Re: [jakartaee-tck-dev] Removing unused imports/wildcards from TCK tests

[Scott Marlow <smarlow@xxxxxxxxxx>]

I updated the script for extracting the TCK test dependencies and 
updated 
https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7 
with the results as well.  The 
https://github.com/scottmarlow/jakartaee-tck/tree/optimize_imports_eclipse 
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 the 
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 on 
https://jakarta.ee/connect/mailing-lists, along with others, not too 
difficult to join any Jakarta EE mailing.  :)



In summary, I think that the 
https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7 
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 the 
> https://gist.github.com/scottmarlow/d4a13d15e7c0ea83d35004445b4b84f0 
> script again and produced a report 
> https://gist.github.com/scottmarlow/0e31e5256507ad0e5c78b3f274d8d4a7 
> 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 run 
> https://github.com/eclipse-ee4j/glassfish-copyright-plugin to update the 
> Copyright dates.
>
> Fred, thanks for the encouragement to try using the Eclipse IDE to do 
> the refactoring!  :-)
>
> > SCNR
> >
> > Regards,
> >
> > Fred