Merge 6.x to master #23843
Merge 6.x to master #23843
Conversation
Signed-off-by: Arjan Tijms <arjan.tijms@gmail.com>
Next version is 6.2.6-SNAPSHOT
Merge 6.2.5 branch
- generated by tests
- still used j2ee.jar - mixed tabs and spaces - removed dead tests
…nd other dead tests
- dead tests - mejb or JAX-RPC dependency
- wsdl variable can be null - reproduced by some test enabled in recent commits
- fixes issue reproducible by some of naming_all tests when using cluster instances
- respects some externally set env properties - removes glassfish before execution - detects glassfish version automatically
- bug was reproducible by several tests from recent commits - removed endorsed as it is not supported any more
…everal bugs - reproducible by several tests enabled in recent commits - removed incorrect wrapping of zip into zip - fixed error message, reported input file as an output - fixed closing streams - fixed removing corrupted files (stream could be still open) - fixed behavior when the glassfish-acc.xml file is missing
- lazy init, but then crashed - MEJB is not supported any more, see specification of Jakarta EE 9.1
…e tests on jenkins
Enhanced runtests.sh and reenabled another block of tests
# Conflicts: nothing much complicated
|
Blocked by this: eclipse-ee4j/metro-wsit#161 |
Since that one has now been unblocked (thanks to you and @lukasj), can we now proceed with this PR? |
|
Goood! Can we have 4.0.0-M4? Or do I have to add another snapshot build? |
|
@lukasj I can stage a 4.0.0-M4 too for Metro (WSIT, or WebServices) if needed. |
|
M4 is planned to be in the last week of March to accommodate changes from dependencies/subprojects. My hope is that grizzly (which I've already asked for back in Jan) will be ready by then and M4 will be the last milestone before the final release. Not sure it was observed that main metro parts (jaxb/jax-ws-ri/wsit) do have M builds on a ~monthly basis and the version number is synced through these projects to make it easier to track changes. I'd like to keep this pattern. |
If I'm not mistaken @dmatej is working on that as we speak ;) Not every part of it appeared to be trivial, but process is being made.
It's sometimes difficult to keep patterns when you're part of a larger project. If everyone would stick to a monthly pattern, then it would take more than 2 years (27 months), give or take, until we could release GF 7. |
|
Where does the "larger project" have its rough schedule, so those being included there can plan their work as needed? Is the whole work supposed to be "one-man show" or collaborative effort? |
I am working on that today, I was without electricity yesterday.
I would see it as some event-driven automat with multiple actors, where every actor works (or asks for help) on anything he requires for an actual project. Schedules are rather orientation points then. |
The rough schedule is the Jakarta EE 10 release plan (https://eclipse-ee4j.github.io/jakartaee-platform/jakartaee10/JakartaEE10ReleasePlan) and specifically for GlassFish there's the tracking board here: https://github.com/eclipse-ee4j/glassfish/projects/3 With so many projects it is indeed mostly event driven. We have about 10 contributors for the 7 release https://github.com/eclipse-ee4j/glassfish/graphs/contributors?from=2021-11-03&to=2022-03-15&type=c although some are helping by preparing dependencies in their own repos (like Scott for Hibernate Validate) and don't show up directly in that graph. |
|
that project board show no dates as does the release plan. It says nothing about estimated target dates for GF RCs/final builds, it also says nothing about GF weekly(?)/milestone builds. It really does not help to align releases of component CIs with GF release - at least those I'm somehow responsible for and I can help with (~11 top-level projects from > 30repos). Events as such are fine and should definitely be responded to, yet some time-buffer should be expected. btw: I did not say you can't do some metro-4.0.0-gf1 (or whatever keeps treating current M3 as the latest) build if you really need it a week ago ;-) |
- fixed which maven uses which settings.xml - invoker builds with the custom settings.xml - invoker builds projects in parallel threads - fixed relativePath - added properties to settings.xml - skip everything not required
- servlet6 - grizzly 4 snapshot - webservices 4 snapshot Signed-off-by: David Matějček <dmatej@seznam.cz>
|
So, current status + dependency tree:
|
No description provided.