| Re: [jakartaee-tck-dev] [External] : Re: Draft pull request for adding Maven pom to each Platform TCK test folder... |
On 8/30/21 7:24 PM, Scott Marlow wrote:
On 8/30/21 12:04 PM, Lukas Jungmann wrote:
On 8/30/21 5:32 PM, Scott Marlow wrote:
On 8/24/21 2:49 PM, Scott Marlow wrote:
As a next step, I'm thinking we should convert each test module to follow the Maven `src/test` or `src/main` convention.
To (start) addressing issue 51 [1], [2] adds a minimal maven `pom.xml` to each test folder using the existing test directories. There are missing dependencies currently (so expect build failures), some that need to be discussed as to how to address (e.g. com.sun.javatest).
We are building still with Java SE 8 and will switch to Java SE 11 soon enough.
If anyone wants to improve the initial pom.xml files, your help is greatly appreciated!
are you going to provide a script which does this conversion in master at any point in time?
We are keeping the master/main branch available for EE 10 test changes but once we have have confidence that we can pass all of the TCKs with Maven/Arquillian, we can update the master/main branch.
the benefit of such script is that both work can happen in master at the same time. One may only need to temporarily add few more items to .gitignore; some files, such as poms, may exist next to existing ones (even though I'd prefer to keep them on some other place to not confuse people too much and to allow those working on these changes to see them all in one place - if needed). Actual switch would be just a matter of committing script's output and creating a PR, a script itself can also work as the documentation...
Perhaps we can script something to update the commits that we want to sync with the `tckrefactor` branch (using git filter-branch or friends like https://stackoverflow.com/questions/3142419/how-can-i-move-a-directory-in-a-git-repo-for-all-commits).
Anyway, the challenge now is to get the EE 10 TCK refactoring done.
I'm not against the idea of using a script to convert each existing test folder to the Maven directory structure, IMO, that sounds very useful!
Something we've used in other projects like[1] or [2] - it may help others to easily join the effort, one does not necessarily need to maintain an extra branch, merging changes etc...
IMO, many of the changes will be deep and too difficult to maintain via scripts.
will those deep changes require "merge to master" at some point as well? Can some of them be done directly in master in a way current build is not negatively impacted and requirement of the new build is satisfied? We're not living in an ideal world, but if we live, then no merge awaits us ...
By no means I'm saying it will be easy, nor that one way is easier than the other.
Are you thinking that EE 10 test contributors will want to only create a pull request against the master/main branch and not have to deal with updating the tckrefactor branch?
Yes. With two branches it's an overhead for you(?) to keep an eye on all changes coming in to be sure they get to the right places as well as for every contributor who adds new test(s) to not forget to create 2 PRs. Unless there will be someone doing regular(?) merges between those 2 branches.
thanks,
--lukas
Thanks,
Scott
thanks,
--lukas
[1]: https://github.com/rfelcman/eclipselink/tree/Mavenize_EclipseLink/buildsystem/mavenize
[2]: https://github.com/javaee/metro-jax-ws/tree/jaxws228x/_migration
I'm not sure of
any strong reasons to prefer one other the other but if anyone does, please speak up. From a quick look, I see github.com/eclipse-ee4j/cdi-tck + github.com/eclipse-ee4j/batch-tck using `src/main` for test sources and github.com/eclipse-ee4j/beanvalidation-tck using `src/test` for test sources.
Scott
If anyone wants to help eliminate the Java Test harness (com.sun.javatest [4]) missing dependencies in [2], your help is greatly appreciated! This is an area that we need to explore to understand more. Whomever looks at this part, needs to come up with different paths that we can choose from.
We can discuss more on the September 8th (or 9th depending on your time zone) TCK zoom call [5]. Note that [5] is the TCK call agenda document and contains a link to the (Jakarta EE Specifications) calendar.
The initial refactoring goal is to have a place to explore updating each test folder to be able to run TCK tests against the different EE container test vehicles with JUnit5/TestNG + Arquillian.
We also will integrate with any EE container tests produced by any of the Spec API teams (e.g. see [6][7] for possible examples).
Scott
[1] https://github.com/eclipse-ee4j/jakartaee-tck/issues/51
[2] https://github.com/eclipse-ee4j/jakartaee-tck/pull/735
[3] https://github.com/eclipse-ee4j/jakartaee-tck/tree/tckrefactor
[4] https://github.com/openjdk/jtharness
[5] https://docs.google.com/document/d/1V1dDLJkd14EDRMPeuI0VzPtU4Lbli8FFBd1pLDLlOrY/edit#
[6] https://github.com/eclipse-ee4j/batch-tck/
[7] https://github.com/eclipse-ee4j/jaxrs-api/pull/1002
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://urldefense.com/v3/__https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev__;!!ACWV5N9M2RV99hQ!fWnwEPVsLIJJpyREI4TQy_9Kdk7E9VSb00mPiY2xGIuXD2GavZ857OMafkcTFkQqdVs$
_______________________________________________
jakartaee-tck-dev mailing list
jakartaee-tck-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev