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

[2.0] Wrong modules in JAVAX_WEBSOCKET_API_RULE #114

Open
boris-petrov opened this issue Apr 13, 2024 · 3 comments
Open

[2.0] Wrong modules in JAVAX_WEBSOCKET_API_RULE #114

boris-petrov opened this issue Apr 13, 2024 · 3 comments
Labels
a:question Further information is requested

Comments

@boris-petrov
Copy link
Contributor

boris-petrov commented Apr 13, 2024

I believe this is a mistake. org.apache.tomcat.embed:tomcat-embed-websocket is not an API, that's the implementation in the embedded Tomcat. It should not be replaced with anything as then projects don't work - i.e. it must be removed from that list. I'm not sure about the line above - org.apache.tomcat:tomcat-websocket - perhaps it also is an implementation, I'm not sure.

The same applies for all rules that contain these two modules.

P.S. I now see a similar problem with org.apache.tomcat.embed:tomcat-embed-core too.

@jjohannes
Copy link
Member

I see what you mean, but the idea is that the capability JAVAX_WEBSOCKET_API_RULE means: These are alternatives that include the API (they may include more). And that is the case: org.apache.tomcat.embed:tomcat-embed-websocket does not only contain an implementation, but also all the API classes (e.g. javax.websocket.server.ServerContainer).

The general idea is that with theses rules, you will not have duplicated classes on the classpath anymore. If two Jars have overlapping classes, they have a shared capability. And that is the case here.

@jjohannes jjohannes added the a:question Further information is requested label Apr 16, 2024
@boris-petrov
Copy link
Contributor Author

Thanks for the answer! I understand what you're saying but in that case, if one has org.apache.tomcat.embed:tomcat-embed-websocket on their classpath, anything other than select(CapabilityDefinition.JAVAX_WEBSOCKET_API_RULE, 'org.apache.tomcat.embed:tomcat-embed-websocket') would cause their projects to not work, right? I agree with the general idea that preventing duplicate classes is great but in cases like these I think it doesn't make sense - it's better to have duplicate classes than a non-working project.

On the other side you do have a way to remove that:

patch.module('org.apache.tomcat.embed:tomcat-embed-websocket') {
	removeCapability(CapabilityDefinition.JAVAX_SERVLET_API)
	removeCapability(CapabilityDefinition.JAVAX_WEBSOCKET_API_RULE)
}

So I would understand if you don't want to "fix" it. It is a problem in the artifact itself after all - I guess it should not include these classes but rather depend on some other dependency... but that's the way it is.

@boris-petrov
Copy link
Contributor Author

Speaking of the devil! 😄 In the new Tomcat version (9.0.88) they've made org.apache.tomcat.embed:tomcat-embed-websocket depend on org.apache.tomcat:tomcat-websocket-api! Which is great but... there are now duplicate classes between the two too. No matter, I just wanted to mention that. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a:question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants