Guess both are compatible. See it as kind of OWB 3-Milestones before the time.
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le jeu. 6 févr. 2020 à 15:40, Thomas Andraschko <andraschko.tho...@gmail.com> a écrit : > i general i like your idea and it makes it easy for us. > > On the other side i also like the idea of a bigbang and fully migrate to > jakarta.* and do a OWB 3.0. > Im not sure whats the current decision but they posted on the JakartaEE > mailing list, that every spec has to increase the version the number. > So CDI 2.0 will become CDI 3.0 with jakarta namespace. > > Am Do., 6. Feb. 2020 um 15:13 Uhr schrieb Romain Manni-Bucau < > rmannibu...@gmail.com>: > > > Hi all, > > > > Create a branch on my owb fork to get a first draft to play with jakarta > > package ([1]) > > > > It basically uses the maven shade relocation feature to move all the > > javax.* we use to jakarta package and attach a new jar with classifier > > "jakarta" to the build. > > > > Concretely it means a little work with maven to make it work without > > bringing undesired artifacts ([2]) but it also enables to already code > > against jakarta and avoid future migrations for new projects which is > worth > > it IMHO. > > > > I guess at some point we can need to actually branch our javax code and > > move master to jakarta but for still some years we can't to break the > less > > possible our users. > > > > This is why I think the relocation - even if we must write some custom > > transformers for exceptions - is not a bad compromise: we keep a single > > codebase to maintain. > > > > Small issue I encountered with this solution is the fact maven shade does > > not use relocations in the manifest so OSGi metadata are broken but I > sent > > a PR ([3]) to fix it. I expect a few discussion on this one but nothing > > blocking here - very worse case we write our own transformer once again > ;). > > > > Any feedback appreciated. Also happy to merge my branch on our master > since > > it does not impact main delivered code (only a few properties which is > not > > hurting). > > > > [1] > > > > > https://github.com/rmannibucau/openwebbeans/commit/4b2f0f0c93462588edf8e90adfa2f311eb0aebab > > [2] > > > > > https://github.com/rmannibucau/openwebbeans/commit/4b2f0f0c93462588edf8e90adfa2f311eb0aebab#diff-10436e2c45e8993cd8ea80b61461531eR49 > > [3] https://github.com/apache/maven-shade-plugin/pull/38 > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > >