From dev-return-100115-archive-asf-public=cust-asf.ponee.io@geronimo.apache.org Sun May 5 16:23:04 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 3D62A18066B for ; Sun, 5 May 2019 18:23:04 +0200 (CEST) Received: (qmail 85922 invoked by uid 500); 5 May 2019 16:23:03 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 85908 invoked by uid 99); 5 May 2019 16:23:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 May 2019 16:23:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 8156DC2C4F for ; Sun, 5 May 2019 16:23:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.78 X-Spam-Level: * X-Spam-Status: No, score=1.78 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id acEn_V04Me39 for ; Sun, 5 May 2019 16:22:59 +0000 (UTC) Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 8A0AE5FDFB for ; Sun, 5 May 2019 16:22:58 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id m32so9062403qtf.0 for ; Sun, 05 May 2019 09:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=JAgpi+4rWIczepslhqG58WQmI9874NmiqNQGylYKa+U=; b=fZX3MUhD12wv8VFKOm8rg29fIm2brVWI9s3UTUfvBOvmcSWhBFuSH7fIm2dwMiRkCx gPjBjSds1O347nzj6PimDZhhzfYjv62RqQTxVOP7InBXpMvnTLqxcbVvwBAI+R97tr2Y m8jPVElYuqZIRQ9wQ+YXH/ISdPwz7RoxrPn1YD3LMmQ+mLVfDBs0EAe226pHg27TyAJh nBj69SOoSH7JwzqctzmZaWqKvXrXpvxi6zW8nq176hTm7NreRUpRAesTqaawynhqIZts 9FMBiW/P2ugpFo3T953cXQx8wWDuB1Lakyg6CxGl7Lz6kcPu4S1xRA4buT+VbnM0w52B stSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=JAgpi+4rWIczepslhqG58WQmI9874NmiqNQGylYKa+U=; b=AHKxeb9my2SZ+S7sEWa2LmWElutkLX9hSFeKvNwYvm/ffEN+uP7tcjEi3jJZMlKwb0 6bngBPKRqfUBe+YWD3ARVAZZhNkHO1zqnkttBMsCIRuzXjRtpPipxQs/9N8YANx8/rjQ yE3ISWtsysw1f0L23aBU2I3pdvShRZ2ivPLutCTLHil3ckmp1HAB0HfEZUcwh3S+YruQ pFKwcKj10XZ7WsruR3o7u9vfeM7vlEJmcfeBOBWHejHzKl4LIiruzrjTSwc5LoIbTyOx s05bRSL60TRHIgWoeDikzJotQQcbvvRlifcCo/xZumBIWRn5is20EjVEN8CYlrWQhl8p ouBg== X-Gm-Message-State: APjAAAU7PWGdUapy5emEtEJJMtbW9f5vEGO3l46jQb8TKTyTEE21B398 7+M/K2l7rDpQkShMGGbgc+Gf5wuDLaGCVlwlbVxn3lI8 X-Google-Smtp-Source: APXvYqyfVubueL7q71ewtwmOlSuiYNCLd6/PbwMXQkWua3edio+2MKihLVrlLwKK+LlmYh61GMk5xGK/p6dgMfu4pQU= X-Received: by 2002:ac8:22f3:: with SMTP id g48mr17904188qta.333.1557073376978; Sun, 05 May 2019 09:22:56 -0700 (PDT) MIME-Version: 1.0 References: <89C25331-028B-4C1E-84C7-60741C515953@yahoo.de> <9EAABA10-ECB6-4053-B7FD-8C901D9E3553@yahoo.de> <68371188-8355-4E6C-A63D-F791044ACDA5@yahoo.de> <9904D65B-AA35-4037-95C3-3CDF83F18F98@yahoo.de> <9E67C623-78BE-4FE8-9FD7-D0BE2CF7C608@yahoo.de> In-Reply-To: <9E67C623-78BE-4FE8-9FD7-D0BE2CF7C608@yahoo.de> From: Romain Manni-Bucau Date: Sun, 5 May 2019 18:20:32 +0200 Message-ID: Subject: Re: [DISCUSS] implement jakarta spec apis To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary="000000000000862e1c05882665ba" --000000000000862e1c05882665ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =C3=A0 16:28, Mark Struberg a =C3=A9= crit : > Eclipse itself probably doesn't yet have all the IP themselves. This firs= t > needs to be clarified. Since all those legal questions have been dealt wi= th > 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 = : > > > > 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 =E2=80=9Egeronimo-=E2=80=9C from the art= ifact Id? > > > > > > -- > > http://bernd.eckenfels.net > > > > Von: Mark Struberg > > 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: > > > > org.apache.geronimo.jakarta-specs > > because specs and jakarta-specs should be in a clearly separated folder= . > > > > geronimo-jakarta-servlet_spec > > because 'jakarta' should be in the jar name > > > > 4.0_1-SNAPSHOT > > 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=3Dspec, major.minor versio= n > =3Dspec version > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > Le sam. 4 mai 2019 =C3=A0 21:49, Romain Manni-Bucau > a =C3=A9crit : > > > > > > > > > Le sam. 4 mai 2019 =C3=A0 21:44, Mark Struberg a = =C3=A9crit > : > > > 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 spe= c. > 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 =C3=A0 21:12, Mark Struberg = a > =C3=A9crit : > > > > I=E2=80=99d 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 fo= r > contributions. > > > >> > > > >> Le sam. 4 mai 2019 =C3=A0 17:47, Raymond Auge > a =C3=A9crit : > > > >> 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 wit= h > 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 =C3=A0 18:24, Mark Struberg = a > =C3=A9crit : > > > >> 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 =C3=A0 16:21, Mark Struberg a > =C3=A9crit : > > > >> > 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 : > > > > >> > > > > > >> > > 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=C3=A9 (@rotty3000) > > > >> Senior Software Architect Liferay, Inc. (@Liferay) > > > >> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) > > > >> > > > >> > > > >> -- > > > >> Raymond Aug=C3=A9 (@rotty3000) > > > >> Senior Software Architect Liferay, Inc. (@Liferay) > > > >> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAlliance) > > > > > > > --000000000000862e1c05882665ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We dont need jakarta in the gav at all.

