5 p.m.
The following branches in the incubator are the proposed changes that will
kick this off for the 2.x releases of WildFly Elytron: -
https://github.com/wildfly-security-incubator/wildfly-elytron/tree/2.x
https://github.com/wildfly-security-incubator/wildfly-elytron-ee
https://github.com/wildfly-security-incubator/wildfly-elytron-mp
I have verified that we can still use the tools provided by git to merge
from the 1.x branch to the three new branches / repos so development for
WildFly will continue in the existing 1.x branch.
Most importantly I can also apply the changes to the master branch of
Elytron as used by Quarkus so I can create them a .Final release without EE
or MP dependencies and without causing the repo to yoyo between Jakarta EE
8 and 9 as that is handled in independent modules.
The modules that have been split out retain the same group and artifact ID
as they had when contained within the main Elytron project, the only
difference with this change is that they will no longer be shaded into the
wildfly-elytron jar.
Regards,
Darran Lofthouse.
On Tue, Jan 28, 2020 at 2:19 PM Darran Lofthouse <darran.lofthouse(a)jboss.com>
wrote:
At some point in the future we are going to need to consider a
migration
to Jakarta EE 9 so I just wanted to raise some ideas as to how we may
choose to structure the project.
As it stands today our 1.x releases are being used for WildFly and in each
release we are maintaining compatibility of the public API against the
previous releases. We have also started with our 2.0.x releases where some
compatibility has been broken to clean up inter package dependencies, we
were planning to tag this as .Final for Quarkus.
If we are going to switch to Jakarta EE 9 which means new packages for the
specifications that feels like we should handle that with a major version
bump. My first idea was we move master to 3.x and insert a new 2.0.x
release which maintains compatibility with 1.x other than the Jakarta
changes but considering other requirements on us that would lead us to: -
* Elytron 1.x - Jakarta EE 8
* Elytron 2.x - Jakarta EE 9
* Elytron 3.x - Jakarta EE 8
* Elytron 4.x - Jakarta EE 9
So instead to simplify our versioning I was going to consider we pull the
spec related modules out into their own projects: -
wildfly-elytron-ee and wildfly-elytron-mp
This would mean our Elytron release streams would become: -
* Elytron 1.x - Jakarta EE 8
* Elytron 2.x - No Jakarta modules, compatible with 1.x.
* Elytron 3.x - No Jakarta modules, some breaking changes.
The new modules would then align with Elytron 2.x and handle the move to
Jakarta EE 9 within their own version ranges.
Regards,
Darran Lofthouse.