[
https://issues.apache.org/jira/browse/LUCENE-9321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098368#comment-17098368
]
Uwe Schindler edited comment on LUCENE-9321 at 5/3/20, 11:32 AM:
-----------------------------------------------------------------
bq. I wouldn't require a second (independent) build pass. If it's something
required for the "release" then let's have a release task in gradle and take
care of it there (javadocs built twice but within the same run of the build -
the "release" build). Otherwise the "release" scripts are duplicating what
could as well be done within the main build script?
During the release you build maven artifacts (with absolute links) going to
local module folder. In addition you build global javadocs with relative links.
So I agree, this should be done in the same build run.
IMHO, both can be done with a same set of tasks, we just need to dynamically
duplicate them in our build plugin. When doing this, I'd change 2 things: the
output directory and apply URI.relativize() to our clones.
The global documentation task depends on those variants; the jar file builds
for maven and those running during normal "developer interaction" depend on
standard javadocs task, that delegates to renderJavaDoc with absolute links.
I have a plan how to do this, let me get started and propose a pull request.
When all is done, the full blown javadocs are never created for developers,
only if the release manager, smoketester, or jenkins calls "gradle
documentation" or "gradle release" (or whatever). If you just run tests or run
precommit, only the "minimal checks" are done. In addition the documentation is
not built, only local javadocs for the module.
I will also try to fix the hardcoded URLs and make then properties, so Jenkins
can tell where the documentation will land. This also alows downstream users to
publish javadocs on their own pages (we have several clones).
was (Author: thetaphi):
bq. I wouldn't require a second (independent) build pass. If it's something
required for the "release" then let's have a release task in gradle and take
care of it there (javadocs built twice but within the same run of the build -
the "release" build). Otherwise the "release" scripts are duplicating what
could as well be done within the main build script?
During the release you build maven artifacts (with absolute links) going to
local module folder. In addition you build global javadocs with relative links.
Both can be done with a same set of tasks, just dynamically duplicate then in
the bud module. When doing this change 2 things: the output die and apply
URI.relativize(). The global documentation task depends on those variants, the
jar file builds for maven depend on standard javadocs task, that delegates to
renderJavaDoc with absolute links.
> Port documentation task to gradle
> ---------------------------------
>
> Key: LUCENE-9321
> URL: https://issues.apache.org/jira/browse/LUCENE-9321
> Project: Lucene - Core
> Issue Type: Sub-task
> Components: general/build
> Reporter: Tomoko Uchida
> Priority: Major
> Attachments: screenshot-1.png
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> This is a placeholder issue for porting ant "documentation" task to gradle.
> The generated documents should be able to be published on lucene.apache.org
> web site on "as-is" basis.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
