You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Kristian Rosenvold <kr...@apache.org> on 2014/12/24 14:20:06 UTC

[DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

>Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)

Last time discussed this we established a consensus to establish 3.0.5
(maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.

This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
code base. As an example, I have been moving code to apache commons,
but we're basically unable to use this effort because commons is now
1.6. alternately I need to backport the code in a
"source-level-shading", but these things are getting silly.

I propose the following:

Make the 3.x line of plugins java 1.6+ only.
Release all shared utilities in 1.6 versions in the 3.x version range.
3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
The most recent core version moves defaults to the 3.x range of plugins.
The parent poms migrate to 3.x range some time in the near future.

Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
ensure that we can still stay 1.5 compatible here.


Kristian

2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
> I don't have access to push a plexus-archiver release, could you
> please do the honors.
>
> Also, looks like my splitting job left some work behind in terms of
> the parent pom.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Hervé BOUTEMY <he...@free.fr>.
Le dimanche 28 décembre 2014 21:04:50 Robert Scholte a écrit :
> Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold
> 
> <kr...@gmail.com>:
> > I'll sumarize what appears to be our consensus so far.
> > 
> > Update to jdk 6.0 "at will", but please be sure that we're not leaving
> > the last 1.5 version in a regressed state.
> > Version number indicates minimum maven version, so a simple JDK
> > upgrade only mandates a minor version update.
> > We are also in a situation a lot of code will be migrating to 3.0.5
> > minimum real soon now.
> 
> When talking about migrating plugins, we should make the plugins 3.0(.x)
> compatible, so we should use migrate to 3.0 (the lowest) and not 3.0.5
> (the latest).
> Most important: for the plugins it doesn't matter; I'm not aware of any
> code where it makes any difference.
> This should give us enough space to remove all M2 hacks with reflections,
> etc.
> And this makes it a lot easier to communicate with the community by just
> saying: maven-plugins 3.x are compatible with all Maven3 distributions.
+1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Benson Margulies <bi...@gmail.com>.
On Tue, Dec 30, 2014 at 6:36 PM, Hervé BOUTEMY <he...@free.fr> wrote:
> personnally, I use invoker: no compatibility problems

I try to make unit tests when I can make unit tests. it's a religion,
or a disease. I agree that falling back to the invoker is the
fallback.

>
> Regards,
>
> Hervé
>
> Le mardi 30 décembre 2014 17:45:36 Benson Margulies a écrit :
>> In my experience, there are significant API issues between 3.0 and
>> 3.1. My particular obsession is with the plugin testing harness.
>>
>> I've had several experiences of the following forn:
>>
>> 1: go to fix a problem in a plugin.
>> 2: try to create an appropriately focussed test
>> 3: try to set up the testing harness
>> 4: get told that all no one understands the version of the testing
>> harness that corresponds to the version of Maven targetted by the
>> plugin, and, in fact, that maintained branch only works with 3.1+.
>>
>> I'd be very happy to read that I've misunderstood and that a floor of
>> '3.0' is enough to get to a working, documented, set of testing tools.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Hervé BOUTEMY <he...@free.fr>.
personnally, I use invoker: no compatibility problems

Regards,

Hervé

Le mardi 30 décembre 2014 17:45:36 Benson Margulies a écrit :
> In my experience, there are significant API issues between 3.0 and
> 3.1. My particular obsession is with the plugin testing harness.
> 
> I've had several experiences of the following forn:
> 
> 1: go to fix a problem in a plugin.
> 2: try to create an appropriately focussed test
> 3: try to set up the testing harness
> 4: get told that all no one understands the version of the testing
> harness that corresponds to the version of Maven targetted by the
> plugin, and, in fact, that maintained branch only works with 3.1+.
> 
> I'd be very happy to read that I've misunderstood and that a floor of
> '3.0' is enough to get to a working, documented, set of testing tools.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Benson Margulies <bi...@gmail.com>.
In my experience, there are significant API issues between 3.0 and
3.1. My particular obsession is with the plugin testing harness.

I've had several experiences of the following forn:

1: go to fix a problem in a plugin.
2: try to create an appropriately focussed test
3: try to set up the testing harness
4: get told that all no one understands the version of the testing
harness that corresponds to the version of Maven targetted by the
plugin, and, in fact, that maintained branch only works with 3.1+.

I'd be very happy to read that I've misunderstood and that a floor of
'3.0' is enough to get to a working, documented, set of testing tools.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Anders Hammar <an...@hammar.net>.
On Sun, Dec 28, 2014 at 9:04 PM, Robert Scholte <rf...@apache.org>
wrote:

> Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold <
> kristian.rosenvold@gmail.com>:
>
>  I'll sumarize what appears to be our consensus so far.
>>
>> Update to jdk 6.0 "at will", but please be sure that we're not leaving
>> the last 1.5 version in a regressed state.
>> Version number indicates minimum maven version, so a simple JDK
>> upgrade only mandates a minor version update.
>> We are also in a situation a lot of code will be migrating to 3.0.5
>> minimum real soon now.
>>
>
> When talking about migrating plugins, we should make the plugins 3.0(.x)
> compatible, so we should use migrate to 3.0 (the lowest) and not 3.0.5 (the
> latest).
> Most important: for the plugins it doesn't matter; I'm not aware of any
> code where it makes any difference.
> This should give us enough space to remove all M2 hacks with reflections,
> etc.
> And this makes it a lot easier to communicate with the community by just
> saying: maven-plugins 3.x are compatible with all Maven3 distributions.
>

Very much +1 on this. The discussion around requiring 3.0.5 was to force
the users to update to a Maven version which didn't have a specific bug or
similar. I personally don't think we should use the minimum Maven version
for that but strictly go for technical reasons (such as API) and in that
case v 3.0 should be enough.

/Anders


>
> Robert
>
>
>
>> Based on past experience, I know that once we start moving shared code
>> to 1.6, there's no turning back. So while it's certainly feasible to
>> our users to release "3.x" versions of our plugins with 1.5 code base,
>> I think this model will not sustain for any amount time. So I still
>> think the recommendation should be 1.6+ for the 3.x plugins, but 1.6
>> may also happen earlier and at RM's discretion. I really think we'd
>> make things a lot easier for our users by declaring the whole 3.x
>> range of plugins 1.6 only. But I have a feeling I'm overcomplicating
>> the "user" perspective since most of them couldn't care less about 1.5
>> anyway.
>>
>> I believe that sums it up. We might want to make some kind of
>> statement on this... ? (Does anyone really care about 1.5...?)
>>
>> Kristian
>>
>>
>>
>>
>>
>> 2014-12-27 18:28 GMT+01:00 Dennis Lundberg <de...@apache.org>:
>>
>>> Hi Kristian,
>>>
>>> I am +1 for any Release Manager wanting to up the minimum Java version
>>> to 1.6 for any of our components, on one condition: if there are any
>>> bugs fixed since the last release of the component, then please do a
>>> final Java 5 compatible release of the component before moving it to
>>> Java 6.
>>>
>>> Regarding versioning I would very much like us to use the major
>>> version of plugins, and other components, to indicate the minimum
>>> *Maven* version it requires. So I'm fine with a bump of the minor
>>> version for a component wishing to switch to Java 6.
>>>
>>> A current example the highlights both of the above is the Checkstyle
>>> Plugin. We will be releasing version 2.14 of the plugin as the final
>>> Java 5 compatible version. After that we will release version 2.15
>>> which will require a version of Checkstyle (the tool - not our plugin)
>>> that requires Java 6 making our plugin require Java 6 as well.
>>>
>>> We should also add an issue in JIRA for each component, specifically
>>> for the change in Java requirement. To make it easier for our users
>>> and ourselves it it also wise to add descriptions to the versions in
>>> JIRA. See the Checkstyle Plugin's road map for an example:
>>> http://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.
>>> jira.plugin.system.project%3Aroadmap-panel
>>>
>>>
>>> On Wed, Dec 24, 2014 at 2:20 PM, Kristian Rosenvold
>>> <kr...@apache.org> wrote:
>>>
>>>> Oops. Snappy contains 1.6 java bytecode, which breaks the build on
>>>>> maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing
>>>>> list :)
>>>>>
>>>>
>>>> Last time discussed this we established a consensus to establish 3.0.5
>>>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>>>>
>>>> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
>>>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
>>>> code base. As an example, I have been moving code to apache commons,
>>>> but we're basically unable to use this effort because commons is now
>>>> 1.6. alternately I need to backport the code in a
>>>> "source-level-shading", but these things are getting silly.
>>>>
>>>> I propose the following:
>>>>
>>>> Make the 3.x line of plugins java 1.6+ only.
>>>> Release all shared utilities in 1.6 versions in the 3.x version range.
>>>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk
>>>> 1.5.
>>>> The most recent core version moves defaults to the 3.x range of plugins.
>>>> The parent poms migrate to 3.x range some time in the near future.
>>>>
>>>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
>>>> ensure that we can still stay 1.5 compatible here.
>>>>
>>>>
>>>> Kristian
>>>>
>>>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>>>
>>>>> I don't have access to push a plexus-archiver release, could you
>>>>> please do the honors.
>>>>>
>>>>> Also, looks like my splitting job left some work behind in terms of
>>>>> the parent pom.
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>>
>>> --
>>> Dennis Lundberg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Robert Scholte <rf...@apache.org>.
Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold  
<kr...@gmail.com>:

