From dev-return-100121-archive-asf-public=cust-asf.ponee.io@geronimo.apache.org Sun May 5 19:04:13 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 F3B8918066B for ; Sun, 5 May 2019 21:04:12 +0200 (CEST) Received: (qmail 29516 invoked by uid 500); 5 May 2019 19:04:12 -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 29499 invoked by uid 99); 5 May 2019 19:04:12 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 May 2019 19:04:12 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 903651810DC for ; Sun, 5 May 2019 19:04:11 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-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: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id 19DuiXGAesFL for ; Sun, 5 May 2019 19:04:08 +0000 (UTC) Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id CCD995F16F for ; Sun, 5 May 2019 19:04:07 +0000 (UTC) Received: by mail-qt1-f193.google.com with SMTP id f24so1993751qtk.11 for ; Sun, 05 May 2019 12:04:07 -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=GfqcSKlJbmlcgi5LUUVKuekiuT4PkFIf55lbU4xpyCg=; b=jOd8IvvWUh3aO31uiW7Ub2Pa0SVfMi7uYkXziq8/wt3EZYbU/+LFu+FTcU/w8XmbGP UcuDXRI3KlxWX8/rjiXZ8N4pdyZHCUxBck1Bhi8nCjr5y/TrQlWDCkw176/JzOZ3T9b8 SYUx1+00A7H+7FGDkuWPMrclfIJCAUqyZxYVliUzfzRc+71PQ23raFPXWKhDTi+IeVbe tp7nSS+3ROYk+ULUiq/x94Jpkt20RusdJ/zhZ9+Rl0Ek5AyDnG6p9wiXZrN6t5yNOeNT 3zrV2QXdBGv9BnPjEwsjGZOfT1mh+KvWSIKv9r6kLF6Zxf9+3RlZFJMuAW0qVNWegHec fHBQ== 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=GfqcSKlJbmlcgi5LUUVKuekiuT4PkFIf55lbU4xpyCg=; b=LeSzQTRGL1HF0qC5HsIObKyjpMjV1wIjqU9u2QTKVds4kscoKY2cEMXebnpXFtWfSk xkaFP9KEvlEdNL0gttvuHwSVIbc27+gYcWNJ3DJZFkfREFi4aMqXnVBKPNtNDJ6DiH6u ITrTUW7SSPjMoG6YecQAsoiOdL4JKUCkXIg3kWLesY8FJH8vuaVo6dQrgTS6l7pL4PU1 ynThksvOxYZnpJ3nxRMDeKkX3QwXSN0lPN6jkUPD0pMZxZ/oaDZvgK7YUzQIV4M8+KXi /WyVqkc6sEFjzWKZEZ0Hj2Qd77VY0Ps9tU+h4hkVs4wJmxW/K3pQck+sJKhTYyQVOhhK FU9A== X-Gm-Message-State: APjAAAVJW1Gq1mO/Vt7I5jCAKTKEG9LIGD0ln/Dl61N7JovAImuXNKhb 0nsB8ur69Sm4EBUYXoHVIfGbWxSOWB/mNpC8A/dZkYMS X-Google-Smtp-Source: APXvYqyZmz/CLGsqggwRKdskaca5RHCElnECe7QHgjN4STW/oaUgBQ3HxwPiRXNbDpXAbahc/ImcB8vwITlPxcBRW84= X-Received: by 2002:a0c:d2e7:: with SMTP id x36mr11605804qvh.92.1557083047025; Sun, 05 May 2019 12:04:07 -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> <9EEF5150-758D-4F61-B586-78229BFC4BB3@yahoo.de> <0856D083-7F08-4B30-88A5-5BBEDE3C263D@yahoo.de> In-Reply-To: <0856D083-7F08-4B30-88A5-5BBEDE3C263D@yahoo.de> From: Romain Manni-Bucau Date: Sun, 5 May 2019 21:03:54 +0200 Message-ID: Subject: Re: [DISCUSS] implement jakarta spec apis To: dev@geronimo.apache.org Content-Type: multipart/alternative; boundary="000000000000e760e6058828a5c0" --000000000000e760e6058828a5c0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =C3=A0 20:49, Mark Struberg a =C3=A9= 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 >: > > > > 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 =C3=A0 18:45, Mark Struberg a = =C3=A9crit : > > 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 =C3=A0 18:30, Mark Struberg a = =C3=A9crit > : > > > I'm not mandating jakarta in the groupId, but it should something els= e > 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 wron= g > 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 =C3=A0 16:28, Mark Struberg = a > =C3=A9crit : > > > > Eclipse itself probably doesn't yet have all the IP themselves. Thi= s > 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 =E2=80=9Egeronimo-=E2=80=9C from the= artifact 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 > version =3Dspec version > > > > > > > > > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1 > > > > > > > > > > > > Le sam. 4 mai 2019 =C3=A0 21:49, Romain Manni-Bucau < > rmannibucau@gmail.com> 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 eve= ry > 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 1= 00 > is likely the same for release manager and seems it will also enable bett= er > 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 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 & > 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 origin= al > javax API. > > > > > > >> > > > > > > >> The result might be that "Jakarta EE REST" (a fictitious nam= e > 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 th= e > 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 unde= r > 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 < > struberg@yahoo.de> 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 < > 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 chang= e > 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) > > > > > > > > > > > > > > > > > > > > > > --000000000000e760e6058828a5c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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.<= /div>

