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

Glassfish Web profile binary does not support ear deployment #1738

Open
starksm64 opened this issue Jan 9, 2025 · 4 comments
Open

Glassfish Web profile binary does not support ear deployment #1738

starksm64 opened this issue Jan 9, 2025 · 4 comments
Assignees
Labels

Comments

@starksm64
Copy link
Contributor

starksm64 commented Jan 9, 2025

Describe the bug
In the platform-tck/glassfish-runner/persistence-platform-tck runner I tried running some tests that should be targetting the Web profile with the web profile binary by specifying -Pweb, and this shows a failure because the org.glassfish.main.distributions:web binary reports ears as invalid archive type.

How was this handled in EE10?

In general we have the majority of test artifacts as EARs, so is this something that a Web profile implementation needs to deal with in a porting layer?

To Reproduce
Steps to reproduce the behavior:

  1. Go to platform-tck/glassfish-runner/persistence-platform-tck
  2. mvn -P verify
  3. See failures
@alwin-joseph
Copy link
Contributor

How was this handled in EE10?

For EE10, the WAR archives were deployed for webprofile testing and EARs were deployed for full platform.

In EE11 , for example in transactions, we create EAR for tests that are run only in full platform profile and for other tests that are run for both full and web profile we generate WARs.

I have not verified if all other modules are following this approach.
Ideal way would be to keep EARs in full profile and WARs for web profile. But since most webprofile tests are run in full profile also we are creating WARs that works for both profiles.

@starksm64
Copy link
Contributor Author

starksm64 commented Jan 9, 2025

Ok, I think we have a problem with most tests defaulting to producing an EAR. This is what the tcks/apis/persistence/persistence-inside-container/platform-tests are doing. We will need to go through and make sure that any test with the @Tag("web") is producing a WAR that can be used in either the web or platform TCKs.

starksm64 added a commit that referenced this issue Jan 9, 2025
….contracts.resource_local, ee.jakarta.tck.persistence.core.query.parameter, and ee.jakarta.tck.persistence.core.criteriaapi.CriteriaDelete packages.

Start returning WARs as test archive
Related to #1738

Signed-off-by: Scott M Stark <[email protected]>
starksm64 added a commit that referenced this issue Jan 9, 2025
….contracts.resource_local, ee.jakarta.tck.persistence.core.query.parameter, and ee.jakarta.tck.persistence.core.criteriaapi.CriteriaDelete packages. (#1739)

Start returning WARs as test archive
Related to #1738

Signed-off-by: Scott M Stark <[email protected]>
@starksm64 starksm64 self-assigned this Jan 13, 2025
@edburns
Copy link
Contributor

edburns commented Jan 14, 2025

The job-to-be-done for this issue is illustrated here: #1748

starksm64 added a commit that referenced this issue Jan 14, 2025
starksm64 added a commit that referenced this issue Jan 14, 2025
* Addresses #1738 for the JPA web profile tests
* Cleanup unused imports that could make is seem as though the EnterpriseArchive artifact was being used.

---------

Signed-off-by: Scott M Stark <[email protected]>
@starksm64
Copy link
Contributor Author

This should be done, but we would need a full run of the web profile to see if there are any failures due to EAR test artifacts.

@starksm64 starksm64 moved this to In review in Jakarta EE11 TCK Release Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: In review
Development

No branches or pull requests

3 participants