Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Go for Java 7! Or 8! Gary div Original message /divdivFrom: Tibor Digana tibordig...@apache.org /divdivDate:01/01/2015 15:07 (GMT-05:00) /divdivTo: dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divJDK1.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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
On Sun, Dec 28, 2014 at 9:04 PM, Robert Scholte rfscho...@apache.org wrote: Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold kristian.rosenv...@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 denn...@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 krosenv...@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 bimargul...@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
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
On Tue, Dec 30, 2014 at 6:36 PM, Hervé BOUTEMY herve.bout...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 denn...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Op Sun, 28 Dec 2014 19:37:47 +0100 schreef Kristian Rosenvold kristian.rosenv...@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 denn...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 kristian.rosenv...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 khmarba...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
It appears that IBM JDK6 is EOL september next year. People move at different speeds :) Kristian 2014-12-25 6:25 GMT+01:00 Gary Gregory garydgreg...@gmail.com: +1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere'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 mkle...@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 rfscho...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
... and when I say CodeHaus above, I mean Apache. Fair? ;) 2014-12-25 13:11 GMT+01:00 Lennart Jörelid lennart.jore...@gmail.com: Quite true. :) But this opens another interesting discussion. Do we move the codehaus products with the slowest of the major JDK release cycles (i.e. to match the IBM JDK release cycle in this case)? Or with the Oracle JDK's release cycles? There may not be much difference in the mechanics of JDK 6 and JDK 7 - but there are certainly differences between JDK 8 and JDK 9, which we have to cater for (or at least create a strategy to handle). If so - do we aim for introducing module mechanics to match Oracle's JDK 9 release or the eventual IBM JDK's release? Or something else entirely? 2014-12-25 12:46 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com: It appears that IBM JDK6 is EOL september next year. People move at different speeds :) Kristian 2014-12-25 6:25 GMT+01:00 Gary Gregory garydgreg...@gmail.com: +1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere'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 mkle...@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 rfscho...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator
Re: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
Quite true. :) But this opens another interesting discussion. Do we move the codehaus products with the slowest of the major JDK release cycles (i.e. to match the IBM JDK release cycle in this case)? Or with the Oracle JDK's release cycles? There may not be much difference in the mechanics of JDK 6 and JDK 7 - but there are certainly differences between JDK 8 and JDK 9, which we have to cater for (or at least create a strategy to handle). If so - do we aim for introducing module mechanics to match Oracle's JDK 9 release or the eventual IBM JDK's release? Or something else entirely? 2014-12-25 12:46 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com : It appears that IBM JDK6 is EOL september next year. People move at different speeds :) Kristian 2014-12-25 6:25 GMT+01:00 Gary Gregory garydgreg...@gmail.com: +1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere'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 mkle...@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 rfscho...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@jguru.se | URL: www.jguru.se | Phone | (skype):jgurueurope | (intl): +46 708 507 603
Re: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1 for moving to at least 1.6 or even 1.7. While 1.8 would be the release with more interesting features, I think requiring this would be too early. Regards Mirko -- Sent from my mobile On Dec 25, 2014 1:12 PM, Lennart Jörelid lennart.jore...@gmail.com wrote: Quite true. :) But this opens another interesting discussion. Do we move the codehaus products with the slowest of the major JDK release cycles (i.e. to match the IBM JDK release cycle in this case)? Or with the Oracle JDK's release cycles? There may not be much difference in the mechanics of JDK 6 and JDK 7 - but there are certainly differences between JDK 8 and JDK 9, which we have to cater for (or at least create a strategy to handle). If so - do we aim for introducing module mechanics to match Oracle's JDK 9 release or the eventual IBM JDK's release? Or something else entirely? 2014-12-25 12:46 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com : It appears that IBM JDK6 is EOL september next year. People move at different speeds :) Kristian 2014-12-25 6:25 GMT+01:00 Gary Gregory garydgreg...@gmail.com: +1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere'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 mkle...@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 rfscho...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1 (Hoping we can get up to 1.7 soon too) On Wednesday, 24 December 2014, Kristian Rosenvold krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: dev-h...@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 ...)
+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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- -- +==+ | Bästa hälsningar, | [sw. Best regards] | | Lennart Jörelid | EAI Architect Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: l...@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 ...)
+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 rfscho...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 mkle...@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 rfscho...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
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 bimargul...@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 mkle...@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 rfscho...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...)
+1 Gary div Original message /divdivFrom: Benson Margulies bimargul...@gmail.com /divdivDate:12/24/2014 17:08 (GMT-05:00) /divdivTo: Maven Developers List dev@maven.apache.org /divdivCc: /divdivSubject: Re: [DISCUSS] Move everything to 1.6, take 2 (was: Re: I can't make a release ...) /divdiv /divHere'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 mkle...@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 rfscho...@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 krosenv...@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 bimargul...@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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
