> > 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 -- java-devel mailing list java-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/java-devel