> I'll sumarize what appears to be our consensus so far.
>
> Update to jdk 6.0 "at will", but please be sure that we're not leaving
> the last 1.5 version in a regressed state.
> Version number indicates minimum maven version, so a simple JDK
> upgrade only mandates a minor version update.
> We are also in a situation a lot of code will be migrating to 3.0.5
> minimum real soon now.

When talking about migrating plugins, we should make the plugins 3.0(.x)  
compatible, so we should use migrate to 3.0 (the lowest) and not 3.0.5  
(the latest).
Most important: for the plugins it doesn't matter; I'm not aware of any  
code where it makes any difference.
This should give us enough space to remove all M2 hacks with reflections,  
etc.
And this makes it a lot easier to communicate with the community by just  
saying: maven-plugins 3.x are compatible with all Maven3 distributions.

Robert

>
> Based on past experience, I know that once we start moving shared code
> to 1.6, there's no turning back. So while it's certainly feasible to
> our users to release "3.x" versions of our plugins with 1.5 code base,
> I think this model will not sustain for any amount time. So I still
> think the recommendation should be 1.6+ for the 3.x plugins, but 1.6
> may also happen earlier and at RM's discretion. I really think we'd
> make things a lot easier for our users by declaring the whole 3.x
> range of plugins 1.6 only. But I have a feeling I'm overcomplicating
> the "user" perspective since most of them couldn't care less about 1.5
> anyway.
>
> I believe that sums it up. We might want to make some kind of
> statement on this... ? (Does anyone really care about 1.5...?)
>
> Kristian
>
>
>
>
>
> 2014-12-27 18:28 GMT+01:00 Dennis Lundberg <de...@apache.org>:
>> Hi Kristian,
>>
>> I am +1 for any Release Manager wanting to up the minimum Java version
>> to 1.6 for any of our components, on one condition: if there are any
>> bugs fixed since the last release of the component, then please do a
>> final Java 5 compatible release of the component before moving it to
>> Java 6.
>>
>> Regarding versioning I would very much like us to use the major
>> version of plugins, and other components, to indicate the minimum
>> *Maven* version it requires. So I'm fine with a bump of the minor
>> version for a component wishing to switch to Java 6.
>>
>> A current example the highlights both of the above is the Checkstyle
>> Plugin. We will be releasing version 2.14 of the plugin as the final
>> Java 5 compatible version. After that we will release version 2.15
>> which will require a version of Checkstyle (the tool - not our plugin)
>> that requires Java 6 making our plugin require Java 6 as well.
>>
>> We should also add an issue in JIRA for each component, specifically
>> for the change in Java requirement. To make it easier for our users
>> and ourselves it it also wise to add descriptions to the versions in
>> JIRA. See the Checkstyle Plugin's road map for an example:
>> http://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
>>
>>
>> On Wed, Dec 24, 2014 at 2:20 PM, Kristian Rosenvold
>> <kr...@apache.org> wrote:
>>>> Oops. Snappy contains 1.6 java bytecode, which breaks the build on  
>>>> maven plugins. We need to upgrade to 1.6; I'm taking this to the  
>>>> mailing list :)
>>>
>>> Last time discussed this we established a consensus to establish 3.0.5
>>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>>>
>>> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
>>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
>>> code base. As an example, I have been moving code to apache commons,
>>> but we're basically unable to use this effort because commons is now
>>> 1.6. alternately I need to backport the code in a
>>> "source-level-shading", but these things are getting silly.
>>>
>>> I propose the following:
>>>
>>> Make the 3.x line of plugins java 1.6+ only.
>>> Release all shared utilities in 1.6 versions in the 3.x version range.
>>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk  
>>> 1.5.
>>> The most recent core version moves defaults to the 3.x range of  
>>> plugins.
>>> The parent poms migrate to 3.x range some time in the near future.
>>>
>>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
>>> ensure that we can still stay 1.5 compatible here.
>>>
>>>
>>> Kristian
>>>
>>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>>> I don't have access to push a plexus-archiver release, could you
>>>> please do the honors.
>>>>
>>>> Also, looks like my splitting job left some work behind in terms of
>>>> the parent pom.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>>
>>
>> --
>> Dennis Lundberg
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Kristian Rosenvold <kr...@gmail.com>.
I'll sumarize what appears to be our consensus so far.

