Move publishing configuration to a separate plugin #56727
Conversation
This is another part of the breakup of the massive BuildPlugin. This PR moves the code for configuring publications to a separate plugin. Most of the time these publications are jar files, but this also supports the zip publication we have for integ tests.
rjernst
added
:Delivery/Build
|
Pinging @elastic/es-core-infra (:Core/Infra/Build) |
| scmNode.appendNode("url", BuildParams.getGitOrigin()); | ||
| } | ||
|
|
||
| private static void configureJavadoc(Project project) { |
There was a problem hiding this comment.
I think this should better live in the ElasticsearchJavaPlugin. This is dealing with the actual generation of javadocs, not creating an artifact to publish. Every java project gets the javadoc task created for it, so due to that, I think we should have consistent behavior there, even if we rarely if ever generate javadocs for modules that aren't also published.
| javadocOptions.addBooleanOption("html5", true); | ||
| }); | ||
| // ensure javadoc task is run with 'check' | ||
| project.getTasks() |
There was a problem hiding this comment.
Perhaps this bit we leave in the publish plugin, as we don't necessarily want to fail builds for javadoc errors on unpublished modules.
There was a problem hiding this comment.
I think we do still want this in those cases. If we are writing javadocs, we should make sure they are valid.
| private static void configurePomGeneration(Project project) { | ||
|
|
||
| TaskProvider<Task> generatePomTask = project.getTasks().register("generatePom"); | ||
| // generatePomTask.configure(t -> t.dependsOn("generatePomFileForNebulaPublication")); |
There was a problem hiding this comment.
Should this be commented out?
There was a problem hiding this comment.
Nope this can be deleted. It's handled by the last block for all publishing tasks.
| publication.getPom().withXml(PublishPlugin::addScmInfo); | ||
|
|
||
| // have to defer this until archivesBaseName is set | ||
| project.afterEvaluate(p -> publication.setArtifactId(getArchivesBaseName(project))); |
There was a problem hiding this comment.
I see we no longer do this explicitly after applying the shadow plugin. I put that there to workaround some very specific configuration ordering issues. Please confirm that the artifact id for the poms generated for the HLRC and JDBC drive are correct. They should be elasticsearch-rest-high-level-client and x-pack-sql-jdbc, respectively.
To be even more thorough its probably worth doing a diff on all POMs, given we fuck something up every time we touch publishing code. When I was testing this I ran ./gradlew generatePom copied all the files to a folder, applied my changes, generated again, then did a diff to manually confirm my PR didn't change how POMs were generated.
There was a problem hiding this comment.
I double checked both those poms and they are correct. I will do a diff as you suggested.
| } catch (IOException e) { | ||
| throw new UncheckedIOException(e); | ||
| } | ||
| javadoc.setClasspath(javadoc.getClasspath().filter(f -> classes.contains(f) == false)); |
There was a problem hiding this comment.
We can simplify this a lot. If all we want is the compile class minus the source set output we can just use the main source set's getCompileClasspath().
There was a problem hiding this comment.
I think this is a bit different. See http://mail.openjdk.java.net/pipermail/javadoc-dev/2018-January/000400.html
There was a problem hiding this comment.
Oh I see what you mean now. Done.
This is another part of the breakup of the massive BuildPlugin. This PR moves the code for configuring publications to a separate plugin. Most of the time these publications are jar files, but this also supports the zip publication we have for integ tests.
This is another part of the breakup of the massive BuildPlugin. This PR moves the code for configuring publications to a separate plugin. Most of the time these publications are jar files, but this also supports the zip publication we have for integ tests.
This is another part of the breakup of the massive BuildPlugin. This PR moves the code for configuring publications to a separate plugin. Most of the time these publications are jar files, but this also supports the zip publication we have for integ tests.
mark-vieira
added
Team:Delivery
This is another part of the breakup of the massive BuildPlugin. This PR
moves the code for configuring publications to a separate plugin. Most
of the time these publications are jar files, but this also supports the
zip publication we have for integ tests.