I noticed that a symlink to mvnDebug in ${EROOT}/usr/bin/ is not being included in the latest maven-bin packages. I thought this might be something people might want, as it is quite a useful thing. Therefore, I took it upon myself to make sure this happens. Please find updated ebuilds for maven-bin (slots 2.0, 2.2 and 3.0) and eselect-maven attached to this report. Reproducible: Always
Created attachment 334536 [details] maven-bin-2.0.11-r3.ebuild
Created attachment 334538 [details] maven-bin-2.2.1-r3.ebuild
Created attachment 334540 [details] maven-bin-3.0.4-r2.ebuild
Created attachment 334542 [details] eselect-maven-0.3.ebuild
Created attachment 334546 [details] files/maven-0.3.eselect
I'm open for this. Though we have to decide whether to use a run-maven-tool script as we have one for java vm tools or if we just don't create the symlink if maven (maven 1.x here) is missing the command. Generating shell or native wrappers either in the maven ebuilds or eselect-maven would be other alternatives. As a side note, for the attachments unified diffs are generally preferred. It helps to spot what should change, after all patches is what we are used to. Thanks.
Created attachment 334788 [details, diff] eselect-maven.ebuild.patch
Created attachment 334790 [details, diff] maven.eselect.patch
Created attachment 334792 [details, diff] maven-bin-2.0.11.ebuild.patch
Created attachment 334794 [details, diff] maven-bin-2.2.1.ebuild.patch
Created attachment 334796 [details, diff] maven-bin-3.0.4.ebuild.patch
I'm not entirely sure the format of the patches is as you desired (mostly because it assumes that the files will be renamed), but here they are. As for something of a run-maven-tool script, I'm not entirely sure what to do about that. I suppose the M2_HOME environment variable is really the only thing that such a script would have to set, so instead of inserting a symlink to /usr/share/${P}/mvn, we could install a shell script that does little more than: M2_HOME=/usr/share/${P}/ /usr/share/${P}/mvn Another solution would be to add an entry in /etc/env.d that does nothing but keep track of which maven version is currently selected, but again, I'm not sure if it's an acceptable solution. Management of M2_HOME is a bit cumbersome as it is, as, indeed, the eselect script does nothing about it, which makes it pretty much useless. Any other ideas? Also, any further comments/criticisms to my "contributions" are more than welcome!
Created attachment 335188 [details, diff] maven-bin-2.0.11.ebuild.patch
Created attachment 335190 [details, diff] maven-bin-2.2.1.ebuild.patch
Created attachment 335192 [details, diff] maven-bin-3.0.4.ebuild.patch
Would something like the latest patches be satisfactory? I now generate a small wrapper (with the make_wrapper function from eutils.eclass) that sets M2_HOME before calling the appropriate mvn (or mvnDebug) binary.
(In reply to comment #12) > I'm not entirely sure the format of the patches is as you desired (mostly > because it assumes that the files will be renamed), but here they are. They are fine, not changing keywords would generate even less noise though. The other thing is the three ebuild patches are basically identical (each can be applied to all ebuilds) and so one against the latest ebuild would have been enough. But that I consider nitpicking. > As for something of a run-maven-tool script, I'm not entirely sure what to > do about that. I suppose the M2_HOME environment variable is really the only > thing that such a script would have to set, so instead of inserting a > symlink to /usr/share/${P}/mvn, we could install a shell script that does > little more than: > M2_HOME=/usr/share/${P}/ /usr/share/${P}/mvn run-java-tool is a shared version of your wrappers in the patch, shared across jvms and tools. It employs some tricks to get good error messages and being able to switch the "selected" vm temporally. > Another solution would be to add an entry in /etc/env.d that does nothing > but keep track of which maven version is currently selected, but again, I'm > not sure if it's an acceptable solution. The problem with env.d is changes don't take effect immediately, see 'man env-update'. If you want to go that route you'd have to add a symlink pointing to the actual currently selected M2_HOME. > Management of M2_HOME is a bit cumbersome as it is, as, indeed, the eselect > script does nothing about it, which makes it pretty much useless. Any other > ideas? yep if M2_HOME is set in the users env I see how that might cause some headaches. > Also, any further comments/criticisms to my "contributions" are more than > welcome! None for the moment ;) I filed bug 453300 which is related to the solution we pick here.
Please refrain from setting M2_HOME at all! It is simply not required, because the start scripts of Maven will set them on its own and only this allows currently the usage of multiple Maven versions just by cally explicitly /usr/bin/mvn-x.y.
If any of you still care, how would you feel about no longer slotting maven-bin at all? It just doesn't seem to make sense. I gather v1 to v2 was a bit rocky but we're way beyond that now.
It might be true for simple projects whatever Maven version you're using, but not for more complicated ones or if you have to maintain elderly customer projects. As Java developer I am absolutely dependent on slotting.
(In reply to Joerg Schaible from comment #20) > It might be true for simple projects whatever Maven version you're using, > but not for more complicated ones or if you have to maintain elderly > customer projects. As Java developer I am absolutely dependent on slotting. How about if it was just SLOTs 1, 2, and 3? Or maybe just 2 and 3, does anyone really use 1 any more?
Personally I don't use Maven 1.x any longer, but it is essential to have the minor versions around for the slots. E.g. when I build XStream 1.4.x with JDK 1.4 I have to use mvn-2.0. For JDK 5 I can use mvn-2.2. A build with JDK 6 requires mvn-3.2. For Java 7 and 8, mvn-3.3 is fine. And it currently looks like Java 9 will require mvn-3.5 or mvn-3.6. Point is that even for the minor versions, Maven often changes some kind of requirement e.g. minimum supported Java version, slightly changes the behaviour of profile activation, has internal compatibility problems (Aether) with its own plugins and so on. While you don't have to keep any slotted version in the official tree (as you might imagine, I have the old JDKs in a local overlay), the slot revision should stay with the current major/minor scheme.
(In reply to Joerg Schaible from comment #22) > Personally I don't use Maven 1.x any longer, but it is essential to have the > minor versions around for the slots. E.g. when I build XStream 1.4.x with > JDK 1.4 I have to use mvn-2.0. For JDK 5 I can use mvn-2.2. A build with JDK > 6 requires mvn-3.2. For Java 7 and 8, mvn-3.3 is fine. And it currently > looks like Java 9 will require mvn-3.5 or mvn-3.6. > > Point is that even for the minor versions, Maven often changes some kind of > requirement e.g. minimum supported Java version, slightly changes the > behaviour of profile activation, has internal compatibility problems > (Aether) with its own plugins and so on. What a scary environment you have. :) That was very informative, thank you. I'm willing to keep them if the situation is as you say but I'm wondering about this line from the documentation. Is this solution not sufficient for you? "Maven 3.3+ require JDK 1.7 or above to execute - they still allows you to build against 1.3 and other JDK versions by Using Toolchains." http://maven.apache.org/download.cgi http://maven.apache.org/guides/mini/guide-using-toolchains.html We're trying to remove Java 7 at the moment to avoid some issues but in the longer term, we'd like to properly support building for older JREs by using older rt.jar files in the bootclasspath as you're supposed to. I understand that some people want the actual old JDKs but that's a headache this struggling team could do without. There will at least be icedtea:7 in java-overlay for the foreseeable future.
Toolchains solve some problems, but have also some major disadvantages: - the project is no longer self-contained, i.e. Toolchain configuration is part of your user's home - it is not possible to activate profiles based on toolchains With the latter limitation it would not be possible to build XStream 1.4.x for older JDKs. The first limitation is annoying for random users trying to build a project for elderly versions and it might be even more an issue for Gentoo's build ecosystem though. Personally I have no problem to keep more Maven or JDK versions in my private overlay as long as the infrastructure allows me to switch easily between those as it is possible now. Note, that a lot of Java projects might still support Java 7 for quite some time because of Android not supporting Java 8.
