Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 450410 - dev-java/maven-bin and app-eselect/eselect-java should install /usr/bin/mvnDebug symlink
Summary: dev-java/maven-bin and app-eselect/eselect-java should install /usr/bin/mvnDe...
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Java (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Java team
URL:
Whiteboard:
Keywords: EBUILD
Depends on:
Blocks: eselect-java-tracker
  Show dependency tree
 
Reported: 2013-01-05 16:01 UTC by Stefan Zwanenburg
Modified: 2017-05-27 09:27 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
maven-bin-2.0.11-r3.ebuild (maven-bin-2.0.11-r3.ebuild,1.38 KB, text/plain)
2013-01-05 16:02 UTC, Stefan Zwanenburg
Details
maven-bin-2.2.1-r3.ebuild (maven-bin-2.2.1-r3.ebuild,1.38 KB, text/plain)
2013-01-05 16:02 UTC, Stefan Zwanenburg
Details
maven-bin-3.0.4-r2.ebuild (maven-bin-3.0.4-r2.ebuild,1.46 KB, text/plain)
2013-01-05 16:02 UTC, Stefan Zwanenburg
Details
eselect-maven-0.3.ebuild (eselect-maven-0.3.ebuild,814 bytes, text/plain)
2013-01-05 16:03 UTC, Stefan Zwanenburg
Details
files/maven-0.3.eselect (maven-0.3.eselect,4.48 KB, text/plain)
2013-01-05 16:31 UTC, Stefan Zwanenburg
Details
eselect-maven.ebuild.patch (eselect-maven.ebuild.patch,717 bytes, patch)
2013-01-08 13:37 UTC, Stefan Zwanenburg
Details | Diff
maven.eselect.patch (maven.eselect.patch,2.48 KB, patch)
2013-01-08 13:38 UTC, Stefan Zwanenburg
Details | Diff
maven-bin-2.0.11.ebuild.patch (maven-bin-2.0.11.ebuild.patch,604 bytes, patch)
2013-01-08 13:38 UTC, Stefan Zwanenburg
Details | Diff
maven-bin-2.2.1.ebuild.patch (maven-bin-2.2.1.ebuild.patch,602 bytes, patch)
2013-01-08 13:38 UTC, Stefan Zwanenburg
Details | Diff
maven-bin-3.0.4.ebuild.patch (maven-bin-3.0.4.ebuild.patch,602 bytes, patch)
2013-01-08 13:39 UTC, Stefan Zwanenburg
Details | Diff
maven-bin-2.0.11.ebuild.patch (maven-bin-2.0.11.ebuild.patch,750 bytes, patch)
2013-01-11 14:21 UTC, Stefan Zwanenburg
Details | Diff
maven-bin-2.2.1.ebuild.patch (maven-bin-2.2.1.ebuild.patch,748 bytes, patch)
2013-01-11 14:21 UTC, Stefan Zwanenburg
Details | Diff
maven-bin-3.0.4.ebuild.patch (maven-bin-3.0.4.ebuild.patch,748 bytes, patch)
2013-01-11 14:21 UTC, Stefan Zwanenburg
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Zwanenburg 2013-01-05 16:01:38 UTC
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
Comment 1 Stefan Zwanenburg 2013-01-05 16:02:18 UTC
Created attachment 334536 [details]
maven-bin-2.0.11-r3.ebuild
Comment 2 Stefan Zwanenburg 2013-01-05 16:02:32 UTC
Created attachment 334538 [details]
maven-bin-2.2.1-r3.ebuild
Comment 3 Stefan Zwanenburg 2013-01-05 16:02:47 UTC
Created attachment 334540 [details]
maven-bin-3.0.4-r2.ebuild
Comment 4 Stefan Zwanenburg 2013-01-05 16:03:04 UTC
Created attachment 334542 [details]
eselect-maven-0.3.ebuild
Comment 5 Stefan Zwanenburg 2013-01-05 16:31:06 UTC
Created attachment 334546 [details]
files/maven-0.3.eselect
Comment 6 Ralph Sennhauser (RETIRED) gentoo-dev 2013-01-07 09:13:58 UTC
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.
Comment 7 Stefan Zwanenburg 2013-01-08 13:37:52 UTC
Created attachment 334788 [details, diff]
eselect-maven.ebuild.patch
Comment 8 Stefan Zwanenburg 2013-01-08 13:38:15 UTC
Created attachment 334790 [details, diff]
maven.eselect.patch
Comment 9 Stefan Zwanenburg 2013-01-08 13:38:36 UTC
Created attachment 334792 [details, diff]
maven-bin-2.0.11.ebuild.patch
Comment 10 Stefan Zwanenburg 2013-01-08 13:38:57 UTC
Created attachment 334794 [details, diff]
maven-bin-2.2.1.ebuild.patch
Comment 11 Stefan Zwanenburg 2013-01-08 13:39:18 UTC
Created attachment 334796 [details, diff]
maven-bin-3.0.4.ebuild.patch
Comment 12 Stefan Zwanenburg 2013-01-08 13:46:32 UTC
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!
Comment 13 Stefan Zwanenburg 2013-01-11 14:21:10 UTC
Created attachment 335188 [details, diff]
maven-bin-2.0.11.ebuild.patch
Comment 14 Stefan Zwanenburg 2013-01-11 14:21:29 UTC
Created attachment 335190 [details, diff]
maven-bin-2.2.1.ebuild.patch
Comment 15 Stefan Zwanenburg 2013-01-11 14:21:46 UTC
Created attachment 335192 [details, diff]
maven-bin-3.0.4.ebuild.patch
Comment 16 Stefan Zwanenburg 2013-01-11 14:23:53 UTC
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.
Comment 17 Ralph Sennhauser (RETIRED) gentoo-dev 2013-01-21 09:16:02 UTC
(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.
Comment 18 Joerg Schaible 2014-03-10 10:27:05 UTC
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.
Comment 19 James Le Cuirot gentoo-dev 2017-05-10 22:33:34 UTC
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.
Comment 20 Joerg Schaible 2017-05-12 22:09:22 UTC
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.
Comment 21 James Le Cuirot gentoo-dev 2017-05-12 22:28:55 UTC
(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?
Comment 22 Joerg Schaible 2017-05-20 15:30:24 UTC
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.
Comment 23 James Le Cuirot gentoo-dev 2017-05-21 08:58:41 UTC
(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.
Comment 24 Joerg Schaible 2017-05-27 09:27:58 UTC
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.