Here's something close... https://github.com/gcuisinier/jenv
On 9 December 2014 at 16:02, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > The really adventurous person could re-use the rvm bash trickery and help > us all ;-) > > On 9 December 2014 at 16:01, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> I normally use a script similar to this: >> http://javaadventure.blogspot.ie/search?q=usemvn >> >> That lets me switch the active maven version for each shell quickly. >> >> You can then set an enforcer rule that prevents the wrong one if you want >> to force a specific maven and people can quickly switch with just one >> command >> >> On 9 December 2014 at 15:43, David Hoffer <dhoff...@gmail.com> wrote: >> >>> In our case devs will be in active development in both branches so >>> potentially building both at the same time. So it seems I either have to >>> upgrade both to 3.2.3 or make the old one at least work with 3.2.3 or >>> don't >>> upgrade at all. >>> >>> Maven really needs a bootstrap process where the build specifies the >>> version used so multiple builds can co-exist using any maven version, is >>> that a planned feature? >>> >>> -Dave >>> >>> On Tue, Dec 9, 2014 at 8:25 AM, Adrien Rivard <adrien.riv...@gmail.com> >>> wrote: >>> >>> > Have them execute a wrapper script that set Maven paths according to >>> the >>> > current project and execute it. >>> > you can even alias this script to "mvn" command. >>> > >>> > >>> > On Tue, Dec 9, 2014 at 4:12 PM, David Hoffer <dhoff...@gmail.com> >>> wrote: >>> > >>> > > I don't think the CI Server is an issue as we have lots of >>> flexibility >>> > when >>> > > we setup those jobs. The issue is for developer builds. I'm not >>> clear >>> > how >>> > > to setup workstations to make it easy to build projects with >>> different >>> > > Maven versions. >>> > > >>> > > Our standard practice is to set M2_HOME to the maven install and >>> then add >>> > > %M2_HOME%/bin to the path. >>> > > >>> > > The suggestion was to not set M2_HOME...okay I thought that was >>> required >>> > > but we can not set it. We still need Maven in our path. Are you >>> saying >>> > > that if I set the path to Maven version X, my build can somehow >>> specify >>> > to >>> > > use Maven version Y or Z? All I've seen in Maven thus far is the >>> ability >>> > > to specify what version must be used not what version to use, and >>> it's >>> > the >>> > > later I'm looking for. I don't want devs to have to reconfigure >>> their >>> > > system props to build different code branches. >>> > > >>> > > -Dave >>> > > >>> > > On Tue, Dec 9, 2014 at 1:51 AM, Bernd Eckenfels < >>> e...@zusammenkunft.net> >>> > > wrote: >>> > > >>> > > > Am Tue, 09 Dec 2014 09:27:29 +0100 >>> > > > schrieb Jörg Schaible <joerg.schai...@swisspost.com>: >>> > > > >>> > > > > > One other issue came up in this upgrade. We still have >>> branches >>> > > > > > that have to stay at 3.0.x. How can I make the trunk build use >>> > > > > > 3.2.3 w/o changing everyone's M2_HOME? Is there a way to >>> bootstrap >>> > > > > > the build so the build picks the specified version of Maven? >>> E.g. >>> > > > > > I want the build to specify the version used not the system. >>> > > > > >>> > > > > Don't set it at all. The mvn shell scripts will automatically do >>> so >>> > > > > for their Maven version on-the-fly. >>> > > > >>> > > > and use a CI Server where you configure the maven path for each >>> job. >>> > > > >>> > > > Gruss >>> > > > Bernd >>> > > > >>> > > > >>> --------------------------------------------------------------------- >>> > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >>> > > > For additional commands, e-mail: users-h...@maven.apache.org >>> > > > >>> > > > >>> > > >>> > >>> > >>> > >>> > -- >>> > Adrien Rivard >>> > >>> >> >> >