But no issue testing thi= ngs, we can even use sandbox/ for that.

Le dim. 5 mai 2019 =C3=A0 20:49, Mark Struberg <= s= truberg@yahoo.de> a =C3=A9crit=C2=A0:
Of course there will be no releases until the EF has a common und= erstanding how to proceed on their side. After all the main goal is compati= bility 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 w= hat other options we have.

LieGrue,
strub


> Am 05.05.2019 um 19:35 schrieb Romain Manni-Bucau <rm= annibucau@gmail.com>:
>
> Ok.
>
> Can we agree to take this discussion back and hold any release - no is= sue with snaps - until it is clarified?
>
> Le dim. 5 mai 2019 =C3=A0 18:45, Mark Struberg <struberg@= yahoo.de> a =C3=A9crit :
> I'm not even sure whether they yet got all the necessary IP to rel= ease anything.
>
> LieGrue,
> strub
>
>
> > Am 05.05.2019 um 18:39 schrieb Romain Manni-Bucau <rmannibucau@gmail.com>:
> >
> >
> >
> > Le dim. 5 mai 2019 =C3=A0 18:30, Mark Struberg <stru= berg@yahoo.de> a =C3=A9crit :
> > I'm not mandating jakarta in the groupId, but it should somet= hing else than the current one.
> > Because otw we would have them completely mixed up in the same fo= lder. That's not nice.
> >
> > Depends, that said happy to just replace specs by jakarta if it w= orks 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 asf= 2 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 am= biguity 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 a= pache 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 <struberg@yahoo.de> a =C3=A9crit :
> > > Eclipse itself probably doesn't yet have all the IP them= selves. This first needs to be clarified. Since all those legal questions h= ave been dealt with behind closed doors we simply have no idea.
> > >
> > > But we do have clean-room implemented APIs under ALv2 over h= ere at Geronimo.
> > > And we can move this ourselves without having to wait for an= ybody.
> > >
> > > 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 Spe= cs, they could just be distributed by Eclipse directly? Having said that, i= f this is not the case I would at least remove =E2=80=9Egeronimo-=E2=80=9C = from the artifact Id?
> > > >
> > > >
> > > > --
> > > > http://bernd.eckenfels.net > > > >=C2=A0
> > > > Von: Mark Struberg <struberg@yahoo.de&= gt;
> > > > 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</gr= oupId>
> > > > because specs and jakarta-specs should be in a clearly = separated folder.
> > > >
> > > > <artifactId>geronimo-jakarta-servlet_spec</art= ifactId>
> > > > 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=3Dspec,= major.minor version =3Dspec version
> > > > >
> > > > > Ex: org.apache.geronimo.specs:jsp:2.1.1
> > > > >
> > > > > Le sam. 4 mai 2019 =C3=A0 21:49, Romain Manni-Buca= u <rmannibucau@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 rel= ease all at once. That means we would need to have a single git repo for ea= ch and every spec. That will be quite many...
> > > > >
> > > > > No, maven plugins was a monorepo for years and the= n 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 c= ompress that time. Release prepare/perform is very fast on these repo so on= e or 100 is likely the same for release manager and seems it will also enab= le 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 hel= p for new spec as we got for each new version.
> > > > > Fixed are generally trivial there and a good reaso= n to use github.
> > > > >
> > > > >
> > > > > LieGrue,
> > > > > strub
> > > > >
> > > > > > Am 04.05.2019 um 21:35 schrieb Romain Manni-B= ucau <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 t= o unify all repo to git. In particular since we will not do all specs proba= bly. Cxf already moved to jakarta spec so we dont need jaxrs stack for inst= ance, same for cdi, bval,... So we wil reduce a lot what we fork IMHO.
> > > > > >
> > > > > > Le sam. 4 mai 2019 =C3=A0 21:12, Mark Struber= g <struberg@yahoo.de> a =C3=A9crit :
> > > > > > I=E2=80=99d keep that in svn because of the t= ons of modules.
> > > > > >
> > > > > > Lg,
> > > > > > Strub
> > > > > >
> > > > > > Am 04.05.2019 um 19:28 schrieb Romain Manni-B= ucau <rmannibucau@gmail.com>:
> > > > > >
> > > > > >> We mainly fork for legal reasons and defa= ults so name is probably not critical while we respect module names.
> > > > > >>
> > > > > >> Btw do we do it in gitbox? Svn had some l= imitations by the past for contributions.
> > > > > >>
> > > > > >> Le sam. 4 mai 2019 =C3=A0 17:47, Raymond = Auge <raymond.auge@liferay.com> a =C3=A9crit : <= br> > > > > > >> One thing to consider is there may be cas= es where it is desirable to retain the javax API alongside some extra jakar= ta packages & types.
> > > > > >>
> > > > > >> For example, for JAX-RS you may wish to a= dd some newly defined jakarta types (part of a new spec) which interact ove= r the original javax API.
> > > > > >>
> > > > > >> The result might be that "Jakarta EE= REST" (a fictitious name for next JAX-RS) might contain a subset of p= ackages which, in combination with JAXRS v2.1, also qualifies as "Jaka= rata EE Rest".
> > > > > >>
> > > > > >> - Ray
> > > > > >>
> > > > > >> On Sat, May 4, 2019 at 11:26 AM Raymond A= uge <raymond.auge@liferay.com> wrote:
> > > > > >> so is this a matter of forking all the cu= rrent specs into the new namespace? Or is the intention to completely chang= e the packages in-place?
> > > > > >>
> > > > > >> - Ray
> > > > > >>
> > > > > >> On Fri, May 3, 2019 at 1:58 PM Romain Man= ni-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 det= ails.
> > > > > >>
> > > > > >> If we cant reuse them let's just crea= te new ones and fix module name for others.
> > > > > >>
> > > > > >> specs/ is fine since it is the same for u= s IMHO
> > > > > >>
> > > > > >> Le ven. 3 mai 2019 =C3=A0 18:24, Mark Str= uberg <struberg@yahoo.de> a =C3=A9crit :
> > > > > >> No, it is not the same. microprofile spec= s are licensed under ALv2 and we know all the legal details.
> > > > > >> For the EE specs this is by far not the s= ame. We don't even know exactly what parts did yet get donated by Oracl= e to the EF.
> > > > > >>
> > > > > >> LieGrue,
> > > > > >> strub
> > > > > >>
> > > > > >>
> > > > > >> > Am 03.05.2019 um 18:12 schrieb Romai= n Manni-Bucau <rmannibucau@gmail.com>:
> > > > > >> >
> > > > > >> > Hi
> > > > > >> >
> > > > > >> > Idnt it the exact same as for microp= rofile? So we dont do?
> > > > > >> >
> > > > > >> > Le ven. 3 mai 2019 =C3=A0 16:21, Mar= k Struberg <struberg@yahoo.de> a =C3=A9crit :
> > > > > >> > I've started tinkering something= under specs/branches/jakarta.
> > > > > >> > It's wip but have to rush out fo= r 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 Ecli= pse 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 welcom= e!
> > > > > >> > >
> > > > > >> > > LieGrue,
> > > > > >> > > strub
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Raymond Aug=C3=A9 (@rotty3000)
> > > > > >> Senior Software Architect Liferay, Inc. (= @Liferay)
> > > > > >> Board Member & EEG Co-Chair, OSGi All= iance (@OSGiAlliance)
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Raymond Aug=C3=A9 (@rotty3000)
> > > > > >> Senior Software Architect Liferay, Inc. (= @Liferay)
> > > > > >> Board Member & EEG Co-Chair, OSGi All= iance (@OSGiAlliance)
> > > > >
> > > >
> > >
> >
>

--000000000000e760e6058828a5c0--