Remove use of Jakarta Deployment

[scottmarlow]

Look for use of Jakarta Deployment and remove use of: javax.enterprise.deploy.model, javax.enterprise.deploy.model.exceptions, javax.enterprise.deploy.shared, javax.enterprise.deploy.shared.factories, javax.enterprise.deploy.spi, javax.enterprise.deploy.spi.exceptions, javax.enterprise.deploy.spi.factories, javax.enterprise.deploy.spi.status

Also document impact on use of Platform TCK.

[scottmarlow]

Regarding the impact of removing javax.enterprise.deploy, src/com/sun/ts/lib/porting/TSDeploymentInterface2.java is based on the deployment model, which is likely used by some Jakarta EE server implementations for testing against the Platform TCK.

Investigate the below classes to help determine the impact of removing Deployment:
src/com/sun/ts/lib/deliverable/cts/deploy/OperationStatus.java
src/com/sun/ts/lib/deliverable/cts/deploy/DeployTestUtil.java
src/com/sun/ts/lib/deliverable/cts/deploy/StandardDeployment14.java
src/com/sun/ts/lib/implementation/sun/javaee/SunRIDeployment2.java

src/com/sun/ts/tests/j2eetools/deploy/platform/ee/tmoduleid/tmoduleidClient.java
src/com/sun/ts/tests/j2eetools/deploy/platform/ee/depmanager2/depmanagerClient2.java
src/com/sun/ts/tests/j2eetools/deploy/platform/ee/depfactory/depfactoryClient.java
src/com/sun/ts/tests/j2eetools/deploy/platform/ee/depmanager3/depmanagerClient3.java
src/com/sun/ts/tests/j2eetools/deploy/platform/ee/depmanager1/depmanagerClient1.java
src/com/sun/ts/tests/common/negdep/NegdepUtil.java

[arjantijms]

@dblevins mentioned a blocker here could be that the TCK uses Jakarta Deployment itself to deploy tests unrelated itself to Jakarta Deployment.

However, the web profile doesn't have Jakarta Deployment, so at least everything in that profile must be using something else to deploy tests. Maybe the tests that now use Jakarta Deployment to deploy tests can be updated to use whatever the web profile tests are using?

[scottmarlow]

True, GlassFish v6 will not likely include a JSR-88 implementation. This will impact other EE implementations as well.

[scottmarlow]

Maybe the tests that now use Jakarta Deployment to deploy tests can be updated to use whatever the web profile tests are using?

I need to refresh my memory on the TCK deployment interfaces. I think your right but I forget what all of the options are.

I wonder if it would be allowed to repackage some JSR-88 impl + api classes under a different package name, so they could be used for deployment (along with updated com.sun.ts.lib.deliverable.cts.deploy classes that also use the repackaged JSR-88 classes).

[scottmarlow]

Jakarta EE implementations may currently use an implementation of com.sun.ts.lib.porting.TSDeploymentInterface2 (JSR-88 based) + com.sun.ts.lib.porting.TSDeploymentInterface (not JSR-88 based), for running the Platform TCK.

So, I think there are a few options to choose from that are worth raising on a mailing list for discussion:

• Option A is the least impact on setting up to run the Jakarta EE 9 Platform TCK by adding the JSR-88 classes to the Platform TCK (e.g. use release from https://github.com/eclipse-ee4j/management-api), so that the Platform TCK com.sun.ts.lib.porting.TSDeploymentInterface2 can continue to depend on JSR-88, as well as Jakarta EE 9 implementations. I'm not sure that this option helps all Jakarta EE implementations, especially those that actually support the (currently optional) Jakarta Deployment API, as any such implementation code will not be present in Jakarta EE 9 implementations.

• Option B is for updating com.sun.ts.lib.porting.TSDeploymentInterface2 (and other Platform TCK code) to somehow not depend on javax.enterprise.deploy.spi. Again, I'm not sure that this option helps all Jakarta EE implementations, especially those that actually support the (currently optional) Jakarta Deployment API, as any such implementation code will not be present in Jakarta EE 9 implementations.

• Option C is for removing all use of javax.enterprise.deploy.spi classes in the Platform TCK. com.sun.ts.lib.porting.TSDeploymentInterface2 would be updated to be the same as com.sun.ts.lib.porting.TSDeploymentInterface.

[scottmarlow]

Note feedback from jakartaee-platform-dev ml discussion started on April 22, 2020.

Also Platform meeting notes for April 28, 2020

On Tuesday, April 28, 2020, Scott Stark starksm64@xxxxxxxxx wrote:

From Scott Stark:

Ideally, I would think that we would need to introduce a new TCK spi that replaces the deployment feature.

From Arjan Tijms:

Even though the tests themselves are not Maven / Arquillian based, we could maybe look into adapting the existing Arquillian servers (connectors) for this.

jsonb-api/pull#221 brought in some Arquillian support to the jsonb-api fork of JSONB platform TCK testing.

[scottmarlow]

Regarding deployment API, since EE 9 implementations can no longer depend on JSR-88, they will need to expose an equivalent facility in their EE implementations and have a Platform TCK replacement for the JSR-88 interfaces (e.g. the new TCK SPI for deployment) that they can adapt their EE server implementation to use, in their porting library.

@starksm64 is ^ what you had in mind regarding a new TCK SPI for deployment?

@dblevins does ^ address your concern about dropping JSR-88 support from the Platform TCK?

[scottmarlow]

Perhaps the new TCK deployment SPI could be a fork of the JSR-88 interfaces, only without the javax package (e.g. switch for jakarta).

[scottmarlow]

@dblevins mentioned a blocker here could be that the TCK uses Jakarta Deployment itself to deploy tests unrelated itself to Jakarta Deployment.

However, the web profile doesn't have Jakarta Deployment, so at least everything in that profile must be using something else to deploy tests. Maybe the tests that now use Jakarta Deployment to deploy tests can be updated to use whatever the web profile tests are using?

I'm guessing that @dblevins is talking about the com/sun/ts/tests/servlet/ee/platform/negdep tests calling Jakarta Deployment classes, with regard to the TCK using Jakarta Deployment itself to deploy tests unrelated to Jakarta deployment.

Currently, the src/com/sun/ts/lib/harness/keyword.properties file has the negdep tests as javaee_web_profile_optional but that doesn't really help us, but thought I would mention it:
com/sun/ts/tests/servlet/ee/platform/negdep = javaeedeploy javaeedeploy_optional javaee_optional javaee_web_profile_optional

IMO, if we replace use of Jakarta Deployment with a new Platform TCK porting layer SPI (e.g. jakarta.enterprise.deploy.* or something), then we could update the com/sun/ts/tests/servlet/ee/platform/negdep tests to use that.

Another (later) option could be removing the src/com/sun/ts/tests/servlet/ee/platform/negdep tests if we cannot get them to work.

[scottmarlow]

Started some minimal changes on scottmarlow/jakartaee-tck/tree/prunedeployment that just removes j2eetools/deploy tests and updates related files that reference them.

[scottmarlow]

Regarding the tests that deploy tests unrelated itself to Jakarta Deployment, they appears to be under com/sun/ts/tests/servlet/ee/platform/negdep, which I think are technically Jakarta Deployment related as per how they are classified in keyword.properties:

com/sun/ts/tests/servlet/ee/platform/negdep = javaeedeploy javaeedeploy_optional javaee_optional javaee_web_profile_optional

So, if we pruned Jakarta Deployment from Jakarta EE 9, I think that we should also remove the negative deployment tests.

user_guides/jakartaee/src/main/jbake/content/using.adoc, shows the mapping of Jakarta Deployment to javaeedeploy_optional:

Table 7-1 Keyword to Technology Mappings for Full Profile Optional
|Jakarta Deployment |`javaeedeploy_optional` or `javaee_optional`

Based on this, I'll add a commit for removing the com/sun/ts/tests/servlet/ee/platform/negdep tests.

[scottmarlow]

Since GlassFish 6.0 is expected to remove the pruned Jakarta Deployment classes, what should the com.sun.ts.lib.implementation.sun.javaee.SunRIDeployment2 use instead of Jakarta Deployment?

[scottmarlow]

Could GlassFish 6.0 switch to use com.sun.ts.lib.porting.TSDeploymentInterface based deployment via com.sun.ts.lib.implementation.sun.javaee.glassfish.AutoDeployment?

Some comments from AutoDeployment:

This class implements the TSDeploymentInterface. It does so by copying
to/from the V3 autodeploy directory and delegates out to ant build files
under bin/xml/glassfish/deploy.xml

[scottmarlow]

It seems to me that the Jakarta Platform TCK already has a standard SPI that can work without Jakarta Deployment and that is com.sun.ts.lib.porting.TSDeploymentInterface, so no new SPIs are needed.

Option C doesn't really make sense as com.sun.ts.lib.porting.TSDeploymentInterface2 is different than com.sun.ts.lib.porting.TSDeploymentInterface.

Will take another look at Option B.