Update to jdk 6.0 "at will", but please be sure that we're not leaving
the last 1.5 version in a regressed state.
Version number indicates minimum maven version, so a simple JDK
upgrade only mandates a minor version update.
We are also in a situation a lot of code will be migrating to 3.0.5
minimum real soon now.

Based on past experience, I know that once we start moving shared code
to 1.6, there's no turning back. So while it's certainly feasible to
our users to release "3.x" versions of our plugins with 1.5 code base,
I think this model will not sustain for any amount time. So I still
think the recommendation should be 1.6+ for the 3.x plugins, but 1.6
may also happen earlier and at RM's discretion. I really think we'd
make things a lot easier for our users by declaring the whole 3.x
range of plugins 1.6 only. But I have a feeling I'm overcomplicating
the "user" perspective since most of them couldn't care less about 1.5
anyway.

I believe that sums it up. We might want to make some kind of
statement on this... ? (Does anyone really care about 1.5...?)

Kristian





2014-12-27 18:28 GMT+01:00 Dennis Lundberg <de...@apache.org>:
> Hi Kristian,
>
> I am +1 for any Release Manager wanting to up the minimum Java version
> to 1.6 for any of our components, on one condition: if there are any
> bugs fixed since the last release of the component, then please do a
> final Java 5 compatible release of the component before moving it to
> Java 6.
>
> Regarding versioning I would very much like us to use the major
> version of plugins, and other components, to indicate the minimum
> *Maven* version it requires. So I'm fine with a bump of the minor
> version for a component wishing to switch to Java 6.
>
> A current example the highlights both of the above is the Checkstyle
> Plugin. We will be releasing version 2.14 of the plugin as the final
> Java 5 compatible version. After that we will release version 2.15
> which will require a version of Checkstyle (the tool - not our plugin)
> that requires Java 6 making our plugin require Java 6 as well.
>
> We should also add an issue in JIRA for each component, specifically
> for the change in Java requirement. To make it easier for our users
> and ourselves it it also wise to add descriptions to the versions in
> JIRA. See the Checkstyle Plugin's road map for an example:
> http://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
>
>
> On Wed, Dec 24, 2014 at 2:20 PM, Kristian Rosenvold
> <kr...@apache.org> wrote:
>>>Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>>
>> Last time discussed this we established a consensus to establish 3.0.5
>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>>
>> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
>> code base. As an example, I have been moving code to apache commons,
>> but we're basically unable to use this effort because commons is now
>> 1.6. alternately I need to backport the code in a
>> "source-level-shading", but these things are getting silly.
>>
>> I propose the following:
>>
>> Make the 3.x line of plugins java 1.6+ only.
>> Release all shared utilities in 1.6 versions in the 3.x version range.
>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
>> The most recent core version moves defaults to the 3.x range of plugins.
>> The parent poms migrate to 3.x range some time in the near future.
>>
>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
>> ensure that we can still stay 1.5 compatible here.
>>
>>
>> Kristian
>>
>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>> I don't have access to push a plexus-archiver release, could you
>>> please do the honors.
>>>
>>> Also, looks like my splitting job left some work behind in terms of
>>> the parent pom.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
>
> --
> Dennis Lundberg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Dennis Lundberg <de...@apache.org>.
Hi Kristian,

