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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>>> 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, <[email protected]> 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:[email protected]] >>>>>> 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 < >>>>>> [email protected]> >>>>>> 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: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>> >>> Kind regards >>> Karl Heinz Marbaise >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> >
