| Hi Scott,
Given the compat tests are to validate compatibility with J2EE 1.2/3, you might consider just nuking them. Those tests were never re-built from what I recall as part of the CTS delivery.
HTH Lance
I updated https://github.com/eclipse-ee4j/jakartaee-tck/issues/313 to group the tests into different technologies (Servlet, JSP, JSTL, EJB). I also removed the now pruned tests from the list.
I'm thinking that we should create separate pull requests (as suggested before) for removing the tests for each specification. To be referenced in the specification level issues that we raise.
Fair point, Ed. Thanks
for the clarification.
---------------------------------------------------
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:
jakartaee-tck
developer discussions <jakartaee-tck-dev@xxxxxxxxxxx>, Kevin Sutter
<sutter@xxxxxxxxxx>
Date:
06/11/2020
11:50
Subject:
[EXTERNAL]
Re: [jakartaee-tck-dev] Platform TCK run started
Kevin, I was responding to the general
comment about supporting legacy applications. Seems that is a broader question
than EJB (to me anyway).
-- Ed
On 6/11/2020 9:26 AM, Kevin Sutter wrote:
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
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
_______________________________________________ jakartaee-tck-dev mailing list jakartaee-tck-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037Oracle Java Engineering 1 Network Drive Burlington, MA 01803Lance.Andersen@xxxxxxxxxx
|
