Attach sources and javadoc on every package - #61
Merged
Conversation
maven-source-plugin and maven-javadoc-plugin lived in the deploy profile, which has no activation block, so they only ran with an explicit -P deploy. maven-publish.yml runs a plain mvn deploy, so the attach-sources and attach-javadocs executions never fired and every artifact cfparser has published is a bare jar with no source attachment and no javadoc. Adding -P deploy to the workflow would not have worked: the same profile carries maven-gpg-plugin bound to verify, and there is no signing key in CI, so the publish would have started failing instead. Moving the two attach plugins into the main build and leaving GPG behind in the profile separates the two concerns -- artifact completeness is not a signing decision. Both bind to the package phase, so mvn test is untouched. Measured cost on package is 19.3s to 23.2s. Versions pinned to the 3.4.0 and 3.12.0 that were already resolving from the superpom, so the build stops moving underneath itself. maven-gpg-plugin beside them was already pinned. Dropped <additionalparam>-Xdoclint:none</additionalparam>. That parameter was removed in maven-javadoc-plugin 3.x, so it has been silently doing nothing and javadoc has been running with doclint on and passing. Deleting dead config keeps behaviour exactly as it is today; replacing it with <doclint>none</doclint> would newly relax checks that currently pass. Closes #60
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #60.
maven-source-pluginandmaven-javadoc-pluginlived in thedeployprofile, which has no<activation>block, so they only ran under an explicit-P deploy.maven-publish.ymlruns a plainmvn deploy, soattach-sourcesandattach-javadocsnever fired — every artifact cfparser has published is a bare jar with no IDE source attachment and no javadoc.Why not just add
-P deployto the workflowThe same profile carries
maven-gpg-plugin, bound toverify. There is no signing key in CI, so passing the profile would have traded missing jars for a broken publish.Moving the two attach plugins into the main
<build>and leaving GPG behind separates the two concerns properly: artifact completeness is not a signing decision, and the workflow needs no change at all.Cost, measured rather than assumed
I flagged in #60 that option 1 costs build time and was worth measuring first:
mvn package -DskipTestsmvn package -DskipTests -P deploy(source + javadoc)About 4 seconds. Both plugins bind to
package, somvn testis untouched — verified, neither goal appears in amvn testrun. The loop developers and CI run most often pays nothing; onlypackage/install/deploydo, which are exactly the operations that should produce complete artifacts.Verification
Plain
mvn deployagainst a local file repository, no-P deploypassed, at both version shapes:The parent correctly ships only its
.pom, which is right forpompackaging. GPG did not run, confirming the profile split holds../gradlew buildmvn packagere-run; all twelve version locations read2.16.0-SNAPSHOTand the diff ispom.xmlaloneTwo smaller things in the same block
Versions pinned to
3.4.0and3.12.0— the versions already resolving from the superpom, so this changes nothing today but stops the build moving underneath itself.maven-gpg-pluginbeside them was already pinned at3.2.4. Given this repo's history with versions drifting between declarations, leaving two unpinned plugins in the main build seemed worth closing off.Dropped
<additionalparam>-Xdoclint:none</additionalparam>. That parameter was removed in maven-javadoc-plugin 3.x, so it has been silently doing nothing — javadoc has been running with doclint on, and passing. Deleting dead config keeps behaviour exactly as it is today. Replacing it with the modern<doclint>none</doclint>would have been the tempting move and is the wrong one: it would newly relax checks that currently pass.Generated by Claude Code