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

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

Open
PavelTurk opened this issue Nov 29, 2024 · 7 comments
Open

Comments

@PavelTurk
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

rgoers commented Nov 30, 2024

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
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Contributor Author

@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
Copy link
Member

rgoers commented Dec 2, 2024

@PavelTurk What "standard"?

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

No branches or pull requests

3 participants