[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jakartaee-tck-dev] Removing unused imports/wildcards from TCK tests and collecting Platform TCK dependencies to help with the (possible) Platform TCK test refactoring that we need to start talking about soon ...
|
Hi Lance,
Thank you for responding!
The main focus is identifying the different test dependencies which I
think will be helpful.
On 12/10/20 12:47 PM, Lance Andersen wrote:
Hi Scott,
There may not always be a platform spec assertion tag so something to
consider when reviewing why platform spec assertions may or may not be
present.
Point well taken! We are trying to simplify the SPEC API development
process for the different SPEC API teams. I now see that I overstated
the relevance of there being zero platform spec assertion tags.
A couple of quick examples:
- The platform spec will define requirements that might not result in a
specific assertion tag in a test. Example that an API, such as JSONP
must run in all containers and this would be done via a vehicle test.
Good point.
As mentioned on
https://github.com/eclipse-ee4j/jakartaee-tck/issues/583#issuecomment-742093541
by Ed Bratt which I will quote:
"
We need to be sure that new features that are added to any TCK are
imported to the Platform TCK.
Also, if the Platform has other requirements (i.e. run in different
modes, and/or containers) those are achievable.
We may want to try and coalesce these discussions to come up with a
combined strategy everyone can adopt.
"
I quoted the above as it nicely summarizes that the Platform TCK still
needs to cover the Platform SPEC requirements and that cooperation is
needed between the SPEC API teams + Platform TCK team. At least that is
a requirement until someone can point out a better/simpler/possible way
for Platform level testing to be in the SPEC API TCKs.
- JSTL outside of being required to be supported by JSP within the Full
Platform would not have Platform spec assertion tags.
Good point.
- signature tests this is (or was at least in the case of Java EE)
defined in the spec license that you had to agree to for creating an
implementation.
+1
- Some APIs may only be required to run in specific containers,
transaction modes… etc. These also would not have a Platform Spec
assertion in many cases depending on how the test built.
+1
Hope the above helps clarify what seems obvious is not obvious :-)
+1
Scott
Best
Lance
On Dec 10, 2020, at 12:03 PM, Scott Marlow <smarlow@xxxxxxxxxx
<mailto:smarlow@xxxxxxxxxx>> wrote:
I updated the script for extracting the TCK test dependencies and
updatedhttps://urldefense.com/v3/__https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nlnZJ051g$
<https://urldefense.com/v3/__https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nlnZJ051g$> with
the results as well.
Thehttps://urldefense.com/v3/__https://github.com/scottmarlow/jakartaee-tck/tree/optimize_imports_eclipse__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nnQ6w1JUw$
<https://urldefense.com/v3/__https://github.com/scottmarlow/jakartaee-tck/tree/optimize_imports_eclipse__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nnQ6w1JUw$> branch
was used to collect this information as many unused Java imports were
dropped.
From ^, we can see which test groups contain Platform SPEC assertions
versus which do not.
The test groups that do not have Platform SPEC assertions are:
Concurrency, ejb32, el, jacc, jaspic, jaxrs, jaxws, jsf, jsonb, jsonp,
jsp, jstl, jws, saaj, securityapi, signaturetest, webservices13,
websocket, jbatch.
Also note that only the Jakarta SPEC API dependencies are shown to
highlight which Jakarta SPEC API dependencies are needed for each test
group. If your interested in seeing the other dependencies as well,
let me know.
I intend to soon start a discussion thread that cross posts against
multiple SPEC API mailing lists, the Platform TCK mailing lists and
possibly some others. This is going to be a messy discussion that
will naturally fork.
My best (or possibly worse :-) idea is to also include
thejakarta.ee-community@xxxxxxxxxxx
<mailto:jakarta.ee-community@xxxxxxxxxxx>mailing list which I hope
that everyone is on but it is possible that some SPEC API mailing list
members won't be on that.
I don't own the discussion that I would like to start, however as lead
of the Platform TCK I am responsible for getting it started and doing
it in a way that allows us to collect feedback from SPEC API teams
that may be developing new SPEC API versions soon and interested in
maintaining a SPEC API level TCK.
Of course, I do hope that all will join the Platform TCK mailing list
for this discussion. It is listed
onhttps://urldefense.com/v3/__https://jakarta.ee/connect/mailing-lists__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nk3euGz3g$
<https://urldefense.com/v3/__https://jakarta.ee/connect/mailing-lists__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nk3euGz3g$>,
along with others, not too difficult to join any Jakarta EE mailing. :)
In summary, I think that
thehttps://urldefense.com/v3/__https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nlnZJ051g$
<https://urldefense.com/v3/__https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nlnZJ051g$>report
currently gives us:
1. The test groups that contain Platform SPEC specific tests, as well
as the test groups that contain no Platform SPEC specific tests.
2. The test groups that contain no dependencies on other Jakarata EE
SPEC APIs, as well as the other test groups that do (and the
dependencies).
This information should assist the teams in deciding which tests may
be easier to move to a respective SPEC API repo level TCK.
We also highlight the test groups with Platform SPEC level tests that
must exist somewhere.
We also highlight the Jakarta SPEC API test dependencies that each
test group has. This helps us to understand whether multiple SPEC API
integration TCKs are needed versus a SPEC API specific TCK (or
possibly both).
Scott
On 12/2/20 3:13 PM, Scott Marlow wrote:
On 12/2/20 11:01 AM, Frederic Gurr wrote:
On 02.12.20 15:57, Scott Marlow wrote:
Are there other editors that might better handle removing unused
imports
+ wildcard imports?
Have you heard of the Eclipse IDE? It's supposed to be quite good. ;)
So with Intellij, not all of the Java wildfly imports were eliminated
(unless I manually opened individual files and removed imports from
there).
With Eclipse, other than some mistake that I must be making in
creating the workspace/project that leads to deletion of a bunch of
xml files under the TCK bin folder (easy to `git restore bin/*.*` to
workaround), the Eclipse `Organize imports` works really well.
After eliminating the unused Java imports, I ran
thehttps://urldefense.com/v3/__https://gist.github.com/scottmarlow/d4a13d15e7c0ea83d35004445b4b84f0__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nleV2N6Aw$
<https://urldefense.com/v3/__https://gist.github.com/scottmarlow/d4a13d15e7c0ea83d35004445b4b84f0__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nleV2N6Aw$>script
again and produced a
reporthttps://urldefense.com/v3/__https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nlnZJ051g$
<https://urldefense.com/v3/__https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nlnZJ051g$>that
shows the per (Jakarta EE Platform TCK) test group dependencies and
number of Platform SPEC assertions as well (per test group).
I'll look at creating a pull request after I
runhttps://urldefense.com/v3/__https://github.com/eclipse-ee4j/glassfish-copyright-plugin__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nnAeHx_5A$
<https://urldefense.com/v3/__https://github.com/eclipse-ee4j/glassfish-copyright-plugin__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nnAeHx_5A$> to
update the Copyright dates.
Fred, thanks for the encouragement to try using the Eclipse IDE to do
the refactoring! :-)
SCNR
Regards,
Fred
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx <mailto:jakartaee-tck-dev@xxxxxxxxxxx>
To unsubscribe from this list,
visithttps://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nlVJTl21g$
<https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!GqivPVa7Brio!NRgU8He-VnpynSDQuoeL_i7woVFGjCr0zgnupTGRtkUAp0mzOCj7VWF6-nlVJTl21g$>
Best
Lance
------------------
Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen@xxxxxxxxxx <mailto:Lance.Andersen@xxxxxxxxxx>
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev
