Scott,
The Jakarta EE
9 release itself can not include any javax.* packages. So, that is
out of the question. But, if the TCK wants or needs to support back
packages (such as Deployment), I would liken that to an App Server that
wishes to support past releases of Java EE or Jakarta EE. I think
the bigger issue for the TCK is that you probably need more than just the
APIs. You probably also need an implementation, and where would you
get that from? Glassfish? Since Glassfish is planning on pruning
Deployment from their Jakarta EE 9 release, would the TCK team step up
to support the implementation in this unique environment? Another
concern with this approach is whether the TCK has any other dependencies
on Jakarta EE technologies. We (Open Liberty) have found that attempting
to mix-and-match between javax and jakarta is an extremely difficult proposition.
I'd question how
many of the Jakarta EE compatible implementations actually rely on Deployment
for their TCK testing. We (Open Liberty) do not. It would be
good to understand how big of an issue this is before exploring the continued
use of Deployment in the TCK.
Personally, I'd
take a look at Option C and attempt to remove this dependency. But,
I have no idea on how big of an effort this would be...
I'll respond again after researching this more. The feedback given so far is very useful, as I wanted to know which options are valid.
Regardless of which option is used, the testing of Deployment (JSR-88) will be removed, as per pruning of Deployment. So, I agree that GlassFish 6.0, should not add Deployment support back in.
Scott
---------------------------------------------------
Kevin Sutter
STSM, MicroProfile and Jakarta EE architect @ IBM
e-mail: sutter@xxxxxxxxxx Twitter: @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)
LinkedIn: https://www.linkedin.com/in/kevinwsutter
From:
Scott
Marlow <smarlow@xxxxxxxxxx>
To:
jakartaee-platform
developer discussions <jakartaee-platform-dev@xxxxxxxxxxx>
Date:
04/27/2020
09:00
Subject:
[EXTERNAL]
Re: [jakartaee-platform-dev] Question about removing Jakarta Deployment
(JSR-88) in Jakarta EE 9 porting package...
Sent
by: jakartaee-platform-dev-bounces@xxxxxxxxxxx
Hi,
Could the Eclipse Jakarta Platform TCK
9.0.0 release include the javax.enterprise.deploy.spi interfaces, in support
of the porting package use of the (pruned in EE 9) Jakarta Deployment API?
This might help Eclipse Jakarta EE implementations
that currently use the Jakarta Deployment API for their TCK testing.
Note that EE 9 implementations are not
expected to include (pruned) Jakarta Deployment API/implementation classes,
but that is a different issue than I'm asking about.
Scott
On Wed, Apr 22, 2020 at 1:46 PM Scott
Marlow <smarlow@xxxxxxxxxx>
wrote:
Hi,
The jakartaee-tck/issue#211 [1] issue
is for removing the Jakarta Deployment (JSR-88) use from the Jakarta EE
9 Platform TCK. Comment [2] mentions a few options for how the EE
9 Platform TCK could deal with removal of (pruned) Jakarta Deployment from
Jakarta EE 9.
I'm especially concerned about Jakarta
EE 8 implementations that actually implement Jakarta Deployment (JSR-88),
as in your Jakarta EE 9 implementation, you will not likely still have
your Jakarta Deployment code for the Platform TCK to use.
I added three options to [2], that I
would like input on.
Option A, is for adding the javax.enterprise.deploy.spi
interfaces to the Jakarta EE 9 Platform TCK, so that the Platform TCK can
continue to depend on them and in theory, your Jakarta EE 9 implementation
could as well. Basically, this means that you could keep using your
Jakarta Deployment implementation code for TCK testing but do not have
to actually include those classes in your Jakarta EE 9 server implementation.
Option B, is basically the same, however
it switches to a different package name for the javax.enterprise.deploy.spi
classes.
Option C, is for removing all of the javax.enterprise.deploy.spi
dependencies from the Platform TCK, meaning that Jakarta EE 9 implementations,
will need to provide a porting package implementation based the on com.sun.ts.lib.porting.TSDeploymentInterface,
which doesn't depend on the javax.enterprise.deploy.spi classes.
Any other ideas or more to add?
Scott
[1] https://github.com/eclipse-ee4j/jakartaee-tck/issues/211
[2] https://github.com/eclipse-ee4j/jakartaee-tck/issues/211#issuecomment-617868811_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev
_______________________________________________
jakartaee-platform-dev mailing list
jakartaee-platform-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-platform-dev