On 29 April 2017 at 19:10, Gilles <gil...@harfang.homelinux.org> wrote: > Hi. > > On Sat, 29 Apr 2017 09:46:56 -0400, Raymond DeCampo wrote: >> >> Please note I wrote an issue concerning this last week or so. >> >> https://issues.apache.org/jira/browse/NUMBERS-21 >> >> I noticed when moving code from [math] to [numbers] that [math] targets 7. > > > As a general rule, this must formally asked on the "dev" ML. > [And, we'll take for granted that if no one raises an objection > within 72 hours, the proposal is accepted.] > >> I had to make some minor downgrades in the code (use of diamond operator). >> >> Given that [math] targets Java 7 and [numbers] is based on it, I see no >> reason [numbers] shouldn't target 7 as well. > > > That's fine with me; however let's note (for the record) that the > last official release of CM (3.6.1) was still Java 5 (five) compatible. > I don't think (TBC) that any of the CM codes intended (as of now) for > inclusion _requires_ Java 7. > > Hence my question about the necessity (seems not) or willingness > (could well be, if just for the comfort of contributors) to upgrade. > > Now, concretely, you could make the "downgrades" and the code is > now Java 6 compatible. > However, as concretely, it is not obvious that we want to loose > more time fiddling with Jenkins to make it perform the build of > code targeted to old Java.
IMO it is wrong for Jenkins to dictate the Java compat level of the items it builds. Besides, it is not difficult to do. > > Regards, > Gilles > > > >> >> >> On Fri, Apr 28, 2017 at 6:30 PM, sebb <seb...@gmail.com> wrote: >> >>> On 28 April 2017 at 16:05, Matt Sicker <boa...@gmail.com> wrote: >>> > If you're going to build for Java 6 using Java 7, then you should >>> > really >>> > use something like < >>> > http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/> to >>> > prevent accidental usage of Java 7. >>> >>> And/Or actually use Java 6 to compile/test, which is pretty easy to do >>> using the -Pjava-1.6 profile. >>> >>> > On 28 April 2017 at 09:51, sebb <seb...@gmail.com> wrote: >>> > >>> >> On 28 April 2017 at 13:01, Gilles <gil...@harfang.homelinux.org> >>> >> wrote: >>> >> > Hi. >>> >> > >>> >> > On Thu, 27 Apr 2017 08:42:36 -0700, Gary Gregory wrote: >>> >> >> >>> >> >> On Apr 27, 2017 8:21 AM, "Gilles" <gil...@harfang.homelinux.org> >>> wrote: >>> >> >> >>> >> >> On Thu, 27 Apr 2017 10:10:57 -0500, Matt Sicker wrote: >>> >> >> >>> >> >>> Choosing Java 8 or 7 for a new component depends on the APIs you >>> want >>> >> to >>> >> >>> use for it more so than what's current. >>> >> >>> >>> >> >> >>> >> >> Indeed, the question could be rephrased as: Is there anything to >>> loose >>> >> >> (for a new component) if we allow the larger API of Java 8? >>> >> >> >>> >> >> >>> >> >> I hear people are still using Java >>> >> >>> >>> >> >>> 6, but I doubt those projects are adapting new libraries or >>> upgrading >>> >> any >>> >> >>> of their dependencies as it is... >>> >> >>> >>> >> >> >>> >> >> That has seemed logical to me for a long time... >>> >> >> >>> >> >> >>> >> >> +1 >>> >> >> >>> >> >> I say pick the version you think is best. >>> >> > >>> >> > >>> >> > At this point, I can't say exactly. >>> >> > The current code doesn't seem to need Java APIs beyond 6, but other >>> >> > utilities yet to be added might benefit. >>> >> > The only argument for leaving Java 6 is that we have to go through >>> >> > hoops with the Jenkins configuration. >>> >> >>> >> That is not an argument for upping the Java version >>> >> >>> >> > Currently it fails in a way that looks cryptic to me. >>> >> >>> >> That's because Jenkins now requires Java 7 to run Maven jobs, though >>> >> it does not seem to need it for all job types. >>> >> >>> >> > So, unless someone can fix it, I'll bump the dependency to Java 7. >>> >> >>> >> Huh? >>> >> Surely you can just tell Jenkins to use Java 7 to build and test? >>> >> There's no need for the source to be updated as well (there might be >>> >> some Javadoc warnings, I suppose, but those can be fixed without >>> >> compromising Java 6 compat.) >>> >> >>> >> But it's pretty easy to fix so it builds and tests using Java 6 - >>> >> which job is it? >>> >> >>> >> > Regards, >>> >> > Gilles >>> >> > >>> >> > >>> >> > >>> >> >> >>> >> >> Gary >>> >> >> >>> >> >> >>> >> >> Regards, >>> >> >> Gilles >>> >> >> >>> >> >> >>> >> >> On 27 April 2017 at 09:41, Gilles <gil...@harfang.homelinux.org> >>> wrote: >>> >> >>> >>> >> >>> >>> >> >>> On Thu, 27 Apr 2017 14:49:01 +0200, Gilles wrote: >>> >> >>>> >>> >> >>>> >>> >> >>>> Hi. >>> >> >>>>> >>> >> >>>>> >>> >> >>>>> The POM indicates: >>> >> >>>>> >>> >> >>>>> <maven.compiler.source>1.6</maven.compiler.source> >>> >> >>>>> <maven.compiler.target>1.6</maven.compiler.target> >>> >> >>>>> >>> >> >>>>> but also: >>> >> >>>>> >>> >> >>>>> <commons.release.desc>(requires Java >>> 7+)</commons.release.desc> >>> >> >>>>> >>> >> >>>>> Which is wrong? >>> >> >>>>> >>> >> >>>>> >>> >> >>>>> Also, please not that keeping 1.6 compatibility seems to >>> complicate >>> >> >>>> >>> >> >>>> the Jenkins configuration: >>> >> >>>> https://builds.apache.org/view/Apache%20Commons/job/Commons_ >>> >> >>>> Numbers/14/console >>> >> >>>> >>> >> >>>> For a new component, shouldn't we just go to Java 8? >>> >> >>>> >>> >> >>>> >>> >> >>>> Gilles >>> >> >>>> >>> >> > >>> >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
