oki, I see. +1, we did something similar with CDI-1.1 back then.
LieGrue, strub > Am 06.02.2020 um 21:31 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > 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 >>>>>> >>>>> >>>> >> >>
