----- Original Message ----- > From: "Mikolaj Izdebski" <mizdebsk@xxxxxxxxxx> > To: "java-devel" <java-devel@xxxxxxxxxxxxxxxxxxxxxxx> > Sent: Wednesday, February 20, 2013 5:34:06 PM > Subject: Re: 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/java-devel -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
