Re: [jakartaee-tck-dev] Platform TCK run started

["Kevin Sutter" <sutter@xxxxxxxxxx>]

Scott,
Since your questions
are specific to the EJB tests, I think you should start with the EJB dev
team and how they wish to maintain their test buckets.  Although there
is some overlap between the EJB and Platform teams, this question about
the EJB tests should be started with them.

https://accounts.eclipse.org/mailing-list/ejb-dev

---------------------------------------------------
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:
       Ed
Bratt <ed.bratt@xxxxxxxxxx>
To:
       Scott
Marlow <smarlow@xxxxxxxxxx>
Cc:
       jakartaee-tck
developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>
Date:
       06/11/2020
09:46
Subject:
       [EXTERNAL]
Re: [jakartaee-tck-dev] Platform TCK run started
Sent
by:        jakartaee-tck-dev-bounces@xxxxxxxxxxx

---

I believe we should check with the Platform
Committer team. I think that it was concluded that directly migrating legacy
applications won't supported without some kind of transformative action.
That could be using the results of the
Eclipse Transformer project or it could be something else. Perhaps, for
now, we should file an issue and disable these tests until we know what
the consensus solution should be. If the answer is do nothing and leave
them out, we can just remove the tests and close the issue(s).
Scott, can you summarize the issue(s)
here and raise it to the Platform committer (jakartaee-platform-dev@xxxxxxxxxxx)
team?
-- Ed
On 6/11/2020 7:11 AM, Scott Marlow wrote:


On Wed, Jun 10, 2020 at 10:22 PM Scott
Marlow <smarlow@xxxxxxxxxx>
wrote:


On Wed, Jun 10, 2020 at 9:33 PM Ed Bratt
<ed.bratt@xxxxxxxxxx>
wrote:
I don't know. Since we are trying to
get all the name-space issues ironed out -- 
I created https://github.com/eclipse-ee4j/jakartaee-tck/issues/317that includes validating that any remaining javax.* classes referenced
are correct.
I am not sure it will be very worthwhile
to try and diagnose problems that crop up after we find there are still
name-space issues in the packages. I'd try to get those issues corrected
first since they suggest that the Jakartification work isn't quite finished
yet.
https://github.com/eclipse-ee4j/jakartaee-tck/pull/316is for updating to the EE 9 XSDs in the tests.

pull/316 is merged.  Once https://github.com/eclipse-ee4j/jakartaee-schemas/pull/9is merged, we can also replace http://java.sun.com/xml/ns/j2ee/web-jsptaglibrary_2_0.xsdwith http://jakarta.ee/xml/ns/jakartaee/web-jsptaglibrary_3_0.xsd.

I'll start a new TCK run so we can see
if there is any improvement.
 

https://github.com/eclipse-ee4j/jakartaee-tck/issues/313is open for updating the application archives that contain javax.ejb.SessionBean
class references, to use jakarta.ejb.SessionBean.  Please also refer
to comment https://github.com/eclipse-ee4j/jakartaee-tck/issues/313#issuecomment-642359469that explains how these archives are testing backward compatibility with
older EE versions.  

In theory, we could run these archives
through a bytecode transformer (statically or during the test run), but
IMO that isn't really required to be done.  For discussion, should
we:

a.  Transform or rebuild the legacy
application archives to reference jakarta.ejb.SessionBean?

b.  Remove the testing of these
legacy application archives?

c.  Something else?

Imo, I think that we have to look deeper
to see what we would be losing if we did (b).  Is there a viable (c)
option?

See discussion on https://github.com/eclipse-ee4j/jakartaee-tck/issues/313. 
I think that we need to understand if pruning/removing the tests for (c),
would require us to open issues for any of the underlying specifications
that are tested with any of the mentioned (not built for EE 9) archives,
to notify those specification teams that the tests are being removed.

Also, I am wondering if any of Common
Applications Deployments can actually be deployed by TSDeploymentInterface
deployment mechanism (related documentation stated that TSDeploymentInterface2
is needed).  When we removed the Jakarta Deployment tests, we considered
whether we need to also remove the Common Applications Deployment support
and decided to keep that in place, until we see reasons to fix or remove
them.  
 

Scott
-- Ed
On 6/10/2020 2:22 PM, Scott Marlow wrote:


On Wed, Jun 10, 2020 at 4:54 PM Ed Bratt
<ed.bratt@xxxxxxxxxx>
wrote:
Scott,
In the domain log, of [1], the very first
exception trace at line 335 includes javax.security which is probably
not correct.
If this isn't expected, I would posit
that it could be difficult to interpret results while there are still name-space
errors.
Ed,

In that first exception trace, I do see javax.security.auth.Subject,
which has almost the same package as https://github.com/eclipse-ee4j/authentication/tree/master/api/src/main/java/jakarta/security/authbut Subject is not there.  Subject is still in SE 11+, so any issue
here?

Scott

-- Ed
[1] https://ci.eclipse.org/jakartaee-tck/job/jakartaee-tck/job/master/682/artifact/connector-results.tar.gz_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev