Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
MIME-Version: 1.0
References: <CAFjTMnwYScQ+ru6qwQmZfOG+sRQaRNMYWtPwSZi7UCKotsU0tg@mail.gmail.com>
 <CA+ULb+v=b9mhfes-a3dmQrHJNVRjN1180pt6vr_EJEw7xOUDOA@mail.gmail.com>
 <CAOqetn9aQ0ip5gOPiMofE6FH4aWn1SzUi2xHGBx78CVM_OHe+w@mail.gmail.com>
 <485317b9-65f0-dbc4-0d84-98fe947462c3@shanecurcuru.org> <D5A8801F.9A7F2%aharui@adobe.com>
 <694CEE1B-301E-460D-A126-73F1E903F1CF@apache.org> <2e833f67-8f08-634e-6caa-5cdfb4886709@apache.org>
 <D5A89AF8.9A8BA%aharui@adobe.com>
In-Reply-To: <D5A89AF8.9A8BA%aharui@adobe.com>
From: "John D. Ament" <johndament@apache.org>
Date: Thu, 03 Aug 2017 16:34:24 +0000
Message-ID: <CAOqetn-gYrD34h9Qop6SEsaAKYeSvZj4pes6m3q7oZfyH6zF-Q@mail.gmail.com>
Subject: Re: Urgent: Regarding Java package name change to org.apache.*
To: general@incubator.apache.org
Content-Type: multipart/alternative; boundary="94eb2c0e9c76b91bb20555dbf48c"
archived-at: Thu, 03 Aug 2017 16:34:40 -0000

--94eb2c0e9c76b91bb20555dbf48c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

One caveat - if your packages are "com.theoldcompany.someproject" they
should be renamed to "org.apache.someproject" before graduation.  If you
have "org.someproject" already or just "someproject" as your package names,
that's not a naming issue so I don't see that ever blocking graduation.

John

On Thu, Aug 3, 2017 at 12:25 PM Alex Harui <aharui@adobe.com.invalid> wrote=
:

> OK, so to summarize a more refined recommendation:
>
> 1) package names with reverse domains MUST be renamed before graduation o=
r
> have an IPMC approved plan for renaming
> 2) Projects who expect that their future users outnumber current users ar=
e
> highly encouraged to rename packages
> 3) Other projects are not required to rename packages and backward
> compatibility is sufficient reason to not rename packages.
>
> Or should #2 also be a MUST?
>
> -Alex
>
> On 8/3/17, 8:34 AM, "Andy Seaborne" <andy@apache.org> wrote:
>
> >
> >
> >On 03/08/17 15:51, Julian Hyde wrote:
> >> It rarely comes down to the IPMC or the Board dictating how a project
> >>names its java classes (does anyone recall an instance?), so it=E2=80=
=99s mainly
> >>the project=E2=80=99s discretion. In my opinion, where the project is o=
n its
> >>adoption curve is an important consideration.
> >
> >+1
> >
> >> Most projects that enter the incubator are early on the adoption curve=
.
> >>Their future users outnumber their current users. The earlier these
> >>projects make the change to org.apache, the fewer people they will
> >>ultimately impact. It seems that gobblin is in this category.
> >>
> >> A few projects, such as Flex, are already near the top of their
> >>adoption curve. The cost/benefit of renaming is not as compelling.
> >
> >Jena was not early on the adoption curve. Long term compatibility has
> >been, and is, a major element of the project culture.  Importantly,
> >there are active users who answer questions (here, elsewhere), external
> >web tutorials, books etc referring to the pre-ASF API.  We have a
> >responsibility to them as well.
> >
> >"add an API" is more stuff that a small set of volunteer contributors
> >(Jena has had no paid contributors working on) could not have coped
> >with.  If a project has the capacity, sure. Not all project will.
> >
> >Set the expectations too high and it is implicitly a filter for a
> >certain kind of project in size and structure.
> >
> >     Andy
> >
> >
> >>
> >> Julian
> >>
> >>
> >>> On Aug 3, 2017, at 7:37 AM, Alex Harui <aharui@adobe.com.INVALID>
> >>>wrote:
> >>>
> >>>  From the peanut gallery:
> >>>
> >>> Does the PPMC get to decide what constitutes a "very good reason" or
> >>>does
> >>> the IPMC and after graduation, the board?
> >>>
> >>> Flex has not changed its packages in the 5 years at Apache.  We felt
> >>> backward compatibility was and is a "very good reason".  It was way
> >>>more
> >>> important to not require folks to alter their code in order to move t=
o
> >>>the
> >>> Apache versions of Flex.  Also, we are not using Java/Maven so there
> >>>isn't
> >>> really a shading option.
> >>>
> >>> On the other hand, it seems like it could be confusing for Apache
> >>>projects
> >>> to have packages starting with "com.".  Flex's packages start with
> >>>"mx" or
> >>> "spark" (the component set names).
> >>>
> >>> Seems like a more refined guidance would be that:
> >>> 1) packages starting with "com" (and maybe
> >>>org.somethingOtherThanApache)
> >>> should be changed as soon as possible/practical
> >>> 2) there is no recommendation for other package prefixes
> >>>
> >>> My 2 cents,
> >>> -Alex
> >>>
> >>> On 8/3/17, 5:42 AM, "Shane Curcuru" <asf@shanecurcuru.org
> >>><mailto:asf@shanecurcuru.org>> wrote:
> >>>
> >>>> John D. Ament wrote on 8/2/17 9:13 PM:
> >>>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik
> >>>>><roman@shaposhnik.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <abti@apache.org>
> >>>>>> wrote:
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> In regards to the recently incubated project - Gobblin, we were
> >>>>>>> wondering
> >>>>>>> about the policy around renaming Java package names to
> >>>>>>>org.apache.* Is
> >>>>>> it a
> >>>>>>> mandatory requirement or good to have?
> >>>>>>>
> >>>>>>> The reason to ask this is that while we see many projects have
> >>>>>>> migrated
> >>>>>> to
> >>>>>>> use org.apache.* package name for their Java source files, the
> >>>>>>>Kafka
> >>>>>>> project uses kafka.* for Scala sources and org.apache.kafka.* for
> >>>>>>>Java
> >>>>>>> sources.
> >>>>>>>
> >>>>>>> Please let us know as soon as possible, because we are in process
> >>>>>>>of
> >>>>>>> renaming the  packages but if not mandatory we would want to keep
> >>>>>> gobblin.*
> >>>>>>> package name and avoid the cost of downstream migrations and
> >>>>>>>backwards
> >>>>>>> incompatibility.
> >>>>>>
> >>>>>> You don't have to do it right away, but it is a requirement unless
> >>>>>>you
> >>>>>> have a really,
> >>>>>> really, really good reason of why you can't do that.
> >>>>>>
> >>>>>>
> >>>>> I'm not aware of any requirement around Java package naming.  IN
> >>>>>fact,
> >>>>> last
> >>>>> time it came up it was clear that its a best practice only, and
> >>>>>doesn't
> >>>>> have any actual naming requirements.
> >>>>
> >>>> John: Do you have a link to that discussion?  I'm of the mind that
> >>>>it's
> >>>> an expected best practice, unless you have a really, really good
> >>>>reason
> >>>> otherwise.
> >>>>
> >>>> Abhishek: Can you describe in more detail what these packages do in
> >>>>the
> >>>> context of your software product?
> >>>>
> >>>> In general, yes, I'd echo Roman's point strongly for the primary
> >>>> external API that most users would call:
> >>>>
> >>>>>> Or to put it a different way: during your eventual graduation this
> >>>>>> question will be
> >>>>>> asked and you better have a really, really good explanation if
> >>>>>>you're
> >>>>>> still using
> >>>>>> something other than o.a.
> >>>>
> >>>> That is, supporting packages, or things that are standards, or thing=
s
> >>>> that are specific plugins that integrate with external code - those =
I
> >>>> could understand staying with a non-a.o package name for compatibili=
ty
> >>>> or other reasons.
> >>>>
> >>>> But the main program that users run in the JVM, or the primary Gobbl=
in
> >>>> classes that users integrating the code into their application?  Tha=
t
> >>>> should be in an org.apache.gobblin.* package.
> >>>>
> >>>> Simple "backwards compatibility for users" as an argument is only
> >>>> suitable if you're deprecating and have a plan to switch in the
> >>>> reasonably-near future after graduation.  Not for the long term.
> >>>>
> >>>> Thanks for raising the question early!
> >>>>
> >>>>>>
> >>>>>> Thanks,
> >>>>>> Roman.
> >>>>
> >>>> --
> >>>>
> >>>> - Shane
> >>>>
> >>>>
> >>>>
> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ap
> >>>>ach
> >>>><
> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.a
> >>>>pach>
> >>>> e.org
> >>>><
> https://na01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Fe.org%
> >>>>2F&data=3D02%7C01%7C%7C581cf191f4d745137c4008d4da8530d6%7Cfa7b1b5a7b3=
4438
> >>>>794aed2c178decee1%7C0%7C0%7C636373712971951815&sdata=3DaY%2BocRBKdLSJ=
NW7r
> >>>>0X4YnZ239BbsJWprJgTncaEESNQ%3D&reserved=3D0>%2Ffoundation%2Fmarks%2Fr=
esou
> >>>>rces&data=3D02%7C01%7C%7Cef18c5e74b0141378
> >>>>
> >>>>79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C63637360=
93
> >>>>056
> >>>>
> >>>>90124&sdata=3DOyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D&re=
serv
> >>>>ed=3D
> >>>> 0
> >>>>
> >>>> --------------------------------------------------------------------=
-
> >>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>><mailto:general-unsubscribe@incubator.apache.org>
> >>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>><mailto:general-help@incubator.apache.org>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>><mailto:general-unsubscribe@incubator.apache.org>
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>><mailto:general-help@incubator.apache.org>
> >>
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >For additional commands, e-mail: general-help@incubator.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>

--94eb2c0e9c76b91bb20555dbf48c--