I am +1 for any Release Manager wanting to up the minimum Java version
to 1.6 for any of our components, on one condition: if there are any
bugs fixed since the last release of the component, then please do a
final Java 5 compatible release of the component before moving it to
Java 6.

Regarding versioning I would very much like us to use the major
version of plugins, and other components, to indicate the minimum
*Maven* version it requires. So I'm fine with a bump of the minor
version for a component wishing to switch to Java 6.

A current example the highlights both of the above is the Checkstyle
Plugin. We will be releasing version 2.14 of the plugin as the final
Java 5 compatible version. After that we will release version 2.15
which will require a version of Checkstyle (the tool - not our plugin)
that requires Java 6 making our plugin require Java 6 as well.

We should also add an issue in JIRA for each component, specifically
for the change in Java requirement. To make it easier for our users
and ourselves it it also wise to add descriptions to the versions in
JIRA. See the Checkstyle Plugin's road map for an example:
http://jira.codehaus.org/browse/MCHECKSTYLE#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel


On Wed, Dec 24, 2014 at 2:20 PM, Kristian Rosenvold
<kr...@apache.org> wrote:
>>Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>
> Last time discussed this we established a consensus to establish 3.0.5
> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>
> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
> code base. As an example, I have been moving code to apache commons,
> but we're basically unable to use this effort because commons is now
> 1.6. alternately I need to backport the code in a
> "source-level-shading", but these things are getting silly.
>
> I propose the following:
>
> Make the 3.x line of plugins java 1.6+ only.
> Release all shared utilities in 1.6 versions in the 3.x version range.
> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
> The most recent core version moves defaults to the 3.x range of plugins.
> The parent poms migrate to 3.x range some time in the near future.
>
> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
> ensure that we can still stay 1.5 compatible here.
>
>
> Kristian
>
> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>> I don't have access to push a plexus-archiver release, could you
>> please do the honors.
>>
>> Also, looks like my splitting job left some work behind in terms of
>> the parent pom.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>



-- 
Dennis Lundberg

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Lennart Jörelid <le...@gmail.com>.
First:  +1 for 1.6 minimum.

Second: I feel we need to take a more strategic look at java in general and
plugin mechanics & dependencies in particular. 1.6 is deprecated since a
few years - and while its bytecode runs fine on a JDK 8 runtime, any
implicit dependencies and internal reflection magic relies on the horrible
fact that the classpath is global and anything is accessible.

This is not the case (or should not be the case) when running on a Java 9
runtime. As I'm sure you are aware, attempting to run maven and its plugins
in an OSGi environment is a rather complex, and currently rather futile,
exercise due to the modularized nature of the classloader as well as the
runtime in general. While there are certainly differences between OSGi and
Java 9 as far as the runtime and classloading mechanics go, the
similarities in modularization are decently clear.

So ... how do we ensure that our plugins can work in a JDK 9 runtime
environment (in addition to JDK 6 - 8 RTs)?
Do we create a shared utility to generate correct module-info.java files?
What are your thoughts on the upcoming - substantially bigger - change when
we need to be compliant with the module mechanics of Java 9?


2014-12-24 14:20 GMT+01:00 Kristian Rosenvold <kr...@apache.org>:

> >Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
> plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>
> Last time discussed this we established a consensus to establish 3.0.5
> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>
> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
> code base. As an example, I have been moving code to apache commons,
> but we're basically unable to use this effort because commons is now
> 1.6. alternately I need to backport the code in a
> "source-level-shading", but these things are getting silly.
>
> I propose the following:
>
> Make the 3.x line of plugins java 1.6+ only.
> Release all shared utilities in 1.6 versions in the 3.x version range.
> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
> The most recent core version moves defaults to the 3.x range of plugins.
> The parent poms migrate to 3.x range some time in the near future.
>
> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
> ensure that we can still stay 1.5 compatible here.
>
>
> Kristian
>
> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
> > I don't have access to push a plexus-archiver release, could you
> > please do the honors.
> >
> > Also, looks like my splitting job left some work behind in terms of
> > the parent pom.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 

