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

Reply via email to