There is no module-info source in log4j-core-3.0.0-beta3-sources.jar

[PavelTurk]

Description

As I found out module-info is generated automatically in 3.0.0-beta3. At the same time its source (module-info.java) must be present in *-3.0.0-beta3-sources.jar files. For example, there is no module-info.java in log4j-core-3.0.0-beta3-sources.jar see [1], but there is a module-info.class in log4j-core-3.0.0-beta3.jar see [2].

The absence of module-info.java makes it difficult for library user to get important information about module, for example, its dependencies, provided and used services etc.

[1] https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/3.0.0-beta3/log4j-core-3.0.0-beta3-sources.jar
[2] https://repo1.maven.org/maven2/org/apache/logging/log4j/log4j-core/3.0.0-beta3/log4j-core-3.0.0-beta3.jar

[ppkarwasz]

Hi @PavelTurk,

While ideally we could have a text representation of module-info.class in our *-source.jar artifacts, the BND Maven plugin that generates them, only provides the compiled version.

I don't believe this is a big problem, since the information in module-info.class can be extracted quite easily by any decompiler or jar -d.

[rgoers]

The ASF has no requirement that generated source files appear in the source release. The ASF release policy states "Every ASF release must contain a source package, which must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools.". In general, a source release package should contain exactly what is in source control under the tag for that release. Doing anything else would lead to problems.

[ppkarwasz]

I think we are talking about the Maven sources artifact. That one has even less requirements: it is not a complete source file, so you can not build the binary artifact using it. It is mostly used by IDEs to show you the source of external libraries.

Currently it contains some generated code/resources:

• The code generated by annotation processors in target/generated-sources/annotations ends up in the source JAR and is also used by the compiler.
• The resources generated in target/maven-shared-archive-resources end up in the source JAR and the binary JAR.

Even if we do decompile module-info.class, I can not find a mechanism in the Maven Source Plugin that would allow us to add the file to the source JAR, without it ending up also in the binary JAR or on the compiler classpath. Solving this feature request will probably need:

• Changes to the Maven Source Plugin.
• Changes to the BND Maven Plugin.

[PavelTurk]

@ppkarwasz

I don't believe this is a big problem, since the information in module-info.class can be extracted quite easily by any decompiler or jar -d.

I am afraid it is not a good solution. Because it is a standard way to get sources from -sources.jar files. For example, when I work in IDE (NB) I do right click on dependency -> download sources. After that I KNOW that I can open any file in that dependency and I will read its source.

[ppkarwasz]

I am afraid it is not a good solution. Because it is a standard way to get sources from -sources.jar files. For example, when I work in IDE (NB) I do right click on dependency -> download sources. After that I KNOW that I can open any file in that dependency and I will read its source.

My IDE (IDEA) automatically decompiles the file and the same functionality is available in Eclipse. I am not saying this is not an issue, but it is a minor one. Feel free to open a PR that fixes this problem. As I mentioned above, this will probably require changes to BND Maven Plugin and maybe Maven Source Plugin, so it seems to be a long run.

[PavelTurk]

@ppkarwasz

The problem is not decompilation (NB also has a Java decompiler plugin); the problem lies in deviating from the standard. But these are just thoughts out loud...

[rgoers]

@PavelTurk What "standard"?