On 5 May 2017 at 23:40, Gilles <gil...@harfang.homelinux.org> wrote: > On Fri, 5 May 2017 16:15:11 +0100, sebb wrote: >> >> On 4 May 2017 at 23:02, Gilles <gil...@harfang.homelinux.org> wrote: >>> >>> On Thu, 4 May 2017 11:02:59 +0100, sebb wrote: >>>> >>>> >>>> On 4 May 2017 at 09:57, Gilles <gil...@harfang.homelinux.org> wrote: >>>>> >>>>> >>>>> On Thu, 4 May 2017 09:19:49 +0100, sebb wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 4 May 2017 at 00:48, Gilles <gil...@harfang.homelinux.org> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> Same commit, different behaviour... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Travis and Jenkins check different things... >>>>>> >>>>>>> https://travis-ci.org/apache/commons-math/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> https://builds.apache.org/job/Commons%20Math%20MasterBranch/34/console >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Exit code: 1 - javadoc: error - invalid flag: >>>>>> --allow-script-in-comments >>>>> >>>>> >>>>> >>>>> >>>>> I knew that it was caused by my adding this flag in the POM file. >>>>> Without this flag, the build fails with Java 8; with the flag, it >>>>> fails with Java 7. >>>> >>>> >>>> >>>> If the flag is really necessary for Java 8 (i.e. the Javadoc cannot >>>> readily be adjusted to avoid the problem) then obviously the flag >>>> setting will need to depend on the Java version being used to compile >>>> the code. >>>> >>>> The Commons Parent pom has some examples of settings that are >>>> conditional upon the Java version. >>> >>> >>> >>> Finally, I configured Jenkins so that the job will skip the javadoc >>> generation. Good enough until Jenkins will *require* Java 8. >> >> >> I disagree. > > > Then, please fix the POM as you suggested (using conditional options?). > >> >> It's now not possible to generate the Javadoc using Java7, i.e. the >> following fails: >> >> mvn javadoc:javadoc >> >> Given that the code targets Java 7, that does not make sense to me. > > > Agreed. > But we've already had (time-consuming) issues because most (all?) > CM contributors do use a Java 8 development environment.
In which case why are there so many Javadoc 8 warnings? >> >> This is actually nothing to do with Jenkins (or Travis AFAICT). >> >> This seems purely to be a problem cause by a stricter Java8 Javadoc >> processor. > > > Indeed. > I'm sure many people complained about behaviour. > Will it change with Java 9? > >> >> I think it needs to be resolved as such, not by suppressing the CI >> build errors that exhibit the problem. > > > Agreed. But in the meantime, it is IMO more important that the > CI build fails only for a good reason (i.e. a code-related one, > not an overzealous documentation generator). > > My fix is for "development time"; hopefully by the time we > can contemplate a release, an apter solution will have been > found and implemented. > > By then, we will probably target Java 10. ;-) > >> >> In any case, it looks like the Javadoc is not compatible with Java 8 >> for other reasons. > > > Sure. Feel free to come and help... :-) > >> >> As it stands, dropping the '--allow-script-in-comments' qualifier >> allows Javadoc7 to work with a couple of warnings. > > > That's the trade-off: either you allow CM contributors to run > Java 8's javadoc on their local machine (so that they can fix > the, now strictly enforced, HTML syntax), or you don't (and > new documentation bugs will be created since they cannot run > javadoc8 without the '--allow-script-in-comments' qualifier). Not true. Apart from fixiing the POM to auto-add the qualifier for Java 8, there is another option. If you drop the '--allow-script-in-comments' qualifier along with the rest of the additionalparam then Javadoc8 does at least run. As does Javadoc7. Seems to me that would be a sensible option until the additionalparam can be made sensitive to the Javadoc version. >> >> There's quite a lot of source fixes needed to make the Javadoc8 >> processor happy even without MathJax. >> (missing tags, malformed HTML etc). > > > Certainly; cf. above. > > > Gilles > > > >>> Regards, >>> Gilles >>> >>> >>>> >>>>> >>>>>> >>>>>>> Regards, >>>>>>> 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