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) >
