geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: [DISCUSS] implement jakarta spec apis
Date Sun, 05 May 2019 17:35:51 GMT
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 <struberg@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 <rmannibucau@gmail.com
> >:
> >
> >
> >
> > Le dim. 5 mai 2019 à 18:30, Mark Struberg <struberg@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 <
> rmannibucau@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 <struberg@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 <
> ecki@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 <struberg@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 <
> rmannibucau@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 <
> rmannibucau@gmail.com> a écrit :
> > > > >
> > > > >
> > > > > Le sam. 4 mai 2019 à 21:44, Mark Struberg <struberg@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 <
> rmannibucau@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 <struberg@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 <
> rmannibucau@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.auge@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.auge@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 <
> rmannibucau@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 <struberg@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 <
> rmannibucau@gmail.com>:
> > > > > >> >
> > > > > >> > Hi
> > > > > >> >
> > > > > >> > Idnt it the exact same as for microprofile? So we dont
do?
> > > > > >> >
> > > > > >> > Le ven. 3 mai 2019 à 16:21, Mark Struberg <struberg@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 <
> struberg@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)
> > > > >
> > > >
> > >
> >
>
>

Mime
View raw message