Why not org.apache.geronimo.spec:servlet:4= .0.1?

As a reminder spec= s means jakarta already and there id jo ambiguity between jakarta and javae= e thanks the version.=C2=A0

That said if we move to git it id even physically clearer.

Finally servlet is a bad example cau= se owned at tomcat for apache i think. We should absolutely stop duplicatin= g them, it pollutes user land for no gain IMHO.

=



Le dim. 5 mai 2019 =C3=A0 16:28, Mark Struberg <struberg@yahoo.de> a =C3=A9crit=C2=A0:
Eclipse itself probably doesn't yet = have all the IP themselves. This first needs to be clarified. Since all tho= se 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@zusammenku= nft.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 t= he case I would at least remove =E2=80=9Egeronimo-=E2=80=9C from the artifa= ct Id?
>
>
> --
> http://bernd.eckenfels.net
>=C2=A0
> Von: Mark Struberg <struberg@yahoo.de>
> Gesendet: Sonntag, Mai 5, 2019 4:09 PM
> An: geronimo-dev
> Betreff: Re: [DISCUSS] implement jakarta spec apis
>=C2=A0
> 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 folde= r.
>
> <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= cau@gmail.com>:
> >
> > Do we also want to clean our gav? Artifact=3Dspec, major.minor ve= rsion =3Dspec version
> >
> > Ex: org.apache.geronimo.specs:jsp:2.1.1
> >
> > Le sam. 4 mai 2019 =C3=A0 21:49, Romain Manni-Bucau <rman= nibucau@gmail.com> a =C3=A9crit :
> >
> >
> > Le sam. 4 mai 2019 =C3=A0 21:44, Mark Struberg <struberg@yahoo.= de> a =C3=A9crit :
> > The problem is that in a git repo you can only release all at onc= e. That means we would need to have a single git repo for each and every sp= ec. That will be quite many...
> >
> > No, maven plugins was a monorepo for years and then they split. <= br> > >
> > That said i proposed that exactly for that. At the end the releas= e process is more on jira dev etc, one or N repos does not compress that ti= me. Release prepare/perform is very fast on these repo so one or 100 is lik= ely the same for release manager and seems it will also enable better osgi = support and probably - hopefully - enable servicemix to stop forking the fo= rk ;).
> >
> > I also see svn as legacy now gitbox is mainstream and people cont= ributing 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 <rma= nnibucau@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 rep= o to git. In particular since we will not do all specs probably. Cxf alread= y 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 =C3=A0 21:12, Mark Struberg <struberg= @yahoo.de> a =C3=A9crit :
> > > I=E2=80=99d keep that in svn because of the tons of modules.=
> > >
> > > Lg,
> > > Strub
> > >
> > > Am 04.05.2019 um 19:28 schrieb Romain Manni-Bucau <rma= nnibucau@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 t= he past for contributions.
> > >>
> > >> Le sam. 4 mai 2019 =C3=A0 17:47, Raymond Auge <= raymond.auge@liferay.com> a =C3=A9crit :
> > >> One thing to consider is there may be cases where it is = desirable to retain the javax API alongside some extra jakarta packages &am= p; types.
> > >>
> > >> For example, for JAX-RS you may wish to add some newly d= efined 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&qu= ot;.
> > >>
> > >> - Ray
> > >>
> > >> On Sat, May 4, 2019 at 11:26 AM Raymond Auge <r= aymond.auge@liferay.com> wrote:
> > >> so is this a matter of forking all the current specs int= o 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 licens= e 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 =C3=A0 18:24, Mark Struberg <strube= rg@yahoo.de> a =C3=A9crit :
> > >> 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 &= lt;rmannibucau@gmail.com>:
> > >> >
> > >> > Hi
> > >> >
> > >> > Idnt it the exact same as for microprofile? So we d= ont do?
> > >> >
> > >> > Le ven. 3 mai 2019 =C3=A0 16:21, Mark Struberg <= s= truberg@yahoo.de> a =C3=A9crit :
> > >> > I've started tinkering something under specs/br= anches/jakarta.
> > >> > It's wip but have to rush out for a few hours n= ow.
> > >> > Will continue later today.
> > >> >
> > >> > LieGrue,
> > >> > strub
> > >> >
> > >> >
> > >> > > Am 03.05.2019 um 15:50 schrieb Mark Struberg &= lt;struberg@yahoo.de>:
> > >> > >
> > >> > > hi folks!
> > >> > >
> > >> > > You might have read todays post from Mike Mili= nkovich.
> > >> > >
> > >> > > https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trad= emarks/
> > >> > >
> > >> > > It basically says that Jakarta will not be abl= e to change a single bit in the current spec apis under the javax.* package= .
> > >> > > Any change has to be done in a different packa= ge.
> > >> > > 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 c= lean geronimo-specs to setup a new project for the EE8 specs under the jaka= rta.* package name.
> > >> > >
> > >> > > I'll go forward and create a branch starti= ng with the most important specs.
> > >> > >
> > >> > > Any feedback and help is welcome!
> > >> > >
> > >> > > LieGrue,
> > >> > > strub
> > >> > >
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Raymond Aug=C3=A9 (@rotty3000)
> > >> Senior Software Architect Liferay, Inc. (@Liferay)
> > >> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAll= iance)
> > >>
> > >>
> > >> --
> > >> Raymond Aug=C3=A9 (@rotty3000)
> > >> Senior Software Architect Liferay, Inc. (@Liferay)
> > >> Board Member & EEG Co-Chair, OSGi Alliance (@OSGiAll= iance)
> >
>

--000000000000862e1c05882665ba--