> Eclipse packages are not using mvn_install macro so they are
not
> affected at all
> (i.e. you are still installing raw poms) and relying on OSGI auto
> requires
> instead of Maven auto requires. Or am I missing something?
This goes against having guidelines at all- if we have maven
guidelines we need to move in direction making it suitable for
everyone (incl. Eclipse). I would like to see Eclipse plugins using
the same technique as others using Maven so make them rely on the
same macros (even if we would have to develop some maven
plugins/extensions for that). We got really close to that state with
mvn-rpmbuild so diverging now would be a step back.
Eclipse packages can be successfully built with %mvn_build. All packages
are already built using XMvn as mvn-rpmbuild is using it under the hoods.
I am open for any suggestions about XMvn. Moreover, I am working on XMvn
plugin API so anyone could write plugins for XMvn and package them
separately (like Eclipse XMvn plugin).
> Question for Alex:
> Would optional installation of raw pom instead of effective with
> specific
> warning that maintainer is responsible for updating proper requires
> be
> acceptable? While you ponder the answer, realize there are ~500
> packages that
> use Maven, most of them are not Eclipse related and thus would
> likely
> benefit
> from proper automatic requires even if Eclipse doesn't.
No, what would be acceptable though is having a marker in the parent
pom package that this parent should never be embedded.
That's easily doable. Add xmvn-mojo into pluginManagement of parent POM.
Configuration of xmvn-mojo would be inherited by all offspring POMs.
One of configuration options available would be disabling generating of
effective POMs.
Still one question will stay open - diverging from upstream more
than
we did before with the patched maven. I know I haven't answered
Mikolaj's question about upstream usability but many of us do use
mvn-local to do upstream work and benefit from the Fedora system
integration which would be irrecoverably lost as having different
poms from maven central in our ~/.m2 would be a no go.
We already have many different POMs. Our POMs are often unusable by
upstream Maven (for example we use versions like "latest" or "SYSTEM"
from time to time).
I already mentioned that several times, but I'll bring this up again.
There is no problem skipping two POM files: one that would be used
by Maven local resolver and another one which you could use for
different purposes. The overhead of installing two POMs is minimal.
Installing effective POMs doesn't mean that raw POMs can't be installed.
--
Mikolaj