maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Heinz Marbaise <khmarba...@gmx.de>
Subject Re: maven 3.0.6 release date
Date Mon, 02 Feb 2015 17:36:59 GMT
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" <dhoffer6@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 <dhoffer6@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 <dhoffer6@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 <dhoffer6@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.fyler@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


Mime
View raw message