Re: [jakartaee-tck-dev] Preparing to hack with ReWrite...
On 11/20/22 8:31 PM, Olivier Lamy
I have started some work.
But is there any reason to split runtime and glassfishtck?
On a case by case basis, IMO we should move sources that we don't
think are going to be needed by the actual refactored TCK tests,
into a `to_be_deleted_later` folder.
It would also be good to isolate the GlassFish TCK into a
separate folder that other test sources do not reference.
Trying to have a clean (e.g at least compiling) I have to
re enable those modules.
And there are some circular dependencies between both.
At the end of the day, those modules will be removed?
I think the test harness and other runtime sources will be
removed as they serve no purpose.
I'm not sure about the GlassFish TCK porting kit. David, Guru,
Alwin do you have a preference for where the GlassFish TCK porting
kit should live?
I'm not sure adding more tooling will fix anything
(except making it more complicated by adding more tooling
I have some issues on how the current tckrefactor build
structure (e.g pom content), I have some changes in my
branch with the servlet tck using arquilian. 
But I didn't to fix too many things in this branch as
the merge/rebase will be an even worst nightmare for me
Some content I have in mind which looks wrong (or I
don't understand the reason) to my (long) Maven
Why having everything in <dependencies>  in
parent pom, this mean by example servlet or jsp will have
batch or jms as dependency?
Why having this section with m-enforcer-p  is
I don't understand the need of using of
build-helper-m-p  in every poms? we probably only need
to have the sources in the standard Maven location.
If your concern is about having a clean build (e.g no
compile issue) in the tckrefactor branch if you need a
volunteer I can have a try for the next few days.
jakartaee-tck-dev mailing list
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakartaee-tck-dev