----- Original Message -----
From: "Mikolaj Izdebski" <mizdebsk(a)redhat.com>
To: "java-devel" <java-devel(a)lists.fedoraproject.org>
Sent: Wednesday, February 20, 2013 5:34:06 PM
Subject: Re: [fedora-java] Installing effective Maven POM files
> > 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.
Care to give an example how this will look like?
> 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.
Are you effectively saying that mvn-local/rpmbuild can/will continue to
use normal(non-effective) poms always? So mvn-local stays a usable development tool not
just packaging.
Alexander Kurtakov
Red Hat Eclipse team
--
Mikolaj
--
java-devel mailing list
java-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/java-devel