HHH-9641 Publish JavaDoc JARs #2078
Conversation
|
Looks good. I wonder if there is anything we should change. |
|
I started a discussion on the mailing list and will attach it here. Basically, this was intended and that's why we have aggregated Java Docs. However, since this is already tested and it works, we might integrate this change as well. I'm waiting to see if there's anyone against it. |
|
If you can resolve the conflicts I will integrate this next week. |
| // The OSGi JAR manifest support does not like a non-existent classes dir, | ||
| // so make sure we dont use the OSGi one :) | ||
| manifest = null | ||
| } |
There was a problem hiding this comment.
Why publishing empty JavaDocs?
There was a problem hiding this comment.
I just replicated what was being done for the sources JAR. I should be able to supress the generation of the JavaDoc JAR and amend the PR.
There was a problem hiding this comment.
It is more a question. No one on the team actually ever uses javadoc jars - in our opinion its silly when you can instead just use the sources jar. So I am really asking.
|
I hope to do 5.3.0.Beta1 this week. No rush, but if you want it in there... |
smoothreggae
force-pushed
the
HHH-9641/publish-javadoc-jars
branch
from
2288084 to
57e0761
Compare
|
I've updated the branch based on the latest in the upstream I just realized something that should really have been obvious when I made the changes: the same all-encompassing JavaDoc JAR is being created for each of the sub-projects. Although this serves the need for a JavaDoc JAR, it seems wrong to include JavaDoc for classes that are not part of a given artifact and it seems wrong to publish such a large JAR for each sub-project. I could do one of the following:
Let me know which option you'd prefer. |
|
To publish module-specific JavaDoc jars, obviously those JavaDoc should be
module-specific :)
…On Tue, Dec 19, 2017 at 9:30 AM george thomas ***@***.***> wrote:
I've updated the branch based on the latest in the upstream master.
I just realized something that should really have been obvious when I made
the changes: the same all-encompassing JavaDoc JAR is being created for
each of the sub-projects. Although this serves the need for a JavaDoc JAR,
it seems *wrong* to include JavaDoc for classes that are *not* part of a
given artifact and it seems *wrong* to publish such a large JAR for each
sub-project.
I could do one of the following:
- decline the PR (since the team doesn't really use the JavaDoc JARs)
- see what it takes to get a more correct JavaDoc JAR for each
sub-project without upsetting the existing build and then update the PR
Let me know which option you'd prefer.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2078 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAOUE8QFIMNVYaEGJVCAQVejVCdq8xQIks5tB9aJgaJpZM4Q1rW_>
.
|
|
Thanks for not choosing to decline it outright :) Let me see what I can do to get some module-specific JavaDoc JARs. |
|
Have you checked the Gradle documentation? Generating javadoc jar is pretty straight-forward. |
|
@sebersole, my changes initially reused what the build in this project already does for JavaDoc. I do plan to use the standard |
|
There really should not be much to do for this - I'm not sure what you want to "duplicate". Anyway, as we are also looking to move to Bintray for publishing release artifacts and syncing to Central we will need to start publishing javadocs as well since Central requires it. We had previously gotten around that, but we will no longer be able to. So I'll likely just do this |
|
The duplication should only be in the configuration for the JavaDoc. |
|
I implemented this myself : #2097 |
|
Cool, @sebersole. I was just about to push a working alternative. |
HHH-9641 is an old ticket and isn't assigned to anyone, but the required changes didn't seem too hard so I gave it a shot. I tested my changes with a
./gradlew clean assemble publishToMavenLocal(which, before my changes only created the binary and source JARs). I'd be glad to do any more required testing and make any other changes necessary.