Re: move maven core to java 7?
Le mardi 10 mars 2015 01:22:29 Jason van Zyl a écrit : I agree we're spending too much energy we have a constructive discussion to make a community decision: yes, it costs energy (not so much since the discussion is constructive), but it's useful but I don't plan to roll anything back. I do not want to support the rather large feature set change across 1.6 and 1.7 because it will be a huge maintenance burden. It's entirely unrealistic to try and support 1.6 and 1.7 given the activity in the core by so few. If we cut this release and then we switch to 1.7 the 3.3.0 will pretty much become instantly dead because I know we'll flip over to 1.7 features quickly and i doubt anyone is going to backport anything and there are likely going to be issues with all the new features and then a user is going to be forced to update anyway to get the fixes. If you want all the new features then too bad, upgrade to 3.3.0 and use 1.7. I really do not want to continue developing with 1.6 because I think it's a waste of time and energy. I perfectly understand this reasoning: and I know I didn't do the backport to 3.0.6 that I prepared because I had the exact same feeling if you want all the new features then too bad, upgrade, and that our users understand it personnally, I can live with both choices: we have the pros and cons of each and will be able to explain our choice in the release notes Regards, Hervé On Mar 10, 2015, at 12:56 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think we're spending far too much energy on this discussion. Roll back to 1.6/1.6 and make the 3.4 1.7. Kristian 2015-03-10 8:50 GMT+01:00 Hervé BOUTEMY herve.bout...@free.fr: Java 7, ie 3.2(Java 6)/3.3(Java 7+current changes) or Java 6, ie 3.2(Java 6)/3.3(Java 6+current changes)/3.4(Java 7, ~1 month later) ? Regards, Hervé Le lundi 9 mars 2015 09:35:30 Jason van Zyl a écrit : Yes, I'll leave it until Wednesday to see if anyone has any issues running master and then I'll stage the release. On Mar 8, 2015, at 6:42 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: notice that this would be a de-facto Maven versionning pattern: 2.0 (Java 1.4)/2.1(Java 1.4+changes)/2.2(Java 5) 3.0 (Java 5)/3.1(Java 5+changes)/3.2(Java 6) then 3.2(Java 6)/3.3(Java 6+changes)/3.4(Java 7), if we announce the pattern and do the 3.4 release something like one month later (after checking that we don't need critical fix on 3.3), could match everybody's concern with such a plan decision, I could go for it Regards, Hervé Le dimanche 8 mars 2015 21:43:11 Robert Scholte a écrit : issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the Java7 decision. And that's fine by me. As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and call this Maven 3.4.0 A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth a 4.0.0 Also see previous releases when we moved forward to Java5 (M2.2) and Java6 (M3.2) Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana tibordig...@apache.org: @Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p582 85 22.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 - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: dev
Re: move maven core to java 7?
At the end of the day, nobody has felt strongly enough about https://git1-us-west.apache.org/repos/asf?p=maven.git;a=commit;h=07b8477b to veto or even -0.5 that commit. I know we have been having the discussion here, but to me it seems like these are bolting the stable doors after the horse has bolted demagogue That commit has stood for more 6 days, and as I understand it, in C-T-R the veto has to land within 3 days or lazy consensus implies everyone approves. So the vote was called (by virtue of the commit), the results are in (by lazy consensus) and everyone agreed 3.3.0 is Java 7 ;-) /demagogue I guess the point I am making: Does anyone feel strongly enough about 3.3.0 being Java 7 to commit a revert of 07b8477b? On 11 March 2015 at 07:35, Hervé BOUTEMY herve.bout...@free.fr wrote: Le mardi 10 mars 2015 01:22:29 Jason van Zyl a écrit : I agree we're spending too much energy we have a constructive discussion to make a community decision: yes, it costs energy (not so much since the discussion is constructive), but it's useful but I don't plan to roll anything back. I do not want to support the rather large feature set change across 1.6 and 1.7 because it will be a huge maintenance burden. It's entirely unrealistic to try and support 1.6 and 1.7 given the activity in the core by so few. If we cut this release and then we switch to 1.7 the 3.3.0 will pretty much become instantly dead because I know we'll flip over to 1.7 features quickly and i doubt anyone is going to backport anything and there are likely going to be issues with all the new features and then a user is going to be forced to update anyway to get the fixes. If you want all the new features then too bad, upgrade to 3.3.0 and use 1.7. I really do not want to continue developing with 1.6 because I think it's a waste of time and energy. I perfectly understand this reasoning: and I know I didn't do the backport to 3.0.6 that I prepared because I had the exact same feeling if you want all the new features then too bad, upgrade, and that our users understand it personnally, I can live with both choices: we have the pros and cons of each and will be able to explain our choice in the release notes Regards, Hervé On Mar 10, 2015, at 12:56 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think we're spending far too much energy on this discussion. Roll back to 1.6/1.6 and make the 3.4 1.7. Kristian 2015-03-10 8:50 GMT+01:00 Hervé BOUTEMY herve.bout...@free.fr: Java 7, ie 3.2(Java 6)/3.3(Java 7+current changes) or Java 6, ie 3.2(Java 6)/3.3(Java 6+current changes)/3.4(Java 7, ~1 month later) ? Regards, Hervé Le lundi 9 mars 2015 09:35:30 Jason van Zyl a écrit : Yes, I'll leave it until Wednesday to see if anyone has any issues running master and then I'll stage the release. On Mar 8, 2015, at 6:42 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: notice that this would be a de-facto Maven versionning pattern: 2.0 (Java 1.4)/2.1(Java 1.4+changes)/2.2(Java 5) 3.0 (Java 5)/3.1(Java 5+changes)/3.2(Java 6) then 3.2(Java 6)/3.3(Java 6+changes)/3.4(Java 7), if we announce the pattern and do the 3.4 release something like one month later (after checking that we don't need critical fix on 3.3), could match everybody's concern with such a plan decision, I could go for it Regards, Hervé Le dimanche 8 mars 2015 21:43:11 Robert Scholte a écrit : issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the Java7 decision. And that's fine by me. As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and call this Maven 3.4.0 A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth a 4.0.0 Also see previous releases when we moved forward to Java5 (M2.2) and Java6 (M3.2) Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana tibordig...@apache.org: @Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p582 85 22.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: move maven core to java 7?
2015-03-08 16:07 GMT+01:00 Tibor Digana tibordig...@apache.org: As you said, the SPI did not work well in multimodule project. You tested SPI in Maven, so you know better than me :) The problem is really only once the SPI project is in the same reactor as is using it. Even then there were indications that this has actually been improved in 3.x; I did not check this. There is a testcase in surefire for this (surefire-141), where I split the provider into a separate project and the testcase forks 2 different builds. I really dont think we should introduce another mechanism Kristian
Re: move maven core to java 7?
Java 7, ie 3.2(Java 6)/3.3(Java 7+current changes) or Java 6, ie 3.2(Java 6)/3.3(Java 6+current changes)/3.4(Java 7, ~1 month later) ? Regards, Hervé Le lundi 9 mars 2015 09:35:30 Jason van Zyl a écrit : Yes, I'll leave it until Wednesday to see if anyone has any issues running master and then I'll stage the release. On Mar 8, 2015, at 6:42 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: notice that this would be a de-facto Maven versionning pattern: 2.0 (Java 1.4)/2.1(Java 1.4+changes)/2.2(Java 5) 3.0 (Java 5)/3.1(Java 5+changes)/3.2(Java 6) then 3.2(Java 6)/3.3(Java 6+changes)/3.4(Java 7), if we announce the pattern and do the 3.4 release something like one month later (after checking that we don't need critical fix on 3.3), could match everybody's concern with such a plan decision, I could go for it Regards, Hervé Le dimanche 8 mars 2015 21:43:11 Robert Scholte a écrit : issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the Java7 decision. And that's fine by me. As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and call this Maven 3.4.0 A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth a 4.0.0 Also see previous releases when we moved forward to Java5 (M2.2) and Java6 (M3.2) Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana tibordig...@apache.org: @Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p582 85 22.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 - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - 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: move maven core to java 7?
I think we're spending far too much energy on this discussion. Roll back to 1.6/1.6 and make the 3.4 1.7. Kristian 2015-03-10 8:50 GMT+01:00 Hervé BOUTEMY herve.bout...@free.fr: Java 7, ie 3.2(Java 6)/3.3(Java 7+current changes) or Java 6, ie 3.2(Java 6)/3.3(Java 6+current changes)/3.4(Java 7, ~1 month later) ? Regards, Hervé Le lundi 9 mars 2015 09:35:30 Jason van Zyl a écrit : Yes, I'll leave it until Wednesday to see if anyone has any issues running master and then I'll stage the release. On Mar 8, 2015, at 6:42 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: notice that this would be a de-facto Maven versionning pattern: 2.0 (Java 1.4)/2.1(Java 1.4+changes)/2.2(Java 5) 3.0 (Java 5)/3.1(Java 5+changes)/3.2(Java 6) then 3.2(Java 6)/3.3(Java 6+changes)/3.4(Java 7), if we announce the pattern and do the 3.4 release something like one month later (after checking that we don't need critical fix on 3.3), could match everybody's concern with such a plan decision, I could go for it Regards, Hervé Le dimanche 8 mars 2015 21:43:11 Robert Scholte a écrit : issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the Java7 decision. And that's fine by me. As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and call this Maven 3.4.0 A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth a 4.0.0 Also see previous releases when we moved forward to Java5 (M2.2) and Java6 (M3.2) Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana tibordig...@apache.org: @Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p582 85 22.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 - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - 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: move maven core to java 7?
I agree we're spending too much energy but I don't plan to roll anything back. I do not want to support the rather large feature set change across 1.6 and 1.7 because it will be a huge maintenance burden. It's entirely unrealistic to try and support 1.6 and 1.7 given the activity in the core by so few. If we cut this release and then we switch to 1.7 the 3.3.0 will pretty much become instantly dead because I know we'll flip over to 1.7 features quickly and i doubt anyone is going to backport anything and there are likely going to be issues with all the new features and then a user is going to be forced to update anyway to get the fixes. If you want all the new features then too bad, upgrade to 3.3.0 and use 1.7. I really do not want to continue developing with 1.6 because I think it's a waste of time and energy. On Mar 10, 2015, at 12:56 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I think we're spending far too much energy on this discussion. Roll back to 1.6/1.6 and make the 3.4 1.7. Kristian 2015-03-10 8:50 GMT+01:00 Hervé BOUTEMY herve.bout...@free.fr: Java 7, ie 3.2(Java 6)/3.3(Java 7+current changes) or Java 6, ie 3.2(Java 6)/3.3(Java 6+current changes)/3.4(Java 7, ~1 month later) ? Regards, Hervé Le lundi 9 mars 2015 09:35:30 Jason van Zyl a écrit : Yes, I'll leave it until Wednesday to see if anyone has any issues running master and then I'll stage the release. On Mar 8, 2015, at 6:42 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: notice that this would be a de-facto Maven versionning pattern: 2.0 (Java 1.4)/2.1(Java 1.4+changes)/2.2(Java 5) 3.0 (Java 5)/3.1(Java 5+changes)/3.2(Java 6) then 3.2(Java 6)/3.3(Java 6+changes)/3.4(Java 7), if we announce the pattern and do the 3.4 release something like one month later (after checking that we don't need critical fix on 3.3), could match everybody's concern with such a plan decision, I could go for it Regards, Hervé Le dimanche 8 mars 2015 21:43:11 Robert Scholte a écrit : issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the Java7 decision. And that's fine by me. As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and call this Maven 3.4.0 A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth a 4.0.0 Also see previous releases when we moved forward to Java5 (M2.2) and Java6 (M3.2) Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana tibordig...@apache.org: @Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p582 85 22.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 - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A master in the art of living draws no sharp distinction between his work and his play; his labor and his leisure; his mind and his body; his education and his recreation. He hardly knows which is which. He simply pursues his
Re: move maven core to java 7?
Yes, I'll leave it until Wednesday to see if anyone has any issues running master and then I'll stage the release. On Mar 8, 2015, at 6:42 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: notice that this would be a de-facto Maven versionning pattern: 2.0 (Java 1.4)/2.1(Java 1.4+changes)/2.2(Java 5) 3.0 (Java 5)/3.1(Java 5+changes)/3.2(Java 6) then 3.2(Java 6)/3.3(Java 6+changes)/3.4(Java 7), if we announce the pattern and do the 3.4 release something like one month later (after checking that we don't need critical fix on 3.3), could match everybody's concern with such a plan decision, I could go for it Regards, Hervé Le dimanche 8 mars 2015 21:43:11 Robert Scholte a écrit : issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the Java7 decision. And that's fine by me. As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and call this Maven 3.4.0 A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth a 4.0.0 Also see previous releases when we moved forward to Java5 (M2.2) and Java6 (M3.2) Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana tibordig...@apache.org: @Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p58285 22.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 - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - A man enjoys his work when he understands the whole and when he is responsible for the quality of the whole -- Christopher Alexander, A Pattern Language - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
What's the rush? Releases are cheap and easy, so I find the argument to upgrade now due to one less release is somewhat lacking. Sent from my iPad On 9 Mar 2015, at 2:22 am, Dennis Lundberg denn...@apache.org wrote: Hi Igor, In my opinion the switch to Java 7 as a prerequisite is a non-risky thing to do, even though I still argue that we should wait till the next release to do it. Making use of the new Java 7 features in the code is the risky bit. That in my book warrants a minor release bump rather that a patch version bump. On Sat, Mar 7, 2015 at 2:45 PM, Igor Fedorenko i...@ifedorenko.com wrote: We changed version from 3.2.x to 3.3.x quite late in the release and this was the reason I proposed change to java 7. It allows us continue 3.3.x improvement and use new language features. Personally I believe changing compiler configuration to target java 7 is very unlikely to introduce regressions in Maven at this point, but I can understand if somebody wants to do additional validation. Making actual code changes just to show we use java 7 language features in 3.3.0 seems unnecessary risk, however. I think it makes more sense to release 3.3.0 as is, then do java 7 cleanup in 3.3.1. -- Regards, Igor On 2015-03-07 7:26, Hervé BOUTEMY wrote: Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit : There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: and before 2.1.0 vs 2.2.0 and the only cause (IIRC) is that we had a schedule, then thought it would be good to upgrade, but didn't change the schedule to have 1 to 2 weeks to test if we decide to take 2 weeks to integrate some improvements that the upgrade permits and test, would the upgrade to 3.3.0 be ok? Regards, Hervé we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Dennis
Re: move maven core to java 7?
So let's say that Dennis and I have our concerns. The discussion about versions seems more about marketing versions. If the current added features are minor incremental worthy AND Java Runtime change to version 7 is also minor incremental worthy, then so be it. I wouldn't call 3.3.0 a dead end, it's just following the concept of versioning. If 3.3.0 will require Java7 without any additional changes, it's just Java 7 in name, just because source+target were pushed to 1.7, whereas 1.6 would have been fine as well. I'd prefer to do the source+target change right after the official release of M3.3.0, which should give us enough time to test it thorough. Be aware that with this choice we're going to reduce the number of supported JDKs to 2, namely Java7 and Java8. I would really like to see that we support the three latest versions, so drop Java6 once Java9 has been officially released. This implies that EOL's are less interesting to me. thanks, Robert Op Sun, 08 Mar 2015 19:38:31 +0100 schreef Stephen Connolly stephen.alan.conno...@gmail.com: I have a biased data point to throw into the mix: pleading The Jenkins project would really like to ditch support for running on Java 6. When Maven releases a version that requires Java 7, and Olivier updates the evil plugin to use the new Maven dependencies, then Jenkins can force through dropping support for Java 6. If all this can happen before May's LTS this year then I will be very happy because that means in May 2016 I will no longer have to support CloudBees customers running Java 6. To get into the LTS that means we need a Maven release this month to allow sufficient soak. /pleading I don't buy Dennis' arg re wait until 3.4.0. To my mind if we are not bumping to Java 7 then this release should be 3.2.6 not 3.3.0... If we are calling it 3.3.0 then it should be Java 7+ in my mind On Sunday, March 8, 2015, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 8 mars 2015 16:17:39 Dennis Lundberg a écrit : On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY herve.bout...@free.fr javascript:; wrote: There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) That is the normal state in open source software. Not many people will volunteer to backport bugfixes to older release lines. It's a matter of putting your limited resources where it does most good, and also where your itch is. Usually this means working on HEAD. I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) I'm not concerned that switching to Java 7 will introduce any new bugs in core, at least not until we start using new Java 7 features. What we should do is think about what is best for our users. Let's look at the pros and cons of the two alternatives: 1. Switch to Java 7 for Maven 3.3.0 Bad: Users that are restricted to Java 6 for some reason will not be able to benefit from the bug fixes and new features in 3.3.0 Good: One less release to make Good: people (few?) who really need new Maven features on old Java will learn to use Toolchains 2. Switch to Java 7 for Maven 3.4.0 Bad: One more release to make Good: Users that are restricted to Java 6 for some reason will benefit from the bug fixes and new features in 3.3.0, even though they might not get any more bugfixes on that release line, because work focus move to 3.4.0-SNAPSHOT as soon as 3.3.0 has been released Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and
Re: move maven core to java 7?
@Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828522.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: move maven core to java 7?
I have a biased data point to throw into the mix: pleading The Jenkins project would really like to ditch support for running on Java 6. When Maven releases a version that requires Java 7, and Olivier updates the evil plugin to use the new Maven dependencies, then Jenkins can force through dropping support for Java 6. If all this can happen before May's LTS this year then I will be very happy because that means in May 2016 I will no longer have to support CloudBees customers running Java 6. To get into the LTS that means we need a Maven release this month to allow sufficient soak. /pleading I don't buy Dennis' arg re wait until 3.4.0. To my mind if we are not bumping to Java 7 then this release should be 3.2.6 not 3.3.0... If we are calling it 3.3.0 then it should be Java 7+ in my mind On Sunday, March 8, 2015, Hervé BOUTEMY herve.bout...@free.fr wrote: Le dimanche 8 mars 2015 16:17:39 Dennis Lundberg a écrit : On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY herve.bout...@free.fr javascript:; wrote: There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) That is the normal state in open source software. Not many people will volunteer to backport bugfixes to older release lines. It's a matter of putting your limited resources where it does most good, and also where your itch is. Usually this means working on HEAD. I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) I'm not concerned that switching to Java 7 will introduce any new bugs in core, at least not until we start using new Java 7 features. What we should do is think about what is best for our users. Let's look at the pros and cons of the two alternatives: 1. Switch to Java 7 for Maven 3.3.0 Bad: Users that are restricted to Java 6 for some reason will not be able to benefit from the bug fixes and new features in 3.3.0 Good: One less release to make Good: people (few?) who really need new Maven features on old Java will learn to use Toolchains 2. Switch to Java 7 for Maven 3.4.0 Bad: One more release to make Good: Users that are restricted to Java 6 for some reason will benefit from the bug fixes and new features in 3.3.0, even though they might not get any more bugfixes on that release line, because work focus move to 3.4.0-SNAPSHOT as soon as 3.3.0 has been released Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com javascript:;: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org javascript:;: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components
Re: move maven core to java 7?
issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the Java7 decision. And that's fine by me. As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and call this Maven 3.4.0 A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth a 4.0.0 Also see previous releases when we moved forward to Java5 (M2.2) and Java6 (M3.2) Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana tibordig...@apache.org: @Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828522.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
On 2015-03-08 9:35, Tibor Digana wrote: @Igor Would you introduce trully incremental compiler with JDT? I guess the surefire would need the interface from core or compiler to be notified about modified tests in order to execute only those. Incremental test execution requires full impact analysis and is far more complicated problem than tracking recompiled classes. For example, changes to a method body in a main class does not result in recompilcation of any other classes, main or test. You'd need to build full dependency graph of all classes to tell what tests are affected by the change. Then you have reflection, dependency injection, changes to resources. Knowing what classes are recompiled is not nearly enough. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
Java SE 7 Features and Enhancements http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828456.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: move maven core to java 7?
+ 1, Java SE 7 Looking for changes in our plugins as well. For instance Java 7 introduced a new utility class java.util.Objects. I found this very useful : java.util.Objects.requireNonNull() in offensive programming in constructors java.util.Objects.equals() java.util.Objects.hashCode() java.io.Closeable For instance many people still use the old style of Java 1.4/1.5 which we can rewrite = to Java 6 : String.length() == 0 = String.isEmpty() return Boolean.TRUE; = return true; (java 5 autoboxing) Collections.synchronizedList() = CopyOnWriteArrayList / ConcurrentLinkedQueue (java 5 java.util.concurrent.*) Arrays.copyOf() Arrays.copyOfRange() java.util.LinkedList : Deque (see the methods of Deque) @Igor Would you introduce trully incremental compiler with JDT? I guess the surefire would need the interface from core or compiler to be notified about modified tests in order to execute only those. -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828450.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: move maven core to java 7?
Just for the record; we already use most of the important java7 stuff through reflection if it is available (and we have been doing this for several years). So the language features are really the only thing we're missing. The improved generics are /great/, try with resources are ok and multicatch sometimes make things nicer. But none of this is really ground-shaking stuff like jdk8. Kristian 2015-03-08 14:41 GMT+01:00 Tibor Digana tibordig...@apache.org: Java SE 7 Features and Enhancements http://www.oracle.com/technetwork/java/javase/jdk7-relnotes-418459.html -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828456.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: move maven core to java 7?
notice that this would be a de-facto Maven versionning pattern: 2.0 (Java 1.4)/2.1(Java 1.4+changes)/2.2(Java 5) 3.0 (Java 5)/3.1(Java 5+changes)/3.2(Java 6) then 3.2(Java 6)/3.3(Java 6+changes)/3.4(Java 7), if we announce the pattern and do the 3.4 release something like one month later (after checking that we don't need critical fix on 3.3), could match everybody's concern with such a plan decision, I could go for it Regards, Hervé Le dimanche 8 mars 2015 21:43:11 Robert Scholte a écrit : issues for 3.2.6 have already been pushed forward to 3.3.0 *before* the Java7 decision. And that's fine by me. As Dennis already suggested: after 3.3.0 push JDK requirement to 1.7 and call this Maven 3.4.0 A JDK requirement has too much impact for a 3.3.1, but IMHO it's not worth a 4.0.0 Also see previous releases when we moved forward to Java5 (M2.2) and Java6 (M3.2) Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana tibordig...@apache.org: @Robert source=target=1.7 after M3.3.0? You mean 3.3.1? A bit strange to make it in an incremental version since a user would not imaging a fix version to break the system requirements in his CI regarding JDK installation. Currently the release notes for 3.2.6 is empty. So if there's really nothing to fix in 3.2.6, I would suggest to jump to 3.3.0 with JDK 7. http://jira.codehaus.org/browse/MNG/fixforversion/20821 -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p58285 22.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 - 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: move maven core to java 7?
On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) That is the normal state in open source software. Not many people will volunteer to backport bugfixes to older release lines. It's a matter of putting your limited resources where it does most good, and also where your itch is. Usually this means working on HEAD. I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) I'm not concerned that switching to Java 7 will introduce any new bugs in core, at least not until we start using new Java 7 features. What we should do is think about what is best for our users. Let's look at the pros and cons of the two alternatives: 1. Switch to Java 7 for Maven 3.3.0 Bad: Users that are restricted to Java 6 for some reason will not be able to benefit from the bug fixes and new features in 3.3.0 Good: One less release to make 2. Switch to Java 7 for Maven 3.4.0 Bad: One more release to make Good: Users that are restricted to Java 6 for some reason will benefit from the bug fixes and new features in 3.3.0, even though they might not get any more bugfixes on that release line, because work focus move to 3.4.0-SNAPSHOT as soon as 3.3.0 has been released Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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 -- Dennis Lundberg - To unsubscribe, e-mail:
Re: move maven core to java 7?
Le dimanche 8 mars 2015 16:17:39 Dennis Lundberg a écrit : On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) That is the normal state in open source software. Not many people will volunteer to backport bugfixes to older release lines. It's a matter of putting your limited resources where it does most good, and also where your itch is. Usually this means working on HEAD. I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) I'm not concerned that switching to Java 7 will introduce any new bugs in core, at least not until we start using new Java 7 features. What we should do is think about what is best for our users. Let's look at the pros and cons of the two alternatives: 1. Switch to Java 7 for Maven 3.3.0 Bad: Users that are restricted to Java 6 for some reason will not be able to benefit from the bug fixes and new features in 3.3.0 Good: One less release to make Good: people (few?) who really need new Maven features on old Java will learn to use Toolchains 2. Switch to Java 7 for Maven 3.4.0 Bad: One more release to make Good: Users that are restricted to Java 6 for some reason will benefit from the bug fixes and new features in 3.3.0, even though they might not get any more bugfixes on that release line, because work focus move to 3.4.0-SNAPSHOT as soon as 3.3.0 has been released Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor --- -- 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: move maven core to java 7?
Let me re-phrase that; what are the benefits/downsides of using annotation processors instead of SPI/plexus ? Kristian 2015-03-08 15:43 GMT+01:00 Kristian Rosenvold kristian.rosenv...@gmail.com : i think an API makes total sense for surefire. I'm not sure about the merits of annotation processors vs SPI or regular plexus components ? Kristian 2015-03-08 15:32 GMT+01:00 Tibor Digana tibordig...@apache.org: Kristian, you probably mean our utilies which switch implementations by java version. Yes, Java 8 is the lastest and greatest to have; But in my own company does not have the confidence to use java 8 even after my trainings incorporating Java 8 features into the projects. BTW, I would like to test a prototype with injection of implemented Surefire API by a user with the help of Annotation Processor. @Component public class CustomRunOrder implement RunOrderCalculator Does it make sense to you or should I give it up? -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828468.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: move maven core to java 7?
The breaking thing is the new prerequisite of Java 7 which would exclude some of our users. On Sun, Mar 8, 2015 at 12:05 AM, Igor Fedorenko i...@ifedorenko.com wrote: How is this a breaking change? All plugins that worked with 3.2.5 are expected to work as is. All projects that built with 3.2.5 are expected to build. -- Regards, Igor On 2015-03-07 17:35, Tibor Digana wrote: (Replying on this thread from my mail server does not work for me) Usually the opensource projects change the major version, to 4.0.0, if breaking the commpatibility with previous release. So why we don't do that? Listing features of Java SE 7 that we may use: try-catch-resources Strings in switch Statements Catching Multiple Exceptions @SafeVarargs Underscores in Numeric Literals Multithreaded Custom Class Loader Closing a URLClassLoader (URLClassLoader.close()) IO and New IO (File Attributes, FileChannel.transferTo()) isLink() is utils Operating on Zip File System Provider http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html Memory File System http://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html Remote Direct Memory Access (RDMA) SDP AsynchronousSocketChannel https://blogs.oracle.com/alanb/entry/sockets_direct_protocol -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828390.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 - 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: move maven core to java 7?
Kristian, you probably mean our utilies which switch implementations by java version. Yes, Java 8 is the lastest and greatest to have; But in my own company does not have the confidence to use java 8 even after my trainings incorporating Java 8 features into the projects. BTW, I would like to test a prototype with injection of implemented Surefire API by a user with the help of Annotation Processor. @Component public class CustomRunOrder implement RunOrderCalculator Does it make sense to you or should I give it up? -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828468.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: move maven core to java 7?
i think an API makes total sense for surefire. I'm not sure about the merits of annotation processors vs SPI or regular plexus components ? Kristian 2015-03-08 15:32 GMT+01:00 Tibor Digana tibordig...@apache.org: Kristian, you probably mean our utilies which switch implementations by java version. Yes, Java 8 is the lastest and greatest to have; But in my own company does not have the confidence to use java 8 even after my trainings incorporating Java 8 features into the projects. BTW, I would like to test a prototype with injection of implemented Surefire API by a user with the help of Annotation Processor. @Component public class CustomRunOrder implement RunOrderCalculator Does it make sense to you or should I give it up? -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828468.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: move maven core to java 7?
As you said, the SPI did not work well in multimodule project.
You tested SPI in Maven, so you know better than me :)
With JSR-269 with can use javax.inject:javax-inject annotations and we the
user can use non-default constructor. Imaging this in user, our processor is
sensitive only in SurefireComponent-s:
(the first experimental version may sleep well without @Inject etc.)
@SurefireComponent
public class CustomRunOrder implement RunOrderCalculator {
CustomRunOrder(@Inject MavenProject mp) {...}
...
}
Our API:
@Qualifier
public @interface SurefireComponent
Later we can introduce Scopes:
@Scope
@Retention(RUNTIME)
public @interface ForkedScoped
@Scope
@Retention(RUNTIME)
public @interface InProcessScoped
--
View this message in context:
http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828481.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: move maven core to java 7?
Hi Igor, In my opinion the switch to Java 7 as a prerequisite is a non-risky thing to do, even though I still argue that we should wait till the next release to do it. Making use of the new Java 7 features in the code is the risky bit. That in my book warrants a minor release bump rather that a patch version bump. On Sat, Mar 7, 2015 at 2:45 PM, Igor Fedorenko i...@ifedorenko.com wrote: We changed version from 3.2.x to 3.3.x quite late in the release and this was the reason I proposed change to java 7. It allows us continue 3.3.x improvement and use new language features. Personally I believe changing compiler configuration to target java 7 is very unlikely to introduce regressions in Maven at this point, but I can understand if somebody wants to do additional validation. Making actual code changes just to show we use java 7 language features in 3.3.0 seems unnecessary risk, however. I think it makes more sense to release 3.3.0 as is, then do java 7 cleanup in 3.3.1. -- Regards, Igor On 2015-03-07 7:26, Hervé BOUTEMY wrote: Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit : There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: and before 2.1.0 vs 2.2.0 and the only cause (IIRC) is that we had a schedule, then thought it would be good to upgrade, but didn't change the schedule to have 1 to 2 weeks to test if we decide to take 2 weeks to integrate some improvements that the upgrade permits and test, would the upgrade to 3.3.0 be ok? Regards, Hervé we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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
Re: move maven core to java 7?
Le vendredi 6 mars 2015 08:33:27 Anders Hammar a écrit : What I'd like to stress here is that we're talking about Maven core, not our plugins. We've had a separate discussion/thread for the plugins and for those we've decided to go with a Java 6 requirement. As plugins were mentioned in this thread as well I want to make sure there is no misunderstanding. yes, we're only talking about core: plugins require another discussion and befoire discussing plugins, we need to really finish the core discussion :) Regards, Hervé /Anders (mobile) Den 6 mar 2015 00:37 skrev Jason van Zyl ja...@takari.io: Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: move maven core to java 7?
Le samedi 7 mars 2015 13:26:36 Hervé BOUTEMY a écrit : Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit : There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: and before 2.1.0 vs 2.2.0 Since we're having 2 discussions in parallel for choices about future compatibility between Java + Maven + plugins versions, I tried to make a little drawing to illustrate the topic: http://people.apache.org/~hboutemy/Maven%20Versions.png (transparency represents current level of support, or more precisely is the inverse of support) In this drawing, we have the little 2.1 and 3.1 versions: I'd prefer avoiding a little 3.3 Or we tell people that even minor versions are the most stable versions to use. While at it, I'll do a little bit of advertising :) this drawing not only happens because of our discussion, but it's also because I'm preparing a talk with Arnaud Héritier for Devoxx France, in April in Paris, about Java versions and Maven tooling to build for multiple Java versions: animal sniffer, toolchains, ... http://cfp.devoxx.fr/2015/talk/FEM-9840/Quand_Java_prend_de_la_vitesse,_Apache_Maven_vous_garde_sur_les_rails We'll do it in french, sorry for non-french speaking people :) If some Maven dev wants to make a talk about this, don't hesitate to contact Arnaud and I: we can share the slides (while creating them) and help translating. It would be interesting to have multiple Maven devs doing the same talk in multiple languages and countries Regards, Hervé - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
We changed version from 3.2.x to 3.3.x quite late in the release and this was the reason I proposed change to java 7. It allows us continue 3.3.x improvement and use new language features. Personally I believe changing compiler configuration to target java 7 is very unlikely to introduce regressions in Maven at this point, but I can understand if somebody wants to do additional validation. Making actual code changes just to show we use java 7 language features in 3.3.0 seems unnecessary risk, however. I think it makes more sense to release 3.3.0 as is, then do java 7 cleanup in 3.3.1. -- Regards, Igor On 2015-03-07 7:26, Hervé BOUTEMY wrote: Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit : There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: and before 2.1.0 vs 2.2.0 and the only cause (IIRC) is that we had a schedule, then thought it would be good to upgrade, but didn't change the schedule to have 1 to 2 weeks to test if we decide to take 2 weeks to integrate some improvements that the upgrade permits and test, would the upgrade to 3.3.0 be ok? Regards, Hervé we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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 - 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: move maven core to java 7?
Le samedi 7 mars 2015 08:45:37 Igor Fedorenko a écrit : We changed version from 3.2.x to 3.3.x quite late in the release yes, let's be fair :) and this was the reason I proposed change to java 7. It allows us continue 3.3.x improvement and use new language features. Personally I believe changing compiler configuration to target java 7 is very unlikely to introduce regressions in Maven at this point, but I can understand if somebody wants to do additional validation. Making actual code changes just to show we use java 7 language features in 3.3.0 seems unnecessary risk, however. I think it makes more sense to release 3.3.0 as is, then do java 7 cleanup in 3.3.1. good point +1 Regards, Hervé -- Regards, Igor On 2015-03-07 7:26, Hervé BOUTEMY wrote: Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit : There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: and before 2.1.0 vs 2.2.0 and the only cause (IIRC) is that we had a schedule, then thought it would be good to upgrade, but didn't change the schedule to have 1 to 2 weeks to test if we decide to take 2 weeks to integrate some improvements that the upgrade permits and test, would the upgrade to 3.3.0 be ok? Regards, Hervé we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
great: can you give us a pointer? if we upgrade to Java 7, having these improvements would be more interesting than waiting the next patch release the idea of Java 7 upgrade came quite late on the release schedule, and IMHO these updates are worth one more release testing Regards, Hervé Le vendredi 6 mars 2015 13:54:03 Kristian Rosenvold a écrit : I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
I deliberately kept the change in github to give the discussion a little time. Personally I dont really mind waiting, but I really believe we're wasting far too much energy on legacy java versions. It's not as if java6 users dont have a working version. And they can pay people to backport stuff they need. This is just a small fraction of the cost of running on legacy versions if software, they should be used to it. K 7. mars 2015 12:05 skrev Dennis Lundberg denn...@apache.org: Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit : There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: and before 2.1.0 vs 2.2.0 and the only cause (IIRC) is that we had a schedule, then thought it would be good to upgrade, but didn't change the schedule to have 1 to 2 weeks to test if we decide to take 2 weeks to integrate some improvements that the upgrade permits and test, would the upgrade to 3.3.0 be ok? Regards, Hervé we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. what I don't like with this plan is that it is exactly what happened with 3.1.1 then 3.2.1: we never did any bugfix for 3.1.1, 3.1.1 was a dead branch for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who will ever do that? (not me...) I agree that the lack of schedule can be a problem if we decide to make the release this week-end: but if we take one week to integrate Java 7 improvements (ie mostly syntax for better maintainability and a few new APIs) and take one week after that to test the result, IMHO we get a better plan: a new Maven version, with features and the assurance we'll do bugfix releases on it (the fact that it has upgraded Java requirement is just a fact on release notes) Regards, Hervé Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit : Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
+1 Le samedi 7 mars 2015 13:09:35 Kristian Rosenvold a écrit : I deliberately kept the change in github to give the discussion a little time. Personally I dont really mind waiting, but I really believe we're wasting far too much energy on legacy java versions. It's not as if java6 users dont have a working version. And they can pay people to backport stuff they need. This is just a small fraction of the cost of running on legacy versions if software, they should be used to it. K 7. mars 2015 12:05 skrev Dennis Lundberg denn...@apache.org: Hi Kristian, Please note that I am not opposed to using Java 7 in the core. What I am objecting to is the planning, or rather the lack of it. We currently have core ready to be released on Java 6. Then just before it is about to be released someone says, hey lets switch Java version as well. IMO that is something you should plan for before work is even started on the next release. Then there is the agreement we made regarding Java versions and their EOL. Switching to Java 7 before the release will mean that a fewer number of users will be able to reap the benefits of the bugfixes and features in Maven 3.3.0. There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0 on Java 7 in a few weeks. Weighing in all of this I don't see any reason to change the Java version for 3.3.0. Den 6 mar 2015 13:54 skrev Kristian Rosenvold kristian.rosenv...@gmail.com: I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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
move maven core to java 7
Usually the opensource projects change the major version, to 4.0.0, if breaking the commpatibility with previous release. So why we don't do that? Listing features of Java SE 7 that we may use: try-catch-resources Strings in switch Statements Catching Multiple Exceptions @SafeVarargs Underscores in Numeric Literals Multithreaded Custom Class Loader Closing a URLClassLoader (URLClassLoader.close()) IO and New IO (File Attributes, FileChannel.transferTo()) isLink() is utils Operating on Zip File System Provider http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html Memory File System http://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html Remote Direct Memory Access (RDMA) SDP AsynchronousSocketChannel https://blogs.oracle.com/alanb/entry/sockets_direct_protocol -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5828386.html Sent from the Maven Developers mailing list archive at Nabble.com.
Re: move maven core to java 7?
How is this a breaking change? All plugins that worked with 3.2.5 are expected to work as is. All projects that built with 3.2.5 are expected to build. -- Regards, Igor On 2015-03-07 17:35, Tibor Digana wrote: (Replying on this thread from my mail server does not work for me) Usually the opensource projects change the major version, to 4.0.0, if breaking the commpatibility with previous release. So why we don't do that? Listing features of Java SE 7 that we may use: try-catch-resources Strings in switch Statements Catching Multiple Exceptions @SafeVarargs Underscores in Numeric Literals Multithreaded Custom Class Loader Closing a URLClassLoader (URLClassLoader.close()) IO and New IO (File Attributes, FileChannel.transferTo()) isLink() is utils Operating on Zip File System Provider http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html Memory File System http://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html Remote Direct Memory Access (RDMA) SDP AsynchronousSocketChannel https://blogs.oracle.com/alanb/entry/sockets_direct_protocol -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828390.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
Sorry, I am not following. The current majority agreement is to change compiler target level together with maven core minor version change from 3.2.x to 3.3.0. Then we can gradually introduce java 7 features in future 3.3.x releases. This way to avoid dead-end 3.3.0 release immediately followed by 3.4.x line of releases. -- Regards, Igor On 2015-03-07 18:23, Tibor Digana wrote: @Igor How about Java SE 7 features? If we change the compiler version, adapting compiler without introducing new Java API features would not make any difference in 3.4.0. Any thoughts? -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828398.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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
@Igor How about Java SE 7 features? If we change the compiler version, adapting compiler without introducing new Java API features would not make any difference in 3.4.0. Any thoughts? -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828398.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: move maven core to java 7?
(Replying on this thread from my mail server does not work for me) Usually the opensource projects change the major version, to 4.0.0, if breaking the commpatibility with previous release. So why we don't do that? Listing features of Java SE 7 that we may use: try-catch-resources Strings in switch Statements Catching Multiple Exceptions @SafeVarargs Underscores in Numeric Literals Multithreaded Custom Class Loader Closing a URLClassLoader (URLClassLoader.close()) IO and New IO (File Attributes, FileChannel.transferTo()) isLink() is utils Operating on Zip File System Provider http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html Memory File System http://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html Remote Direct Memory Access (RDMA) SDP AsynchronousSocketChannel https://blogs.oracle.com/alanb/entry/sockets_direct_protocol -- View this message in context: http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828390.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: move maven core to java 7?
Did I object something? :-) -- Olivier On 6 Mar 2015 21:19, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We are CTR not RTC If you object to the change, veto the commit On 6 March 2015 at 07:44, Olivier Lamy ol...@apache.org wrote: +1 I just find the change/discussion a bit too fast. You should wait longer than ~10h as the world has more timezone. IMHO waiting for the answer from various members of the community is more like 2/3 days. Cheers -- Olivier On 6 Mar 2015 10:37, Jason van Zyl ja...@takari.io wrote: Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
Re: move maven core to java 7?
IMO this Java version bump should be reflected in a minor Maven version bump as opposed to a maintenance release. Gary On Fri, Mar 6, 2015 at 12:09 AM, Anders Hammar and...@hammar.net wrote: Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. Please create a JIRA ticket for this to make things clear in the release notes. /Anders On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action
Re: move maven core to java 7?
I created MNG-5780 to track the change I let the issue open, because I hope that we won't have to revert the commit after someone steps in with a strong reason not to upgrade But in 48h, if nobody votes -1 woth a strong issue, I'll close the issue and point to the (a little bit too quick at the moment) commit Regards, Hervé - Mail original - De: Stephen Connolly stephen.alan.conno...@gmail.com À: Maven Developers List dev@maven.apache.org Envoyé: Vendredi 6 Mars 2015 11:18:56 Objet: Re: move maven core to java 7? We are CTR not RTC If you object to the change, veto the commit On 6 March 2015 at 07:44, Olivier Lamy ol...@apache.org wrote: +1 I just find the change/discussion a bit too fast. You should wait longer than ~10h as the world has more timezone. IMHO waiting for the answer from various members of the community is more like 2/3 days. Cheers -- Olivier On 6 Mar 2015 10:37, Jason van Zyl ja...@takari.io wrote: Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http
Re: move maven core to java 7?
Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
I already have the full jdk7 port in a branch in github, so that assumption does not hold :) Kristian 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org: Hi, If we are going to release 3.3.0 very soon, like this week or the next, there won't be any time to start using Java 7 features in the 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and announce, in the 3.3.0 release notes, that the 3.3.x line is the last line that will work with Java 6. Depending on what the core developers want to focus on after the 3.3.0 release is done, the core can either go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This would also be consistent with our policy [1] for plugins/components wanting to move to a higher major Java version, in that we should release what we currently have in trunk before upgrading to a higher major Java version. My votes are: -1 for Java 7 in 3.3.0 +1 for Java 7 in 3.4.0 [1] http://maven.apache.org/developers/java6.html On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
We are CTR not RTC If you object to the change, veto the commit On 6 March 2015 at 07:44, Olivier Lamy ol...@apache.org wrote: +1 I just find the change/discussion a bit too fast. You should wait longer than ~10h as the world has more timezone. IMHO waiting for the answer from various members of the community is more like 2/3 days. Cheers -- Olivier On 6 Mar 2015 10:37, Jason van Zyl ja...@takari.io wrote: Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
+1 On Thu, Mar 5, 2015 at 8:16 AM, Igor Fedorenko i...@ifedorenko.com wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. Please create a JIRA ticket for this to make things clear in the release notes. /Anders On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
+1 for the upgrade On Thu, Mar 5, 2015 at 7:53 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: +1 (both for the move to java 7, Robert's concerns and Stephen justification) another reason: the next Maven core minor version bump isn't expected before a while let's use the 3.3.0 minor version choice done on Maven features be used on this internal JDK choice update too Regards, Hervé Le jeudi 5 mars 2015 08:14:57 Jason van Zyl a écrit : Robert, I think it's reasonable at this point to move to Java 1.7. I'd really prefer to use new features and given Java 1.7 is about to be EOL'd I don't think it's very practical staying on Java 1.6. On Mar 5, 2015, at 8:09 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We never got a final official policy. I believe the consensus was at least: * all Java versions currently supported by Oracle and one back on a Major version bump. I think we should go with all Java versions currently supported by Oracle on a Minor version bump... but there was some grumbling from Chris and I didn't want to fracture the community at the time. I think with Oracle being more strict it is reasonable that we start moving on up. Thus if we are to have a policy I would say that every minor version release is supposed to work with any version line of Java that was under public free support by Oracle at the time of the first release in our minor version line. Or in other words, 3.3.x would be JDK7 JDK8 (it may work with JDK9 but we cannot know until that is released) Moving our base JDK up will allow us to compile with JDK7 bytecode which will improve startup performance according to the rumours I have heard. On 5 March 2015 at 15:53, Jason van Zyl ja...@takari.io wrote: Stephen, as the keeper of long discussions we've had about JDK versions what did we actually decide a while back? On Mar 5, 2015, at 7:43 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 On 5 March 2015 at 12:19, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - 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 -- - Arnaud Héritier http://aheritier.net Mail/GTalk: aheritier AT gmail DOT com Twitter/Skype : aheritier
Re: move maven core to java 7?
On 2015-03-05 14:12, Kristian Rosenvold wrote: Actually Files.walkFileTree is just about the only NIO 7 feature we're not using. Anyone have any specific pointers/experience that actually show this being faster than the current strategy ? I ran some tests about a year ago on a large 200K files source tree and back then convinced myself Files.walkFileTree was noticeably faster. That test was on linux. Today I tried to reproduce the same results on osx and coulnd't, walking directory using new and old-style io perform about the same. Sorry for the misinformation. -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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: move maven core to java 7?
My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
Op Thu, 05 Mar 2015 14:16:24 +0100 schreef Igor Fedorenko i...@ifedorenko.com: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. IIUC Kristian already made it possible in plexus-utils to pick up these java7 NIO features when using that JRE version. Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. I think last time the trigger wasn't the EOL of JDK6 but the availability of JDK8 which made us move forward. So in this case: once JDK9 is available for all, we could move forward. -- Regards, Igor Let me add another link: https://gradle.org/docs/current/userguide/installation.html This doesn't have to be an issue, but I can imagine that new users will first of all select a tool which matches their JDK. There are plenty of reasons why to choose for one or the other. First of all I'd like to approach this from a user perspective, not because we can, otherwise we should use the latest JDK ASAP. If we do indeed get that remarkable performance improvement, then that would be a good reason to move to JDK7 for me. Robert On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
+1 On Mar 5, 2015, at 4:19 AM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - The modern conservative is engaged in one of man's oldest exercises in moral philosophy; that is, the search for a superior moral justification for selfishness. -- John Kenneth Galbraith - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
We never got a final official policy. I believe the consensus was at least: * all Java versions currently supported by Oracle and one back on a Major version bump. I think we should go with all Java versions currently supported by Oracle on a Minor version bump... but there was some grumbling from Chris and I didn't want to fracture the community at the time. I think with Oracle being more strict it is reasonable that we start moving on up. Thus if we are to have a policy I would say that every minor version release is supposed to work with any version line of Java that was under public free support by Oracle at the time of the first release in our minor version line. Or in other words, 3.3.x would be JDK7 JDK8 (it may work with JDK9 but we cannot know until that is released) Moving our base JDK up will allow us to compile with JDK7 bytecode which will improve startup performance according to the rumours I have heard. On 5 March 2015 at 15:53, Jason van Zyl ja...@takari.io wrote: Stephen, as the keeper of long discussions we've had about JDK versions what did we actually decide a while back? On Mar 5, 2015, at 7:43 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 On 5 March 2015 at 12:19, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
Stephen, as the keeper of long discussions we've had about JDK versions what did we actually decide a while back? On Mar 5, 2015, at 7:43 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 On 5 March 2015 at 12:19, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
Robert, I think it's reasonable at this point to move to Java 1.7. I'd really prefer to use new features and given Java 1.7 is about to be EOL'd I don't think it's very practical staying on Java 1.6. On Mar 5, 2015, at 8:09 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We never got a final official policy. I believe the consensus was at least: * all Java versions currently supported by Oracle and one back on a Major version bump. I think we should go with all Java versions currently supported by Oracle on a Minor version bump... but there was some grumbling from Chris and I didn't want to fracture the community at the time. I think with Oracle being more strict it is reasonable that we start moving on up. Thus if we are to have a policy I would say that every minor version release is supposed to work with any version line of Java that was under public free support by Oracle at the time of the first release in our minor version line. Or in other words, 3.3.x would be JDK7 JDK8 (it may work with JDK9 but we cannot know until that is released) Moving our base JDK up will allow us to compile with JDK7 bytecode which will improve startup performance according to the rumours I have heard. On 5 March 2015 at 15:53, Jason van Zyl ja...@takari.io wrote: Stephen, as the keeper of long discussions we've had about JDK versions what did we actually decide a while back? On Mar 5, 2015, at 7:43 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 On 5 March 2015 at 12:19, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
+1 On 5 March 2015 at 12:19, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
+1 (both for the move to java 7, Robert's concerns and Stephen justification) another reason: the next Maven core minor version bump isn't expected before a while let's use the 3.3.0 minor version choice done on Maven features be used on this internal JDK choice update too Regards, Hervé Le jeudi 5 mars 2015 08:14:57 Jason van Zyl a écrit : Robert, I think it's reasonable at this point to move to Java 1.7. I'd really prefer to use new features and given Java 1.7 is about to be EOL'd I don't think it's very practical staying on Java 1.6. On Mar 5, 2015, at 8:09 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We never got a final official policy. I believe the consensus was at least: * all Java versions currently supported by Oracle and one back on a Major version bump. I think we should go with all Java versions currently supported by Oracle on a Minor version bump... but there was some grumbling from Chris and I didn't want to fracture the community at the time. I think with Oracle being more strict it is reasonable that we start moving on up. Thus if we are to have a policy I would say that every minor version release is supposed to work with any version line of Java that was under public free support by Oracle at the time of the first release in our minor version line. Or in other words, 3.3.x would be JDK7 JDK8 (it may work with JDK9 but we cannot know until that is released) Moving our base JDK up will allow us to compile with JDK7 bytecode which will improve startup performance according to the rumours I have heard. On 5 March 2015 at 15:53, Jason van Zyl ja...@takari.io wrote: Stephen, as the keeper of long discussions we've had about JDK versions what did we actually decide a while back? On Mar 5, 2015, at 7:43 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: +1 On 5 March 2015 at 12:19, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - 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: move maven core to java 7?
2015-03-05 17:26 GMT+01:00 Robert Scholte rfscho...@apache.org: Op Thu, 05 Mar 2015 14:16:24 +0100 schreef Igor Fedorenko i...@ifedorenko.com: Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. IIUC Kristian already made it possible in plexus-utils to pick up these java7 NIO features when using that JRE version. Actually Files.walkFileTree is just about the only NIO 7 feature we're not using. Anyone have any specific pointers/experience that actually show this being faster than the current strategy ? I think the simplified generics alone are more than enough of a feature to use java7. If you're restricted to java6 you might as well stay on an old maven version too... Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
+1 :) K 2015-03-05 13:27 GMT+01:00 Anders Hammar and...@hammar.net: I think this is what we decided on - support latest and one prior released JDK version. IF we do, we need to update the README file in the distro as well as the system requirements page online. /Anders On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
+1 -- Thanks, ~t~ On 5 Mar 2015 at 13:28:25, Anders Hammar (and...@hammar.net) wrote: I think this is what we decided on - support latest and one prior released JDK version. IF we do, we need to update the README file in the distro as well as the system requirements page online. /Anders On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
move maven core to java 7?
With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
I think this is what we decided on - support latest and one prior released JDK version. IF we do, we need to update the README file in the distro as well as the system requirements page online. /Anders On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor - 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: move maven core to java 7?
What I'd like to stress here is that we're talking about Maven core, not our plugins. We've had a separate discussion/thread for the plugins and for those we've decided to go with a Java 6 requirement. As plugins were mentioned in this thread as well I want to make sure there is no misunderstanding. /Anders (mobile) Den 6 mar 2015 00:37 skrev Jason van Zyl ja...@takari.io: Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: move maven core to java 7?
+1 I just find the change/discussion a bit too fast. You should wait longer than ~10h as the world has more timezone. IMHO waiting for the answer from various members of the community is more like 2/3 days. Cheers -- Olivier On 6 Mar 2015 10:37, Jason van Zyl ja...@takari.io wrote: Ok, the consensus is to move forward to Java7. I updated the POM and we're in no rush so give it a whirl and we can think about releasing next week if the world doesn't blow up. On Mar 5, 2015, at 2:32 PM, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello there, I would go for JDK7 as well, in April it will be EOLed anyway. I do not understand why someone who is forced to use JDK6 or let alone JDK5 is allowed (or has) to use the newest versions of build tools BTW. IMO it is stressful enough to support two JDKs (on different at least 3 OSes). Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen) https://bitbucket.org/mfriedenhagen/ On Thu, Mar 5, 2015 at 11:18 PM, Chris Graham chrisgw...@gmail.com wrote: My preference is to always go for the lowest common denoninator, as it gives the largest possible spread. My 'grumbling' as Stephen put it [ :-) ], is more that I'd like people to have an awareness that there are other platforms out there. For example, the current IBM WAS 8.x stack defaults to Java 6, and Java 7 is an extra optional install. I'm not sure if there is an IBM Java 8 available (or being used in a product - I'm not sure, I've not looked, and now, I no long can!). Once the core moves the plugins will follow. I don't necessarilly agree with the premise that those stuck on older versions of Java will not want to use the newer core/plugins, especially as backports of fixes are exceptionally uncommon. But if you feel the pressing need to update, feel free. On Fri, Mar 6, 2015 at 6:11 AM, Karl Heinz Marbaise khmarba...@gmx.de wrote: Hi, On 3/5/15 2:16 PM, Igor Fedorenko wrote: This is chicken-and-egg situation. We won't use java 7 features unless the code targets java 7. Try-with-resources and multi-exception catch are the too features I'd like to start using throughout the code. Although not critical per se, I think they make writing correct maintainable code noticeably easier. Improvements to standard library, nio in particular, is another big reason for me. For example, Files#walkFileTree is significantly faster than comparable File-based implementation on large source trees. Knowing the core is on java 7 will allow us use that in plexus-utils for example. Hm..plexus-utils is used in many plugins which would cause them to upgrade to Java 7 as well ? Besides, java 7 is EOL'ed by Oracle next month. Yes, many organizations still use java 6 (and java 5), but the same organizations are not likely to move to use latest maven features any time soon either. -- Regards, Igor On 2015-03-05 7:59, Robert Scholte wrote: I don't know the numbers, but I think JDK6 is still used a lot by the community. Current code builds fine with JDK6. Which JDK7 specific features do you want to use, which are not possible with the current codebase? Without any critical codechanges I'd go for -1. Robert Op Thu, 05 Mar 2015 13:19:11 +0100 schreef Igor Fedorenko i...@ifedorenko.com: With maven core version change to 3.3.0 on master, any objections I change compile source/target to java 7? -- Regards, Igor Kind regards Karl Heinz Marbaise - 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 Thanks, Jason -- Jason van Zyl Founder, Takari and Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