--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Stephen Connolly <st...@gmail.com>.
+1

(Hoping we can get up to 1.7 soon too)

On Wednesday, 24 December 2014, Kristian Rosenvold <kr...@apache.org>
wrote:

> >Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
> plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>
> Last time discussed this we established a consensus to establish 3.0.5
> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>
> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
> code base. As an example, I have been moving code to apache commons,
> but we're basically unable to use this effort because commons is now
> 1.6. alternately I need to backport the code in a
> "source-level-shading", but these things are getting silly.
>
> I propose the following:
>
> Make the 3.x line of plugins java 1.6+ only.
> Release all shared utilities in 1.6 versions in the 3.x version range.
> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
> The most recent core version moves defaults to the 3.x range of plugins.
> The parent poms migrate to 3.x range some time in the near future.
>
> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
> ensure that we can still stay 1.5 compatible here.
>
>
> Kristian
>
> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bimargulies@gmail.com
> <javascript:;>>:
> > I don't have access to push a plexus-archiver release, could you
> > please do the honors.
> >
> > Also, looks like my splitting job left some work behind in terms of
> > the parent pom.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org <javascript:;>
> For additional commands, e-mail: dev-help@maven.apache.org <javascript:;>
>
>

-- 
Sent from my phone

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Andreas Gudian <an...@gmail.com>.
Did we already cover what we want to keep supporting via Toolchains?

We would have to take some care in Surefire if we wanted to keep some
support for <1.6 when using toolchains or when allowing users to configure
a different JVM.



2014-12-25 15:57 GMT+01:00 Karl Heinz Marbaise <kh...@gmx.de>:

