Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[MJAVADOC-329] Allow generation of empty javadoc JARs #65

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

jfallows
Copy link

Add generateIfEmpty property to javadoc:jar goal, defaulting to false for backwards compatibility.
Add testGenerateIfEmpty property to javadoc:test-jar goal for consistency, defaulting to false for backwards compatibility.

          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>3.0.0</version>
            <executions>
              <execution>
                <phase>package</phase>
                <configuration>
                  <target>
                    <mkdir dir="${project.build.directory}/apidocs" />
                  </target>
                </configuration>
                <goals>
                  <goal>run</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <version>3.2.0</version>
            <configuration>
              <sourceFileExcludes>
                <exclude>**/internal/**/*.java</exclude>
              </sourceFileExcludes>
            </configuration>
            <executions>
              <execution>
                <goals>
                  <goal>jar</goal>
                </goals>
              </execution>
            </executions>
          </plugin>

where no non-internal classes exist, therefore no public Javadoc is required, yet Maven Central requires inclusion of a Javadoc JAR during deployment.

This now simplifies to

          <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-javadoc-plugin</artifactId>
            <version>3.2.1</version>
            <configuration>
              <sourceFileExcludes>
                <exclude>**/internal/**/*.java</exclude>
              </sourceFileExcludes>
              <generateIfEmpty>true</generateIfEmpty>
            </configuration>
            <executions>
              <execution>
                <goals>
                  <goal>jar</goal>
                </goals>
              </execution>
            </executions>
          </plugin>

Integration tests passed successfully.

[INFO] --- maven-invoker-plugin:3.2.1:verify (integration-test) @ maven-javadoc-plugin ---
[INFO] -------------------------------------------------
[INFO] Build Summary:
[INFO]   Passed: 54, Failed: 0, Errors: 0, Skipped: 17
[INFO] -------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------

As ASF Committer jfallows,

Checklist

Following this checklist to help us incorporate your
contribution quickly and easily:

  • Make sure there is a JIRA issue filed
    for the change (usually before you start working on it). Trivial changes like typos do not
    require a JIRA issue. Your pull request should address just this issue, without
    pulling in other changes.
  • Each commit in the pull request should have a meaningful subject line and body.
  • Format the pull request title like [MJAVADOC-XXX] - Fixes bug in ApproximateQuantiles,
    where you replace MJAVADOC-XXX with the appropriate JIRA issue. Best practice
    is to use the JIRA issue title in the pull request title and in the first line of the
    commit message.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Run mvn clean verify -Prun-its to make sure basic checks pass. A more thorough check will
    be performed on your pull request automatically.

If your pull request is about ~20 lines of code you don't need to sign an
Individual Contributor License Agreement if you are unsure
please ask on the developers list.

To make clear that you license your contribution under
the Apache License Version 2.0, January 2004
you have to acknowledge this by using the following check-box.

 Add generateIfEmpty (default false) to javadoc:jar goal
 Add testGenerateIfEmpty (default false) to javadoc:test-jar goal
 Add unit test for javadoc:jar generateIfEmpty
@elharo elharo changed the title [MJAVADOC-329] - Allow generation of empty javadoc JARs [MJAVADOC-329] Allow generation of empty javadoc JARs Jul 9, 2023
Copy link
Contributor

@elharo elharo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can review if you resolve conflicts.

jonenst added a commit to powsybl/powsybl-math-native that referenced this pull request Aug 31, 2023
This adds a package-info.class file to the generated jar but it shouldn't be a problem
This is because maven uses the jar as the input to the javadoc tool and we don't
want to diverge too much from the maven way (you get problems really fast)
(In theory, I guess we could generated the javadoc from target/classes instead of target/project.jar)

The generated javadoc has one package with one class because:
- It doesn't seem to be possible to generate an empty javadoc (no packages).
- It doesn't seem to be possible to generate an empty package (no classes).

references:
* https://stackoverflow.com/questions/53706943/how-to-upload-an-artifact-to-maven-central-with-an-empty-javadoc-jar-or-empty-s
 => what we did in 1.0.0 and 1.0.1: totally empty javadoc.jar (valid for maven central upload but ugly)
* https://stackoverflow.com/questions/59071851/how-to-force-a-javadoc-jar-even-though-there-is-no-public-javadoc
 => still produces a totally empty javadoc.jar (and big scary red errors)
* https://stackoverflow.com/questions/1138390/javadoc-for-package-info-java-only
 => This plus excluding the class from the jar seems like the best solution for now ?

promising but not yet ready:
* https://issues.apache.org/jira/browse/MJAVADOC-329
  apache/maven-javadoc-plugin#65
* https://bugs.openjdk.org/browse/JDK-8193107
  https://hg.openjdk.org/jdk/jdk/rev/111104f1e033
  empty modules are allowed, but does becoming a module work with how the native library are loaded ??
jonenst added a commit to powsybl/powsybl-math-native that referenced this pull request Aug 31, 2023
This adds a package-info.class file to the generated jar but it shouldn't be a problem
This is because maven uses the jar as the input to the javadoc tool and we don't
want to diverge too much from the maven way (you get problems really fast)
(In theory, I guess we could generated the javadoc from target/classes instead of target/project.jar)

The generated javadoc has one package with one class because:
- It doesn't seem to be possible to generate an empty javadoc (no packages).
- It doesn't seem to be possible to generate an empty package (no classes).

references:
* https://stackoverflow.com/questions/53706943/how-to-upload-an-artifact-to-maven-central-with-an-empty-javadoc-jar-or-empty-s
 => what we did in 1.0.0 and 1.0.1: totally empty javadoc.jar (valid for maven central upload but ugly)
* https://stackoverflow.com/questions/59071851/how-to-force-a-javadoc-jar-even-though-there-is-no-public-javadoc
 => still produces a totally empty javadoc.jar (and big scary red errors)
* https://stackoverflow.com/questions/1138390/javadoc-for-package-info-java-only
 => This plus excluding the class from the jar seems like the best solution for now ?

promising but not yet ready:
* https://issues.apache.org/jira/browse/MJAVADOC-329
  apache/maven-javadoc-plugin#65
* https://bugs.openjdk.org/browse/JDK-8193107
  https://hg.openjdk.org/jdk/jdk/rev/111104f1e033
  empty modules are allowed, but does becoming a module work with how the native library are loaded ??

Signed-off-by: HARPER Jon <[email protected]>
@vietj
Copy link

vietj commented Oct 5, 2024

that would be a useful feature

@michael-o
Copy link
Member

I think there is a potential better way to solve this. Some plugins have a forceCreation parameter, we can leverage it here as well. I think it was maven-source-plugin.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants