Hi David, I feel compelled to throw out the obligatory "It's open source; scratch your itch" response here. It sounds like your team could really use this feature, you seem to think it would be easy to implement, you have an existing template for how another related build tool already does this, and it is not a feature already being worked on by the core Maven developers. It might be worth the development effort for your team to contribute the feature upstream.
-Curtis On Feb 2, 2015 11:17 AM, "David Hoffer" <dhoff...@gmail.com> wrote: > Here is a link to how Gradle does this > > http://gradle.org/docs/current/dsl/org.gradle.api.tasks.wrapper.Wrapper.html > looks like it does a build tool download and builds against that version. > Not sure if this allows simultaneous builds to use different versions but I > assume it does. > > -Dave > > > On Mon, Feb 2, 2015 at 9:58 AM, David Hoffer <dhoff...@gmail.com> wrote: > > > It looks like http://mvnvm.org/ configures a system for a version of > > Maven which is nice but not really what I'm asking for. What I'm asking > > for is no system config. We want to run multiple Maven builds on the > same > > box at the same time with different Maven versions. E.g. pom specifies > > everything, system defines nothing. > > > > -Dave > > > > On Mon, Feb 2, 2015 at 9:50 AM, David Hoffer <dhoff...@gmail.com> wrote: > > > >> For the first question, there is not one answer. As an example one > >> current project is on 3.0.4. I did upgrade that one to 3.2.5 and I > found I > >> had to update several plugins (unfortunately I don't recall which ones > >> those were). In trunk I made those changes so we could use 3.2.5 but I > >> can't make those same plugin changes for branch builds (no one wants to > >> assume the risk of those changes there). So because this would force > devs > >> to have 2 different Maven system configs...we decided to stay at 3.0.4 > for > >> both builds. > >> > >> Yes we have a top level pom that defines plugin versions but that is > >> included in the branch...it's the branch one we don't want to > >> change...trunk one is generally okay to update. (We also have a global > >> company pom...that contains company global things like license, > >> distributionManagement, etc.) > >> > >> I'm not clear why you think this feature couldn't work in Maven or > >> Gradle...seems pretty simple to me. Something like a small bootstraper > is > >> the kernel of the build tool and Maven or Gradle itself is downloaded > as a > >> 'bundle'...or a 'plugin' if I can reuse that term. With this approach > the > >> build is guaranteed to be using exactly the same build bits every > time...no > >> risk of any changes...and the pom defines everything. That being > said...I > >> have not looked at how Gradle accomplishes this. > >> > >> -Dave > >> > >> > >> > >> > >> > >> On Mon, Feb 2, 2015 at 9:10 AM, Karl Heinz Marbaise <khmarba...@gmx.de> > >> wrote: > >> > >>> Hi David, > >>> > >>> unfortunately you really didn't answer my question... > >>> > >>> From which versions of Maven would you like to update...? And what are > >>> the problems you/devs have been faces with? > >>> > >>> > >>> You can test it via CI ... > >>> > >>> BTW: Jenkins was just an example for any kind of CI solution is doesn't > >>> matter if you use Jenkins, TeamCity, Bamboo, or what ever... etc. the > >>> process is always the same... > >>> > >>> > >>> On 2/2/15 4:30 PM, David Hoffer wrote: > >>> > >>>> Hi Karl, > >>>> > >>>> Our posts crossed. We use several different Maven versions > >>>> > >>> > >>> Which ones? > >>> > >>> > but upgrading > >>> > >>>> has always been problematic because it's hard if not impossible to > >>>> upgrade > >>>> all projects to the latest. > >>>> > >>> > >>> Why not? What where/are the exact issues? > >>> > >>> > It's easy to upgrade the trunk (usually) but > >>> > >>>> we have older branches where we do not want to upgrade because we want > >>>> minimal changes in that branch build (e.g. no plugin changes). > >>>> > >>> > >>> What kind of plugin changes ? Haven't you defined a company pom which > >>> contains all the plugin definitions and is continiously maintained to > >>> update them..... > >>> > >>> > >>>> We can't use Jenkins...but that's not an issue...as for CI we have no > >>>> problem running the version we want. The issue is for developers...I > >>>> don't > >>>> want devs to have to constantly switch their environment around just > to > >>>> run > >>>> different maven versions. We often have to run both at the same time > >>>> as we > >>>> are fixing something in a branch and the same in trunk after the > merge. > >>>> > >>>> This is a standard feature of Gradle and lots of folks here are > pushing > >>>> for > >>>> that. If Maven had this feature it would remove their argument. > >>>> > >>> > >>> That sounds like two things.... > >>> > >>> First downloading Maven version (however this can be identified) and > >>> switching to the downloaded instances... > >>> > >>> > >>> Apart from that. Downloading automatically some version does not solve > >>> the real problem here. The builds have not been well maintained and > >>> upgraded/improved as the usualy source code as well... > >>> > >>> I have my doubts that this will work all the time with Gradle as > >>> well...cause in the meantime you have several differernt gradle > versions as > >>> well....I think you will faces the same thing with Gradle cause using a > >>> Gradle version 0.X and now using with 2.2.1 or something produces the > same > >>> problems... > >>> > >>> > >>> > >>> > >>> > >>>> -Dave > >>>> > >>>> On Mon, Feb 2, 2015 at 8:20 AM, David Hoffer <dhoff...@gmail.com> > >>>> wrote: > >>>> > >>>> That's great that Jenkins does this but we need it built into Maven > >>>>> directly. Our CI infrastructure is TeamCity with many hundreds of > >>>>> builds > >>>>> and that's not going to change any time soon and we need developers > to > >>>>> get > >>>>> the same feature from the command line & integrated with their IDE. > >>>>> > >>>>> -Dave > >>>>> > >>>>> On Mon, Feb 2, 2015 at 8:12 AM, <cody.a.fy...@wellsfargo.com> wrote: > >>>>> > >>>>> I have to admit, this would be pretty cool. > >>>>>> > >>>>>> However, Jenkins already has this functionality. You specify the > Maven > >>>>>> version in the job and configure Jenkins to automatically download > >>>>>> that > >>>>>> version (it does with this with Java and Ant as well). > >>>>>> > >>>>>> I highly suggest you look into it. Even running it on your local > >>>>>> machine > >>>>>> is pretty convenient. > >>>>>> > >>>>>> Cody Fyler > >>>>>> Lending Grid Build Team > >>>>>> G=Lending Grid Builds > >>>>>> (515) – 441 - 0814 > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Hoffer [mailto:dhoff...@gmail.com] > >>>>>> Sent: Monday, February 02, 2015 9:06 AM > >>>>>> To: Maven Users List > >>>>>> Subject: Re: maven 3.0.6 release date > >>>>>> > >>>>>> On a somewhat related note, one feature I'd like to see added to > >>>>>> Maven is > >>>>>> the ability to easily upgrade the version of Maven used. I want the > >>>>>> build > >>>>>> to specify the version of Maven used and automatically download and > >>>>>> use > >>>>>> that version. Currently it's the system that determines what > version > >>>>>> is > >>>>>> installed on the path. The best a project can do is require a (min) > >>>>>> version of Maven. This makes it hard to upgrade as we have several > >>>>>> projects to support and some will never be upgraded as they are > older > >>>>>> branches. Is this feature on the Maven radar? > >>>>>> > >>>>>> On Mon, Feb 2, 2015 at 6:27 AM, Karl Heinz Marbaise < > >>>>>> khmarba...@gmx.de> > >>>>>> wrote: > >>>>>> > >>>>>> Hi, > >>>>>>> > >>>>>>> isn't it an option to update to 3.2.5 ? Have you tried it ? > >>>>>>> > >>>>>>> > >>>>>>> On 2/2/15 10:27 AM, Bichov, Vitaly wrote: > >>>>>>> > >>>>>>> Hi, > >>>>>>>> > >>>>>>>> There is this (http://jira.codehaus.org/browse/MNG-5315) bug. > >>>>>>>> The bug has a fix proposal and a workaround. > >>>>>>>> Due to some restrictions I can't apply the workaround on my > >>>>>>>> > >>>>>>> environment. > >>>>>> > >>>>>>> > >>>>>>>> Will the bug be fixed in the next (3.0.6) release? > >>>>>>>> When will 3.0.6 version will be released if ever? > >>>>>>>> > >>>>>>>> Thank you, > >>>>>>>> Vitaly > >>>>>>>> > >>>>>>>> > >>>>>>>> Kind regards > >>>>>>> Karl Heinz Marbaise > >>>>>>> > >>>>>>> ------------------------------------------------------------ > >>>>>>> --------- > >>>>>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >>>>>>> For additional commands, e-mail: users-h...@maven.apache.org > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >>> > >>> Kind regards > >>> Karl Heinz Marbaise > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: users-h...@maven.apache.org > >>> > >>> > >> > > >
