@Pandrex247 can you please run the full TCK on this branch? It'll probably supersede #7212 because the other PR is become stale.

Argh. Test are failing b/c eclipse foundation servers are down including MP repositories. See https://www.eclipsestatus.io

@Pandrex247 Can you please run the full TCK on this branch (even if you ran it before) as I committed some more changes here.
Thank you

@Pandrex247 Please run all TCKs on this branch. This should fix the Web Profile TCK

Just FYI- I am mucking with the commit messages via force-push, the code remains the same

The Platform TCK is still running, but the Web Profile TCK has passed 🥳

Any updates? :) :)

if everything succeeded, can you please kick off full TCK again just to make sure I haven't messed anything up?
Thank you.🙏

It passed 🥳
I will kick off another run for your new changes

Last changes just remove unused code from the PR. No need to run the TCK. Ready to merge.

@lprimak Is this new PR still compatible with the one I last checked with our real-world EAR? If not, looking at the horrible history of the last PR, we might should wait with the merge for another test drive? 🤔

No worries. This PR is a rebase to main plus some unused code cleanup and review suggestions. It contains all our fixes and was tested against all our reproducers.
Feel free to test against Quipsy of course but I feel confident that everything is as it should be.

Thank you, Lenny! Ok, in this case I see no need for more pre-release checks and will test just the final CE 6.2022.5. 😅

@Pandrex247 Will this PR be contained in Payara CE 6.2025.5?

My guess is probably not

Don't forget about me :)

@mkarg No this won't be included in 6.2025.5.
@lprimak I am currently deep into a major rework of the codebase (almost finished I hope) - reviewing and getting this merged (along with documenting the new configuration options) is next on my to do list

Thank you

@Pandrex247 Will this PR be contained in Payara CE 6.2025.5?

@mkarg No this won't be included in 6.2025.5. @lprimak I am currently deep into a major rework of the codebase (almost finished I hope) - reviewing and getting this merged (along with documenting the new configuration options) is next on my to do list

"Deep rewrite" sounds like it makes sense to let me run a test drive with that before publishing?

@mkarg Nah it should be harmless - changing maven group IDs and build config around.

@lprimak
Not to throw a wrench into things, but can you explain to me how warlibs is different to applibs?
I'm trying to write some documentation for you and struggling to understand the difference.

Is it just that when --warlibs is enabled all libraries stored under domain_dir/lib/warlibs will be loaded, whereas applibs have to be added explicitly one by one (--libraries wibbleLib,wobbleLib)?
Is your new option essentially doing --libraries *?
Or is it doing something different?

See payara/Payara-Documentation#598 & flowlogix#6

If --properties warlibs=true is functionally identical to --libraries * it might be worth a follow-up iteration (can be done in a separate PR, I don't want to hold this one up in the name of perfection) to just have --libraries * be an acceptable option over adding a separate domain_dir/lib/warlibs directory.

My mind is currently circling around the following:

• If the behaviour is as I described, --libraries * seems to be a more "intuitive" way of achieving this over adding a completely separate directory and deployment option
• I want to do some testing on if this extra directory is actually synchronised correctly: to-resynchronize-library-files

Reading through #6405 again I can see that you already mentioned including libs in applibs doesn't seem to get them scanned by CDI - so I guess my root question is: why the new folder? Why not just fix/add CDI scanning to applibs? Was it to have some sort of differentiation?

Trust me, it was my first thought to "fix" applibs. However this turned out to more complicated and I didn't want to break existing functionality.

The main point behind warlibs is to improve deployment times for developers, and to get instant feedback on code modifications.
It allows to make skinny WARs for development and shift all dependencies into payara domain so they only get loaded (including annotation processing and all initialization) once.

Here is the difference breakdown:

• adding --applibs x,y,z isn't enough. The libraries also need to be listed in MANIFEST.MF of the "cient"
• applibs are not cached, as warlibs are, i.e. if you replace lib in applib/ and redeply it'll get updated, warlibs won't.
• warlibs get annotation and extension scanning and processing, including for CDI, EJB, Servlet and such. applibs don't.

I am not sure where / how applibs are used but I am sure that I couldn't make it work without breaking compatibility.

Regarding "resync", since warlibs feature is for development, I don't think that would apply.

Thanks for the extra info, I'll look into adding that to the docs in some way.

Regarding "resync", since warlibs feature is for development, I don't think that would apply.

I tested the resync - it appears to work.
I was worried that the extra lib directory wouldn't be synced across to a remote instance (e.g. if the sync of files to the remote instance wasn't just "lib/*"), but they seem to be synced just fine 👌

Well, this was the biggest scope creep in "my" history.
What was supposed to be a 3-day project turned into 9-month, close-to-1000hrs of work for me, not to mention
Markus, Andy, and like 10 other devs who got touched by this.

And still not done.
This tranche culminates in another "3-day" project: #7165

Also time to introduced the ecosystem enhancement described here: payara/ecosystem-support#98 to make use of this