Oops - mea culpa. I can update the lifecycle to require JDK 6 or did you 
already do this?

On Mar 31, 2013, at 6:39 AM, Simone Tripodi <simonetrip...@apache.org> wrote:

> Good to hear we are on the same path! :)
> 
> You can already fix them, in components that require more recents
> JDKs, by overriding ${javac.src.version} and ${javac.target.version}
> properties in their POM, i.e. like in Lifecycle-Warmup.
> 
> Thanks for taking care of it!
> -Simo
> 
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
> 
> 
> On Sun, Mar 31, 2013 at 3:35 PM, Mikhail Mazursky
> <mikhail.mazur...@gmail.com> wrote:
>> Hi, Simone,
>> 
>> 2013/3/31 Simone Tripodi <simonetrip...@apache.org>
>> 
>>> Hi Mikhail,
>>> 
>>> time ago we already discussed it and we found the agreement that the
>>> default supported JDK is Java5, since Guice targets it and users of
>>> JDK5 platform would be still interested on adopting our libraries; if,
>>> for some reasons, a component requires a newer JDK version, it is
>>> enough the ${javac.src.version} and ${javac.target.version} properties
>>> are overridden in its own pom.
>>> 
>>> That's what i had in mind - bump version only in specific components that
>> require newer version and document it. No global target version.
>> 
>> 
>>> -1 to have a global target JDK, -1 on bumping directly to newer JDKs:
>>> while it is true that old JDKs reached the EOL, customers haven't
>>> abandoned that platforms, immagine some of us still have customers
>>> requiring JDK1.4 - we have to serve the industry and, for a wider
>>> adoption, we have to genuinely take care to our user as well that we
>>> do to our code.
>>> 
>>> For the ForkJoinPoo: if codehaus' jsr166y backports to JDK6 is really
>>> Java6 compatible, it would be preferred.
>>> 
>>> HTH,
>>> -Simo
>>> 
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>> 
>>> 
>>> On Sun, Mar 31, 2013 at 1:39 PM, Mikhail Mazursky
>>> <mikhail.mazur...@gmail.com> wrote:
>>>> Hello all@dev.
>>>> 
>>>> I found out that some parts of our code use methods, introduced in Java
>>> 6:
>>>> - Collections.asLifoQueue() in DefaultStager;
>>>> - Collections.newSetFromMap() in WarmUper;
>>>> - ForkJoinPool from jsr166y in WarmUper requires Java 6 too - see [1].
>>>> - maybe more.
>>>> 
>>>> But in pom.xml we target Java 5.
>>>> 
>>>> I think we should decide what version we target and fix our code and/or
>>> our
>>>> pom.xml's. We may want to enforce this by using
>>> animal-sniffer-maven-plugin
>>>> [2].
>>>> 
>>>> IMHO warmup project can target Java 7 if it requires ForkJoinPool. Other
>>>> parts may target Java 6 if it is usefull. Even JDK 6 reached it's "end of
>>>> life" a month ago so i don't see much value in supporting Java 5.
>>>> 
>>>> WDYT?
>>>> 
>>>> [1]: http://g.oswego.edu/dl/concurrency-interest/
>>>> [2]: http://mojo.codehaus.org/animal-sniffer-maven-plugin/
>>> 

Reply via email to