Skip to content
New issue

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

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

Already on GitHub? # to your account

Automatic module name missing in the implementation JAR #246

Closed
jeffmorin opened this issue Feb 10, 2023 · 5 comments
Closed

Automatic module name missing in the implementation JAR #246

jeffmorin opened this issue Feb 10, 2023 · 5 comments

Comments

@jeffmorin
Copy link

Hi everyone:

It's impossible to include both the API and the implementation of JSTL in their current form in a modularized project (i.e. with module-info.java files).

The API is already fully modularized with jakarta.servlet.jsp.jstl as a module name in its module-info.java file. This is fine.

The implementation, however, is not modularized and has no automatic module name, which leaves no choice other than deducing the module name from the generated JAR name. But this JAR name, after being stripped from the version number according to the automatic module naming rules, is precisely jakarta.servlet.jsp.jstl, which is the same as the API module name above.

See the problem? This creates a conflict, as both JARs happen to have the same module name and therefore cannot be used together in any modularized project.

If the development team is not willing to add a module-info.java file right away, a simple solution consists in adding an Automatic-Module-Name entry in the maven-jar-plugin configuration:

<manifestEntries>
  ...
  <Automatic-Module-Name>org.apache.servlet.jsp.jstl</Automatic-Module-Name>
</manifestEntries>

where the automatic module name must be different from jakarta.servlet.jsp.jstl.

I used org.apache.servlet.jsp.jstl to mimic what was done with Jakarta EL (jakarta.elfor the API, com.sun.el for the implementation), but any other suitable module name can be chosen instead.

I tried to file this fix request through a pull request from the master branch, only to find out that it doesn't contain the implementation. If I must file a pull request, which branch should I start from?

Thanks.

@arjantijms
Copy link
Contributor

The implementation moved to the WaSP project: https://github.com/eclipse-ee4j/wasp

See also #146

@arjantijms
Copy link
Contributor

com.sun.el for the implementation

The automatic module name for the Expression Language implementation is actually org.glassfish.expressly. See:

https://github.com/eclipse-ee4j/expressly/blob/master/pom.xml#L173

@jeffmorin
Copy link
Author

Looks like I didn't find the right location when I searched for the WaSP project... Many thanks Arjan, I'll look there.

@jeffmorin
Copy link
Author

Finally, just what the doctor ordered... Thanks again!

@pnicolucci
Copy link
Contributor

pnicolucci commented Apr 4, 2023

An issue was opened for this in the WaSP project: eclipse-ee4j/wasp#58 closing this issue in favor of that one.

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

No branches or pull requests

3 participants