| Re: [jakartaee-platform-dev] Question about removing Jakarta Deployment (JSR-88) in Jakarta EE 9 porting package... |
|
Thanks Kevin. Let me rephrase, will it be easier for the GlassFish project, when running the TCK, if we keep the deployment api? Steve From: jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Kevin Sutter Steve, I’ve just pruned that api from GlassFish so I’m not understanding the implications. Do I need to put it back? From:jakartaee-platform-dev-bounces@xxxxxxxxxxx <jakartaee-platform-dev-bounces@xxxxxxxxxxx>
On Behalf Of Scott Marlow 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_______________________________________________ |