On Thu, Jan 17, 2019 at 2:04 AM Robert Varga <[email protected]> wrote: > On 17/01/2019 07:13, Anil Belur via RT wrote: > > On Wed Jan 16 13:31:24 2019, [email protected] wrote: > >> Adding helpdesk. > >> > >> I suppose SET_JDK_VERSION should not be an array. > >> > >> -Lori > > > > Greetings Lori: > > > > This approach for passing multiple java-versions (openjdk8 and > openjdk11) seem > > to work for the maven-verify jobs but not for the javadocs-verify jobs. > This is because JJB ${job-name} expansion is handling the ${java-version} > when the job name has a variable name included. When the job name does not > have the ${java-version} this is passed as a list to the job. > > > > I think we may need to make the scripts a little intelligence to handle > these scenarios or simply fix this in the job which requires to be changed > in global-jjb. I've have noted this in Jira and will work on fixing this in > global-jjb to make sure this works properly for other jobs too. > > > > https://jira.linuxfoundation.org/browse/RELENG-1648 > > Actually, what is the compelling reason to have a separate javadoc > verify job? > > I mean javadocs are being generated in normal verify jobs, hence it > looks to me like duplicate work (given that the javadoc job needs to > also generate/compile sources). >
There is non other than when we started building it, we weren't 100% sure how it would work yet and wanted to build it separate to separate it from our production jobs. Now that this is a part of our regular workflow and we have a better sense of how these javadocs are built we could move the relevant logic into the maven-verify and maven-merge jobs. Robert, we had a separate email thread discussing just this over the holidays but our conversation lost steam. It was titled "Reworking MRI javadoc". I've bumped the thread to restart the converstation. Hope this helps, Thanh
_______________________________________________ infrastructure mailing list [email protected] https://lists.opendaylight.org/mailman/listinfo/infrastructure
