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

Provide compliance with both javax.servlet and jakarta.servlet #379

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

lounagen
Copy link

@lounagen lounagen commented Mar 9, 2022

Temporary workaround for #349, tested on tomcat 10.

Instead of forking java-saml-toolkit classes or using Eclipse transformer on client side, this PR allows to create 2 jar:

  • legacy one (for javax)
  • a new one (for jakarta) to reference with <classifier>jakarta<classifier>

To build :

  • legacy one: mvn clean install (mvn clean install -Pjavax)
  • jakarta one: mvn clean install -Pjakarta

I'm not sure how the artifacts are deployed within the release process, i think it should look like this? :

mvn release:prepare
mvn release:perform
mvn clean install deploy -Prelease
mvn clean install deploy -Prelease,jakarta (may be without release profile here to avoid overwriting sources/javadoc jars?)
mvn release:clean

The compliance is achieved within pom.xml metadata and do not modify the original java sources, so you will need to continue using javax to debug with sources.

The javax vs jakarta dependencies are moved under dedicated maven profiles.

  • For javax case, that's all
  • For jakarta case, we copy all source folders into a temp folder and replace on the fly the javax pkg name by jakarta one, and change the default maven source folders.

Let me know if there is a more efficient way to publish a jakarta compliant jar on central repo.

This compliance is for built jar only, and do not modify the original java sources.
You will need to continue using javax to debug with sources.
@manish-manghwani
Copy link

Hi @lounagen, thanks for providing this solution. Although, I have changed the source files to support the jakarta namespace but now I am not able to generate class files because dependencies are not getting resolved.
I want to understand the process of how we can generate .class files jar with new changes. Let me know if you or anyone else can guide me on this. Thank you!

@lounagen
Copy link
Author

Hi @lounagen, thanks for providing this solution. Although, I have changed the source files to support the jakarta namespace but now I am not able to generate class files because dependencies are not getting resolved.
I want to understand the process of how we can generate .class files jar with new changes. Let me know if you or anyone else can guide me on this. Thank you!

Hi @manish-manghwani ,
This PR was only a basis for discussion, but as mentioned in the thread below, this isn't an ideal solution, as the servlet concept should be externalized to be independent from the provider (javax, Jakarta, jersey, grizzly, ...): #349 (comment)

On my side, I've just extracted the few methods I needed and called the core module directly, without relying any more on the wrapper lib. You can ask the project owners (I'm not) for more info on your specific usecase.

@markkolich
Copy link

FWIW, I think #395 might supersede this PR ... trying to nudge the maintainers to get #395 merged

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.

None yet

3 participants