You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Bichov, Vitaly" <vi...@hp.com> on 2015/02/02 10:27:56 UTC
maven 3.0.6 release date
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
Re: maven 3.0.6 release date
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,
based on the JIRA not...but i'm not sure if this is just left over cause
the text sounds like it has been solved for 3.0.5 and
3.1.0...furthermore i'm using a parallel build with 180 modules without
any issue...for a long time...Maven 3.1.1....
On 2/2/15 6:58 PM, Bichov, Vitaly wrote:
> Hi,
>
> Was the issue resolved in 3.2.5?
Have you tried to run with 3.2.5 ?
>
> Thank you,
> Vitaly
>
> -----Original Message-----
> From: Karl Heinz Marbaise [mailto:khmarbaise@gmx.de]
> Sent: יום ב 02 פברואר 2015 15:27
> To: users@maven.apache.org
> Subject: Re: maven 3.0.6 release date
>
> 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
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: maven 3.0.6 release date
Posted by "Bichov, Vitaly" <vi...@hp.com>.
Hi,
Was the issue resolved in 3.2.5?
Thank you,
Vitaly
-----Original Message-----
From: Karl Heinz Marbaise [mailto:khmarbaise@gmx.de]
Sent: יום ב 02 פברואר 2015 15:27
To: users@maven.apache.org
Subject: Re: maven 3.0.6 release date
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 3.0.6 release date
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Hello,
In practise it seems to be a small issue (at least for us). Older
branches are seldomly touched and nearly all work with any 3.x
versions (the main reason for this is, that we prefer to use Eclipse
with its internal default maven). My main pain of switching (mostly
JVM) comes from working on OSS projects in parallel to company.
I think it is actually a good idea to keep all active branches somewhat
recent. Otherwise you wont get support for those older plugins in case
you need it (and you run into these problems).
Anyway, I actually have a simple batch file to set my PATH with some
usual combinations of java and maven (asf, company6, company7), but the
idea of having this information inside the project root directory is
attractive for quick switching.
I think a promising tool for your need would be jenv. As it
is documented now it deals with the java version, but it already
brings wrappers for maven, so it might only need a small tweaking to
modify the maven path as well. https://github.com/gcuisinier/jenv
I somewhat feel this is the better way than letting maven parse the POM
and refork itself.
Gruss
Bernd
Am Mon, 2 Feb 2015 08:20:46 -0700
schrieb David Hoffer <dh...@gmail.com>:
> 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, <co...@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:dhoffer6@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
> > <kh...@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-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: users-help@maven.apache.org
> > >
> > >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 3.0.6 release date
Posted by Doug Douglass <do...@gmail.com>.
On Mon, Feb 2, 2015 at 8:30 AM, David Hoffer <dh...@gmail.com> wrote:
>
> 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.
>
>
I have not used, but http://mvnvm.org purports to do what you're asking for.
maven system settings (was: maven 3.0.6 release date)
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
You can specify a empty settings file with -s and define MAVEN_SKIP_RC,
this will avoid all system specific configs (as long as nobody modifies
the maven program folder).
However to my experience sooner or later you do need some specific
landscape settings in the settings.xml file. So it is a good idea to
plan for adding it into the configuration management. Jenkins' maven
builder can manage those config files for example.
Gruss
Bernd
PS: no idea how this is related with the release planning.
Am Mon, 2 Feb 2015 09:58:39 -0700
schrieb David Hoffer <dh...@gmail.com>:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 3.0.6 release date
Posted by David Hoffer <dh...@gmail.com>.
Hi Curtis,
I understand the obligatory reply. I want to point out I'm not saying it
would be easy to implement...just that the concept/feature seems simple. I
have no idea if the seemingly simple concept would be simple to
implement...that would probably take deep knowledge of how Maven is
structured.
It seems our team is not the only ones that could use this feature as I
have seen many approaches at solving this problem but none that address it
internally within Maven.
-Dave
On Mon, Feb 2, 2015 at 10:23 AM, Curtis Rueden <ct...@wisc.edu> wrote:
> 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" <dh...@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 <dh...@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 <dh...@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 <
> khmarbaise@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 <dh...@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, <co...@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:dhoffer6@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 <
> > >>>>>> khmarbaise@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-unsubscribe@maven.apache.org
> > >>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>> Kind regards
> > >>> Karl Heinz Marbaise
> > >>>
> > >>> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> > >>> For additional commands, e-mail: users-help@maven.apache.org
> > >>>
> > >>>
> > >>
> > >
> >
>
Re: maven 3.0.6 release date
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi Chris,
On 2/2/15 6:23 PM, Curtis Rueden wrote:
> 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.
Yes thumb up...create an JIRA issue for it and start working on it...
Kind regards
Karl Heinz Marbaise
>
> -Curtis
> On Feb 2, 2015 11:17 AM, "David Hoffer" <dh...@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 <dh...@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 <dh...@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 <kh...@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 <dh...@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, <co...@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:dhoffer6@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 <
>>>>>>>> khmarbaise@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
>>>>>>>>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 3.0.6 release date
Posted by Curtis Rueden <ct...@wisc.edu>.
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" <dh...@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 <dh...@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 <dh...@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 <kh...@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 <dh...@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, <co...@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:dhoffer6@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 <
> >>>>>> khmarbaise@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-unsubscribe@maven.apache.org
> >>>>>>> For additional commands, e-mail: users-help@maven.apache.org
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>> Kind regards
> >>> Karl Heinz Marbaise
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >>> For additional commands, e-mail: users-help@maven.apache.org
> >>>
> >>>
> >>
> >
>
Re: maven 3.0.6 release date
Posted by David Hoffer <dh...@gmail.com>.
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 <dh...@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 <dh...@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 <kh...@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 <dh...@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, <co...@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:dhoffer6@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 <
>>>>>> khmarbaise@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-unsubscribe@maven.apache.org
>>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> Kind regards
>>> Karl Heinz Marbaise
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>
>
Re: maven 3.0.6 release date
Posted by David Hoffer <dh...@gmail.com>.
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 <dh...@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 <kh...@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 <dh...@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, <co...@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:dhoffer6@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 <khmarbaise@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>
>
Re: maven 3.0.6 release date
Posted by David Hoffer <dh...@gmail.com>.
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 <kh...@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 <dh...@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, <co...@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:dhoffer6@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 <kh...@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-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
> Kind regards
> Karl Heinz Marbaise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven 3.0.6 release date
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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 <dh...@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, <co...@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:dhoffer6@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 <kh...@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-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>>
>>>
>>
>>
>
Kind regards
Karl Heinz Marbaise
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 3.0.6 release date
Posted by David Hoffer <dh...@gmail.com>.
Hi Karl,
Our posts crossed. We use several different Maven versions but upgrading
has always been problematic because it's hard if not impossible to upgrade
all projects to the latest. 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).
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.
-Dave
On Mon, Feb 2, 2015 at 8:20 AM, David Hoffer <dh...@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, <co...@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:dhoffer6@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 <kh...@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-unsubscribe@maven.apache.org
>> > For additional commands, e-mail: users-help@maven.apache.org
>> >
>> >
>>
>
>
Re: maven 3.0.6 release date
Posted by David Hoffer <dh...@gmail.com>.
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, <co...@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:dhoffer6@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 <kh...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>
RE: maven 3.0.6 release date
Posted by co...@wellsfargo.com.
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:dhoffer6@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 <kh...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven 3.0.6 release date
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi David,
On 2/2/15 4:05 PM, David Hoffer wrote:
> 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.
If you work with CI systems like Jenkins they can exactly do what you
wish...
Just define the version you like to use of Maven change the used version
in the build job and run the build. It will automatically download the
Maven version and use it...
> 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.
I suppose you are talking about prerequisites ?
> This makes it hard to upgrade as we have several
> projects to support and some will never be upgraded as they are older
> branches.
Why ? Are those project maven plugin projects or "usual" application
build projects ?
Furthermore the question is which versions do they use at the moment ?
Why not updating Maven ...just do some tests build in a Jenkins and
afterward simply change it..?
> Is this feature on the Maven radar?
Not that i know...but i have to admit that i didn't check the jira for
that...But of course you can create a jira issue for this...
From my perspective i have my doubts to support such thing...
Kind regards
Karl Heinz Marbaise
>
> On Mon, Feb 2, 2015 at 6:27 AM, Karl Heinz Marbaise <kh...@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
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: maven 3.0.6 release date
Posted by Mark Derricutt <ma...@talios.com>.
On 3 Feb 2015, at 4:05, David Hoffer wrote:
> 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?
Could this be handled in the /bin/mvn script - have a new "mvn upgrade" that could download into ~/.m2/install" and run from there if newer than the system install.
This could also maven allow you to define a environment variable for M2_VERSION and have it download run against that?
Mark
--
Mark Derricutt
http://www.theoryinpractice.net
http://www.chaliceofblood.net
http://plus.google.com/+MarkDerricutt
http://twitter.com/talios
http://facebook.com/mderricutt
Re: maven 3.0.6 release date
Posted by David Hoffer <dh...@gmail.com>.
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 <kh...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: maven 3.0.6 release date
Posted by Karl Heinz Marbaise <kh...@gmx.de>.
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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org