;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 impac
7;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 M
2015-03-08 16:07 GMT+01:00 Tibor Digana :
> 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 h
(M2.2) and
>>>>> Java6
>>>>> (M3.2)
>>>>>
>>>>> Op Sun, 08 Mar 2015 21:33:38 +0100 schreef Tibor Digana
>>>>>
>>>>> :
>>>>>> @Robert
>>>>>> source=target=1.7 after M3.3.0? You
gt; :
> > >>> @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 requir
> >>> 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.
> >>>
> >>> Curren
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.
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 wrote:
>
> Hi Igor,
>
> In my opinion the switch to Java 7 as a prerequisite is a non-risky
> thing
ttp://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 N
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
eally 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 archi
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 en
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 analys
I have a biased data point to throw into the mix:
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 sup
Le dimanche 8 mars 2015 16:17:39 Dennis Lundberg a écrit :
> On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY 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
ider.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
>>
>>
>>
>&
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 p
On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY 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 w
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
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 c
> 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/mo
-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
t;
>
>
> --
> 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.
>
> -
> T
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
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 unsubsc
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
@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
m/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 unsubs
ccess (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
gs.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.
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
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 belie
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 regressi
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 o
+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 do
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 the
> 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 ha
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
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
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 thi
+1
On Thu, Mar 5, 2015 at 8:16 AM, 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"
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 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
Did I object something? :-)
--
Olivier
On 6 Mar 2015 21:19, "Stephen Connolly"
wrote:
> We are CTR not RTC
>
> If you object to the change, veto the commit
>
> On 6 March 2015 at 07:44, Olivier Lamy wrote:
>
> > +1
> > I just find the change/discussion a bit too fast.
> > You should wait longer
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 :
> 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
>
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
o quick at the moment) commit
Regards,
Hervé
- Mail original -
De: "Stephen Connolly"
À: "Maven Developers List"
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 Mar
We are CTR not RTC
If you object to the change, veto the commit
On 6 March 2015 at 07:44, Olivier Lamy 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 com
> 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
+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" wrote:
> Ok, the consensus is to m
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
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 wrote:
> Hello there,
>
> I would go for JDK7 as well, in April it w
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).
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 Ja
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 the
+1 for the upgrade
On Thu, Mar 5, 2015 at 7:53 PM, Hervé BOUTEMY 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 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
2015-03-05 17:26 GMT+01:00 Robert Scholte :
> Op Thu, 05 Mar 2015 14:16:24 +0100 schreef Igor Fedorenko
> :
>
>> 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
+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
Op Thu, 05 Mar 2015 14:16:24 +0100 schreef Igor Fedorenko
:
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" pe
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
wrote:
> We never got a final official policy.
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 fr
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
wrote:
> +1
>
> On 5 March 2015 at 12:19, Igor Fedorenko wrote:
>
>> With maven core version change to 3.3.0 on master, any objectio
+1
On 5 March 2015 at 12:19, Igor Fedorenko 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-unsu
+1
On Mar 5, 2015, at 4:19 AM, Igor Fedorenko 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
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 notice
+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.
/Ande
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
+1 :)
K
2015-03-05 13:27 GMT+01:00 Anders Hammar :
> 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:
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 wrote:
> With maven core version change to 3.
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...@ma
70 matches
Mail list logo