Btw, the limit so far has been hit whenever some internal JDK class did return some javax class. It appears that the JDK ships many old EE parts. E.g. old common-annotations which still miss @Priority. Or even worse an ancient javax.transaction package. And then some javax.sql classes from the JDK return some transaction stuff :( Here subclassing would make perfect sense as you noted on Twitter. So we could leave the existing javax.* classes and if we need some change then we introduce a subclass in a corresponding jakarta.*. This might work in many cases. But we need to check if it als works for hierarchies. You cannot add something in a root class in jakarta as the original,classes would not extend you. Need. A bit more time to think about that.
LieGrue, Strub > Am 05.05.2019 um 21:03 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: > > I see, makes sense. > > Personally i strongly think we dont need a strong toggle and that future > compat can rely on javax, this is what javaee was about after all. > > But no issue testing things, we can even use sandbox/ for that. > >> Le dim. 5 mai 2019 à 20:49, Mark Struberg <strub...@yahoo.de> a écrit : >> Of course there will be no releases until the EF has a common understanding >> how to proceed on their side. After all the main goal is compatibility >> amongst vendors. >> >> I'd actually even would avoid to push snapshots to our repository.apache.org >> ... >> >> This is mainly for understanding how far we come, what the limits are and >> what other options we have. >> >> LieGrue, >> strub >> >> >> > Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau <rmannibu...@gmail.com>: >> > >> > Ok. >> > >> > Can we agree to take this discussion back and hold any release - no issue >> > with snaps - until it is clarified? >> > >> > Le dim. 5 mai 2019 à 18:45, Mark Struberg <strub...@yahoo.de> a écrit : >> > I'm not even sure whether they yet got all the necessary IP to release >> > anything. >> > >> > LieGrue, >> > strub >> > >> > >> > > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau >> > > <rmannibu...@gmail.com>: >> > > >> > > >> > > >> > > Le dim. 5 mai 2019 à 18:30, Mark Struberg <strub...@yahoo.de> a écrit : >> > > I'm not mandating jakarta in the groupId, but it should something else >> > > than the current one. >> > > Because otw we would have them completely mixed up in the same folder. >> > > That's not nice. >> > > >> > > Depends, that said happy to just replace specs by jakarta if it works >> > > for you better (org.apache.geronimo.jakarta). I just dont want >> > > jakarta-specs or _spec-xxx as before, always looked fishy and almost >> > > wrong even if I get where it comes from. >> > > >> > > Btw, what is our status on having eclipse releasing api under asf2 >> > > license? >> > > >> > > I dont want us to invest in something we drop like in 2 weeks and sounds >> > > it can be for most of specs. Any page tracking that? >> > > >> > > >> > > LieGrue >> > > strub >> > > >> > > > Am 05.05.2019 um 18:20 schrieb Romain Manni-Bucau >> > > > <rmannibu...@gmail.com>: >> > > > >> > > > We dont need jakarta in the gav at all. >> > > > >> > > > Why not org.apache.geronimo.spec:servlet:4.0.1? >> > > > >> > > > As a reminder specs means jakarta already and there id jo ambiguity >> > > > between jakarta and javaee thanks the version. >> > > > >> > > > That said if we move to git it id even physically clearer. >> > > > >> > > > Finally servlet is a bad example cause owned at tomcat for apache i >> > > > think. We should absolutely stop duplicating them, it pollutes user >> > > > land for no gain IMHO. >> > > > >> > > > >> > > > >> > > > >> > > > Le dim. 5 mai 2019 à 16:28, Mark Struberg <strub...@yahoo.de> a écrit : >> > > > Eclipse itself probably doesn't yet have all the IP themselves. This >> > > > first needs to be clarified. Since all those legal questions have been >> > > > dealt with behind closed doors we simply have no idea. >> > > > >> > > > But we do have clean-room implemented APIs under ALv2 over here at >> > > > Geronimo. >> > > > And we can move this ourselves without having to wait for anybody. >> > > > >> > > > LieGrue, >> > > > strub >> > > > >> > > > >> > > > > Am 05.05.2019 um 16:12 schrieb Bernd Eckenfels >> > > > > <e...@zusammenkunft.net>: >> > > > > >> > > > > I wonder if you need that going forward for Jakarta Specs, they >> > > > > could just be distributed by Eclipse directly? Having said that, if >> > > > > this is not the case I would at least remove „geronimo-“ from the >> > > > > artifact Id? >> > > > > >> > > > > >> > > > > -- >> > > > > http://bernd.eckenfels.net >> > > > > >> > > > > Von: Mark Struberg <strub...@yahoo.de> >> > > > > Gesendet: Sonntag, Mai 5, 2019 4:09 PM >> > > > > An: geronimo-dev >> > > > > Betreff: Re: [DISCUSS] implement jakarta spec apis >> > > > > >> > > > > For now I've used the following patterns: >> > > > > >> > > > > <groupId>org.apache.geronimo.jakarta-specs</groupId> >> > > > > because specs and jakarta-specs should be in a clearly separated >> > > > > folder. >> > > > > >> > > > > <artifactId>geronimo-jakarta-servlet_spec</artifactId> >> > > > > because 'jakarta' should be in the jar name >> > > > > >> > > > > <version>4.0_1-SNAPSHOT</version> >> > > > > 4.0 is for servlet-4.0, 1 is the patch level. >> > > > > >> > > > > I'd NOT do a release or push to our snapshots repo until in about 2 >> > > > > weeks when the modus operandi is clear within the Jakarta community. >> > > > > >> > > > > LieGrue, >> > > > > strub >> > > > > >> > > > > >> > > > > >> > > > > > Am 05.05.2019 um 08:55 schrieb Romain Manni-Bucau >> > > > > > <rmannibu...@gmail.com>: >> > > > > > >> > > > > > Do we also want to clean our gav? Artifact=spec, major.minor >> > > > > > version =spec version >> > > > > > >> > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 >> > > > > > >> > > > > > Le sam. 4 mai 2019 à 21:49, Romain Manni-Bucau >> > > > > > <rmannibu...@gmail.com> a écrit : >> > > > > > >> > > > > > >> > > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg <strub...@yahoo.de> a >> > > > > > écrit : >> > > > > > The problem is that in a git repo you can only release all at >> > > > > > once. That means we would need to have a single git repo for each >> > > > > > and every spec. That will be quite many... >> > > > > > >> > > > > > No, maven plugins was a monorepo for years and then they split. >> > > > > > >> > > > > > That said i proposed that exactly for that. At the end the release >> > > > > > process is more on jira dev etc, one or N repos does not compress >> > > > > > that time. Release prepare/perform is very fast on these repo so >> > > > > > one or 100 is likely the same for release manager and seems it >> > > > > > will also enable better osgi support and probably - hopefully - >> > > > > > enable servicemix to stop forking the fork ;). >> > > > > > >> > > > > > I also see svn as legacy now gitbox is mainstream and people >> > > > > > contributing like to see their name in - I expect maybe some help >> > > > > > for new spec as we got for each new version. >> > > > > > Fixed are generally trivial there and a good reason to use github. >> > > > > > >> > > > > > >> > > > > > LieGrue, >> > > > > > strub >> > > > > > >> > > > > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-Bucau >> > > > > > > <rmannibu...@gmail.com>: >> > > > > > > >> > > > > > > AFAIK we dont have limitations there and can do share stuff >> > > > > > > outside with jgit - but it is very rare - so probably sane to >> > > > > > > unify all repo to git. In particular since we will not do all >> > > > > > > specs probably. Cxf already moved to jakarta spec so we dont >> > > > > > > need jaxrs stack for instance, same for cdi, bval,... So we wil >> > > > > > > reduce a lot what we fork IMHO. >> > > > > > > >> > > > > > > Le sam. 4 mai 2019 à 21:12, Mark Struberg <strub...@yahoo.de> a >> > > > > > > écrit : >> > > > > > > I’d keep that in svn because of the tons of modules. >> > > > > > > >> > > > > > > Lg, >> > > > > > > Strub >> > > > > > > >> > > > > > > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau >> > > > > > > <rmannibu...@gmail.com>: >> > > > > > > >> > > > > > >> We mainly fork for legal reasons and defaults so name is >> > > > > > >> probably not critical while we respect module names. >> > > > > > >> >> > > > > > >> Btw do we do it in gitbox? Svn had some limitations by the past >> > > > > > >> for contributions. >> > > > > > >> >> > > > > > >> Le sam. 4 mai 2019 à 17:47, Raymond Auge >> > > > > > >> <raymond.a...@liferay.com> a écrit : >> > > > > > >> One thing to consider is there may be cases where it is >> > > > > > >> desirable to retain the javax API alongside some extra jakarta >> > > > > > >> packages & types. >> > > > > > >> >> > > > > > >> For example, for JAX-RS you may wish to add some newly defined >> > > > > > >> jakarta types (part of a new spec) which interact over the >> > > > > > >> original javax API. >> > > > > > >> >> > > > > > >> The result might be that "Jakarta EE REST" (a fictitious name >> > > > > > >> for next JAX-RS) might contain a subset of packages which, in >> > > > > > >> combination with JAXRS v2.1, also qualifies as "Jakarata EE >> > > > > > >> Rest". >> > > > > > >> >> > > > > > >> - Ray >> > > > > > >> >> > > > > > >> On Sat, May 4, 2019 at 11:26 AM Raymond Auge >> > > > > > >> <raymond.a...@liferay.com> wrote: >> > > > > > >> so is this a matter of forking all the current specs into the >> > > > > > >> new namespace? Or is the intention to completely change the >> > > > > > >> packages in-place? >> > > > > > >> >> > > > > > >> - Ray >> > > > > > >> >> > > > > > >> On Fri, May 3, 2019 at 1:58 PM Romain Manni-Bucau >> > > > > > >> <rmannibu...@gmail.com> wrote: >> > > > > > >> Hmm >> > > > > > >> >> > > > > > >> My understanding was it was getting under eclipse license as >> > > > > > >> well and was fully donated but can have missed some details. >> > > > > > >> >> > > > > > >> If we cant reuse them let's just create new ones and fix module >> > > > > > >> name for others. >> > > > > > >> >> > > > > > >> specs/ is fine since it is the same for us IMHO >> > > > > > >> >> > > > > > >> Le ven. 3 mai 2019 à 18:24, Mark Struberg <strub...@yahoo.de> a >> > > > > > >> écrit : >> > > > > > >> No, it is not the same. microprofile specs are licensed under >> > > > > > >> ALv2 and we know all the legal details. >> > > > > > >> For the EE specs this is by far not the same. We don't even >> > > > > > >> know exactly what parts did yet get donated by Oracle to the >> > > > > > >> EF. >> > > > > > >> >> > > > > > >> LieGrue, >> > > > > > >> strub >> > > > > > >> >> > > > > > >> >> > > > > > >> > Am 03.05.2019 um 18:12 schrieb Romain Manni-Bucau >> > > > > > >> > <rmannibu...@gmail.com>: >> > > > > > >> > >> > > > > > >> > Hi >> > > > > > >> > >> > > > > > >> > Idnt it the exact same as for microprofile? So we dont do? >> > > > > > >> > >> > > > > > >> > Le ven. 3 mai 2019 à 16:21, Mark Struberg <strub...@yahoo.de> >> > > > > > >> > a écrit : >> > > > > > >> > I've started tinkering something under >> > > > > > >> > specs/branches/jakarta. >> > > > > > >> > It's wip but have to rush out for a few hours now. >> > > > > > >> > Will continue later today. >> > > > > > >> > >> > > > > > >> > LieGrue, >> > > > > > >> > strub >> > > > > > >> > >> > > > > > >> > >> > > > > > >> > > Am 03.05.2019 um 15:50 schrieb Mark Struberg >> > > > > > >> > > <strub...@yahoo.de>: >> > > > > > >> > > >> > > > > > >> > > hi folks! >> > > > > > >> > > >> > > > > > >> > > You might have read todays post from Mike Milinkovich. >> > > > > > >> > > >> > > > > > >> > > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/ >> > > > > > >> > > >> > > > > > >> > > >> > > > > > >> > > It basically says that Jakarta will not be able to change a >> > > > > > >> > > single bit in the current spec apis under the javax.* >> > > > > > >> > > package. >> > > > > > >> > > Any change has to be done in a different package. >> > > > > > >> > > The Jakarta people over at Eclipse already did some voting >> > > > > > >> > > and the new package name will be jakarta.* >> > > > > > >> > > >> > > > > > >> > > Thus I would like to recommend to use our IP clean >> > > > > > >> > > geronimo-specs to setup a new project for the EE8 specs >> > > > > > >> > > under the jakarta.* package name. >> > > > > > >> > > >> > > > > > >> > > I'll go forward and create a branch starting with the most >> > > > > > >> > > important specs. >> > > > > > >> > > >> > > > > > >> > > Any feedback and help is welcome! >> > > > > > >> > > >> > > > > > >> > > LieGrue, >> > > > > > >> > > strub >> > > > > > >> > > >> > > > > > >> > >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> -- >> > > > > > >> Raymond Augé (@rotty3000) >> > > > > > >> Senior Software Architect Liferay, Inc. (@Liferay) >> > > > > > >> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) >> > > > > > >> >> > > > > > >> >> > > > > > >> -- >> > > > > > >> Raymond Augé (@rotty3000) >> > > > > > >> Senior Software Architect Liferay, Inc. (@Liferay) >> > > > > > >> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) >> > > > > > >> > > > > >> > > > >> > > >> > >>
