Hi Mark Thread is nit about spec jars. No real challenge there and I think you are almost fully right, we should just create the new spec jar with the new version (the almost being we should make them j9 friendly and stop using a bad naming convention+move to git but that's details).
This thread is about owb. We will need to maintain javax version for likely few years (Id say 5) and probably dont want to handle multiple branches so question is: what is the most costly between 2 branches and almost systematic backports or a one time mapper (with exceptions or not) setup. Once this maintenance period passed (when ee10 arrives?) we would just move to jakarta IMHO. Hope it makes sense. Le jeu. 6 févr. 2020 à 21:22, Mark Struberg <strub...@yahoo.de.invalid> a écrit : > I'm for doing a separate geronimo-jakarta-specs build. > Reason is that Bill, etc did talk about removing a few methods from those > migrated APIs. > There are also discussions about doing 'small changes' like adding > generics to some APIs. > > Ofc imo that's no small change, but well... > > We are safer off by using a separate build. > > Back almost a year ago I did already migrate most of the necessary specs: > > http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/ < > http://svn.apache.org/repos/asf/geronimo/specs/branches/jakarta/> > > Of course it is actually not a branch anymore but should get moved to say > > http://svn.apache.org/repos/asf/geronimo/specs/jakarta-specs/ < > http://svn.apache.org/repos/asf/geronimo/specs/jakarta-specs/>trunk > > LieGrue, > strub > > > Am 06.02.2020 um 15:42 schrieb Romain Manni-Bucau <rmannibu...@gmail.com > >: > > > > 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 > >>>> > >>> > >> > >
