On 30 April 2017 at 15:32, Gilles <gil...@harfang.homelinux.org> wrote: > On Sun, 30 Apr 2017 14:49:56 +0100, sebb wrote: >> >> 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. > > > I agree. > >> Besides, it is not difficult to do. > > > Then why doesn't INFRA do it when they perform an upgrade that > breaks what used to work?
Don't ask me, ask them... > Help welcome, since I must have missed the "easy" part in my > attempts to fix it... Which job is failing? > Gilles > > >> >>> >>> 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