> Hi,
>
> let me summarize things a little bit:
>
> > Last time discussed this we established a consensus to establish 3.0.5
> > (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>
> http://www.mail-archive.com/dev@maven.apache.org/msg102539.html
>
> that was not three months ago...so the line to lift all plugins to 2.2.1
> minimum is not very far way...
>
> I would assume a month or two...I hope less..
>
> https://builds.apache.org/job/dist-tool-plugin/site/dist-
> tool-prerequisites.html
>
> maven-enforcer: next takes a little bit..working on it...
> maven-ear-plugin: waiting for a feedback (on monday i hope so). After that
> i will call a VOTE for it...
> maven-jar-plugin: currently one issue open.....
> maven-gpg-plugin: could be released...
> maven-plugin-plugin: currently no issue open for the 3.4 release (so could
> be pushed out in very short time)
> maven-compiler-plugin: just to fit 2.2.1 could be released
> maven-antrun-plugin: Release 1.8 prepared (i would call a vote in a few
> days).
> maven-jarsigner-plugin: Could be released...to fullfil 2.2.1
>
> maven-archetype-plugin: Takes some time...started to work on it
>
> So now the problematic items:
>
> maven-ant-plugin: Should be retired
> maven-doap-plugin: Might be retired
> maven-stage-plugin: Might be retired
> maven-docck-plugin: Might be retired Unsure
> maven-patch-plugin: Should be retired (better use VCS for such things).
> maven-repository-plugin: Might be retired
> maven-verifier-plugin: Should be retired
> maven-eclipse-plugin: Should be retired to bring people to correct
> direction and use m2e instead
>
> So now coming to the maven releases:
>
> Maven 3.0.X line
>  No change for a year (https://github.com/apache/maven/tree/maven-3.0.x)
>  No issue related to 3.0.X line in JIRA
>
> Maven 3.1.X Line
>  No change for 10 months (https://github.com/apache/maven/tree/maven-3.1.x
> )
>  No issue related to 3.1.X line in JIRA
>
> So next level upgrading will be 3.0.5 minium....
>
> So we should declare EoL for Maven 3.0.5 in Februar 2015...or earlier...
> and for 3.1.1 in April...
>
> So based on the above i would say moving to Java 1.6 does really make
> sense although it is inconsistent from the user point of view...but making
> a clear release note shouldn't be that hard to make...
>
> So +1 to move to 1.6....
>
> This should be made clear by making all plugin versions to bump to 3.0
> (some of them are already there in relationship with Maven 3 minimum).
>
>
> And for all things which have problem we could make a branch from the
> latest releases and fix it there...
>
>
> Kind regards
> Karl Heinz Marbaise
> On 12/24/14 2:20 PM, Kristian Rosenvold wrote:
>
>> Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
>>> plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>>>
>>
>>
>> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
>> code base. As an example, I have been moving code to apache commons,
>> but we're basically unable to use this effort because commons is now
>> 1.6. alternately I need to backport the code in a
>> "source-level-shading", but these things are getting silly.
>>
>> I propose the following:
>>
>> Make the 3.x line of plugins java 1.6+ only.
>> Release all shared utilities in 1.6 versions in the 3.x version range.
>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk
>> 1.5.
>> The most recent core version moves defaults to the 3.x range of plugins.
>> The parent poms migrate to 3.x range some time in the near future.
>>
>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
>> ensure that we can still stay 1.5 compatible here.
>>
>>
>> Kristian
>>
>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>
>>> I don't have access to push a plexus-archiver release, could you
>>> please do the honors.
>>>
>>> Also, looks like my splitting job left some work behind in terms of
>>> the parent pom.
>>>
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Karl Heinz Marbaise <kh...@gmx.de>.
Hi,

let me summarize things a little bit:

 > Last time discussed this we established a consensus to establish 3.0.5
 > (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.

http://www.mail-archive.com/dev@maven.apache.org/msg102539.html

that was not three months ago...so the line to lift all plugins to 2.2.1 
minimum is not very far way...

I would assume a month or two...I hope less..

https://builds.apache.org/job/dist-tool-plugin/site/dist-tool-prerequisites.html

maven-enforcer: next takes a little bit..working on it...
maven-ear-plugin: waiting for a feedback (on monday i hope so). After 
that i will call a VOTE for it...
maven-jar-plugin: currently one issue open.....
maven-gpg-plugin: could be released...
maven-plugin-plugin: currently no issue open for the 3.4 release (so 
could be pushed out in very short time)
maven-compiler-plugin: just to fit 2.2.1 could be released
maven-antrun-plugin: Release 1.8 prepared (i would call a vote in a few 
days).
maven-jarsigner-plugin: Could be released...to fullfil 2.2.1

maven-archetype-plugin: Takes some time...started to work on it

So now the problematic items:

maven-ant-plugin: Should be retired
maven-doap-plugin: Might be retired
maven-stage-plugin: Might be retired
maven-docck-plugin: Might be retired Unsure
maven-patch-plugin: Should be retired (better use VCS for such things).
maven-repository-plugin: Might be retired
maven-verifier-plugin: Should be retired
maven-eclipse-plugin: Should be retired to bring people to correct 
direction and use m2e instead

So now coming to the maven releases:

Maven 3.0.X line
  No change for a year (https://github.com/apache/maven/tree/maven-3.0.x)
  No issue related to 3.0.X line in JIRA

Maven 3.1.X Line
  No change for 10 months (https://github.com/apache/maven/tree/maven-3.1.x)
  No issue related to 3.1.X line in JIRA

So next level upgrading will be 3.0.5 minium....

So we should declare EoL for Maven 3.0.5 in Februar 2015...or earlier...
and for 3.1.1 in April...

So based on the above i would say moving to Java 1.6 does really make 
sense although it is inconsistent from the user point of view...but 
making a clear release note shouldn't be that hard to make...

So +1 to move to 1.6....

This should be made clear by making all plugin versions to bump to 3.0 
(some of them are already there in relationship with Maven 3 minimum).


And for all things which have problem we could make a branch from the 
latest releases and fix it there...


Kind regards
Karl Heinz Marbaise
On 12/24/14 2:20 PM, Kristian Rosenvold wrote:
>> Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>
>
> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
> code base. As an example, I have been moving code to apache commons,
> but we're basically unable to use this effort because commons is now
> 1.6. alternately I need to backport the code in a
> "source-level-shading", but these things are getting silly.
>
> I propose the following:
>
> Make the 3.x line of plugins java 1.6+ only.
> Release all shared utilities in 1.6 versions in the 3.x version range.
> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
> The most recent core version moves defaults to the 3.x range of plugins.
> The parent poms migrate to 3.x range some time in the near future.
>
> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
> ensure that we can still stay 1.5 compatible here.
>
>
> Kristian
>
> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>> I don't have access to push a plexus-archiver release, could you
>> please do the honors.
>>
>> Also, looks like my splitting job left some work behind in terms of
>> the parent pom.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Tibor Digana <ti...@apache.org>.
JDK1.5 and 1.6 are unsupported anymore.
JDK 1.7 is still long alive and under maintenance. 
The Java SE 7 API won't be taken back due to whatever JVM fault :))

The JDK 8 is alive too short.

I don't see any reason why the default Maven plugins have to go with awful
1.5 or 1.6.
We can freely switch to javac 1.7 in default plugins and/or upgrade the
Maven dist to 3.3.1.

One way or another, any build can still use the sniffer plugin to check 1.5
signatures on the top of JDK7 or JDK8.



--
View this message in context: http://maven.40175.n5.nabble.com/DISCUSS-Move-everything-to-1-6-take-2-was-Re-I-can-t-make-a-release-tp5820796p5821968.html
Sent from the Maven Developers mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Olivier Lamy <ol...@apache.org>.
We already discussed this so many times....
But seriously with 2015 coming really soon I believe it's time.
Finally so many years after java 1.5 EOL! :-)

--
Olivier
On 25 Dec 2014 00:20, "Kristian Rosenvold" <kr...@apache.org> wrote:

> >Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
> plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>
> Last time discussed this we established a consensus to establish 3.0.5
> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>
> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
> code base. As an example, I have been moving code to apache commons,
> but we're basically unable to use this effort because commons is now
> 1.6. alternately I need to backport the code in a
> "source-level-shading", but these things are getting silly.
>
> I propose the following:
>
> Make the 3.x line of plugins java 1.6+ only.
> Release all shared utilities in 1.6 versions in the 3.x version range.
> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
> The most recent core version moves defaults to the 3.x range of plugins.
> The parent poms migrate to 3.x range some time in the near future.
>
> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
> ensure that we can still stay 1.5 compatible here.
>
>
> Kristian
>
> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
> > I don't have access to push a plexus-archiver release, could you
> > please do the honors.
> >
> > Also, looks like my splitting job left some work behind in terms of
> > the parent pom.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Kristian Rosenvold <kr...@gmail.com>.
I assume that anyone wishing for 1.7 will also accept 1.6.

I would really just like to establish a consensus that we're leaving
1.5 in favour of 1.6. We have a certain tradition for being "last" to
leave jdk versions and I don't really mind this. It *does* become a
problem when it makes practical development of maven and their core
plugins a problem, which is where we're at.

So my key argument is really about making the pain smaller, not about
using a cool jdk version (which is 1.8 anyway, 1.7 is boring).
apache-commons just opened up for all apache committers so we can
basically move lots of our code to "better" homes if we care to.

Kristian



2014-12-24 23:08 GMT+01:00 Benson Margulies <bi...@gmail.com>:
> Here's what I don't understand. I can see why people need to keep
> building apps that run on antediluvian version. I can't see why it's
> such a problem for a tool, such as Maven, to require 1.7. Who are we
> accomodating by the current policy, or even the 1.6 plan?
>
> Meanwhile, it seems to me that we don't need a complex system of
> releases. There will be no new 3.0.x releases except for some sort of
> exceptional event. If we simply open up everything except the 3.0.x
> branch of the core to 1.6 or 1.7, then the worst that happens is, in
> the event of a security issue out in a component or a plugin, someone
> has to make a branch from the last 1.5-compatible release to make the
> fix.
>
>
> On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint <mk...@gmail.com> wrote:
>> +1.
>>
>> jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be
>> EOL-ed in April 2015..
>>
>> I would suggest moving straight to 1.7 but I guess that's been already
>> discussed.
>>
>> Milos
>>
>> On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte <rf...@apache.org>
>> wrote:
>>
>>> +1, would also make testing with JDK9 easier, although I've already found
>>> a good solution for that.
>>>
>>> Robert
>>>
>>> Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold <
>>> krosenvold@apache.org>:
>>>
>>>
>>>  Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
>>>>> plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>>>>>
>>>>
>>>> Last time discussed this we established a consensus to establish 3.0.5
>>>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>>>>
>>>> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
>>>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
>>>> code base. As an example, I have been moving code to apache commons,
>>>> but we're basically unable to use this effort because commons is now
>>>> 1.6. alternately I need to backport the code in a
>>>> "source-level-shading", but these things are getting silly.
>>>>
>>>> I propose the following:
>>>>
>>>> Make the 3.x line of plugins java 1.6+ only.
>>>> Release all shared utilities in 1.6 versions in the 3.x version range.
>>>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk
>>>> 1.5.
>>>> The most recent core version moves defaults to the 3.x range of plugins.
>>>> The parent poms migrate to 3.x range some time in the near future.
>>>>
>>>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
>>>> ensure that we can still stay 1.5 compatible here.
>>>>
>>>>
>>>> Kristian
>>>>
>>>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>>>
>>>>> I don't have access to push a plexus-archiver release, could you
>>>>> please do the honors.
>>>>>
>>>>> Also, looks like my splitting job left some work behind in terms of
>>>>> the parent pom.
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Benson Margulies <bi...@gmail.com>.
Here's what I don't understand. I can see why people need to keep
building apps that run on antediluvian version. I can't see why it's
such a problem for a tool, such as Maven, to require 1.7. Who are we
accomodating by the current policy, or even the 1.6 plan?

Meanwhile, it seems to me that we don't need a complex system of
releases. There will be no new 3.0.x releases except for some sort of
exceptional event. If we simply open up everything except the 3.0.x
branch of the core to 1.6 or 1.7, then the worst that happens is, in
the event of a security issue out in a component or a plugin, someone
has to make a branch from the last 1.5-compatible release to make the
fix.


On Wed, Dec 24, 2014 at 5:02 PM, Milos Kleint <mk...@gmail.com> wrote:
> +1.
>
> jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be
> EOL-ed in April 2015..
>
> I would suggest moving straight to 1.7 but I guess that's been already
> discussed.
>
> Milos
>
> On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte <rf...@apache.org>
> wrote:
>
>> +1, would also make testing with JDK9 easier, although I've already found
>> a good solution for that.
>>
>> Robert
>>
>> Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold <
>> krosenvold@apache.org>:
>>
>>
>>  Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
>>>> plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>>>>
>>>
>>> Last time discussed this we established a consensus to establish 3.0.5
>>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>>>
>>> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
>>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
>>> code base. As an example, I have been moving code to apache commons,
>>> but we're basically unable to use this effort because commons is now
>>> 1.6. alternately I need to backport the code in a
>>> "source-level-shading", but these things are getting silly.
>>>
>>> I propose the following:
>>>
>>> Make the 3.x line of plugins java 1.6+ only.
>>> Release all shared utilities in 1.6 versions in the 3.x version range.
>>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk
>>> 1.5.
>>> The most recent core version moves defaults to the 3.x range of plugins.
>>> The parent poms migrate to 3.x range some time in the near future.
>>>
>>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
>>> ensure that we can still stay 1.5 compatible here.
>>>
>>>
>>> Kristian
>>>
>>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>>
>>>> I don't have access to push a plexus-archiver release, could you
>>>> please do the honors.
>>>>
>>>> Also, looks like my splitting job left some work behind in terms of
>>>> the parent pom.
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Milos Kleint <mk...@gmail.com>.
+1.

jdk 1.6 is EOL-ed for some time (Feb 2013) already and even 1.7 will be
EOL-ed in April 2015..

I would suggest moving straight to 1.7 but I guess that's been already
discussed.

Milos

On Thu, Dec 25, 2014 at 7:54 AM, Robert Scholte <rf...@apache.org>
wrote:

> +1, would also make testing with JDK9 easier, although I've already found
> a good solution for that.
>
> Robert
>
> Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold <
> krosenvold@apache.org>:
>
>
>  Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
>>> plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
>>>
>>
>> Last time discussed this we established a consensus to establish 3.0.5
>> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>>
>> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
>> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
>> code base. As an example, I have been moving code to apache commons,
>> but we're basically unable to use this effort because commons is now
>> 1.6. alternately I need to backport the code in a
>> "source-level-shading", but these things are getting silly.
>>
>> I propose the following:
>>
>> Make the 3.x line of plugins java 1.6+ only.
>> Release all shared utilities in 1.6 versions in the 3.x version range.
>> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk
>> 1.5.
>> The most recent core version moves defaults to the 3.x range of plugins.
>> The parent poms migrate to 3.x range some time in the near future.
>>
>> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
>> ensure that we can still stay 1.5 compatible here.
>>
>>
>> Kristian
>>
>> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>>
>>> I don't have access to push a plexus-archiver release, could you
>>> please do the honors.
>>>
>>> Also, looks like my splitting job left some work behind in terms of
>>> the parent pom.
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Robert Scholte <rf...@apache.org>.
+1, would also make testing with JDK9 easier, although I've already found  
a good solution for that.

Robert

Op Wed, 24 Dec 2014 14:20:06 +0100 schreef Kristian Rosenvold  
<kr...@apache.org>:

>> Oops. Snappy contains 1.6 java bytecode, which breaks the build on  
>> maven plugins. We need to upgrade to 1.6; I'm taking this to the  
>> mailing list :)
>
> Last time discussed this we established a consensus to establish 3.0.5
> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
>
> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
> code base. As an example, I have been moving code to apache commons,
> but we're basically unable to use this effort because commons is now
> 1.6. alternately I need to backport the code in a
> "source-level-shading", but these things are getting silly.
>
> I propose the following:
>
> Make the 3.x line of plugins java 1.6+ only.
> Release all shared utilities in 1.6 versions in the 3.x version range.
> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk  
> 1.5.
> The most recent core version moves defaults to the 3.x range of plugins.
> The parent poms migrate to 3.x range some time in the near future.
>
> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
> ensure that we can still stay 1.5 compatible here.
>
>
> Kristian
>
> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
>> I don't have access to push a plexus-archiver release, could you
>> please do the honors.
>>
>> Also, looks like my splitting job left some work behind in terms of
>> the parent pom.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)

Posted by Hervé BOUTEMY <he...@free.fr>.
+1

if someone really wants to stay with JDK 5, just don't update plugins to 
latest and greatest

and IMHO, if we need to maintain Maven 3.0.x in parallel from 3.2.x, that's 
not because of the JDK prerequisite: that's because there are problems to 
upgrade some plugins because of Aether change

Regards,

Hervé

Le mercredi 24 décembre 2014 14:20:06 Kristian Rosenvold a écrit :
> >Oops. Snappy contains 1.6 java bytecode, which breaks the build on maven
> >plugins. We need to upgrade to 1.6; I'm taking this to the mailing list :)
> Last time discussed this we established a consensus to establish 3.0.5
> (maybe 3.0.6) as a minimum baseline for the 3.x range of plugins.
> 
> This 3.0.X has a 1.5 java requirement.  The problem is that *everyone*
> is moving to 1.6 and it's getting increasingly hard to maintain a 1.5
> code base. As an example, I have been moving code to apache commons,
> but we're basically unable to use this effort because commons is now
> 1.6. alternately I need to backport the code in a
> "source-level-shading", but these things are getting silly.
> 
> I propose the following:
> 
> Make the 3.x line of plugins java 1.6+ only.
> Release all shared utilities in 1.6 versions in the 3.x version range.
> 3.0.X maven versions stay "forever" on the 2.x line of plugins and jdk 1.5.
> The most recent core version moves defaults to the 3.x range of plugins.
> The parent poms migrate to 3.x range some time in the near future.
> 
> Keeping 3.0.x fixes to a minuimum (and "critical" stuff) only, will
> ensure that we can still stay 1.5 compatible here.
> 
> 
> Kristian
> 
> 2014-12-24 13:52 GMT+01:00 Benson Margulies <bi...@gmail.com>:
> > I don't have access to push a plexus-archiver release, could you
> > please do the honors.
> > 
> > Also, looks like my splitting job left some work behind in terms of
> > the parent pom.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org