incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: Urgent: Regarding Java package name change to org.apache.*
Date Thu, 03 Aug 2017 16:34:24 GMT
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 or
> have an IPMC approved plan for renaming
> 2) Projects who expect that their future users outnumber current users are
> 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’s mainly
> >>the project’s discretion. In my opinion, where the project is on 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 to
> >>>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 things
> >>>> that are specific plugins that integrate with external code - those
I
> >>>> could understand staying with a non-a.o package name for compatibility
> >>>> or other reasons.
> >>>>
> >>>> But the main program that users run in the JVM, or the primary Gobblin
> >>>> classes that users integrating the code into their application?  That
> >>>> 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=https%3A%2F%2Fwww.ap
> >>>>ach
> >>>><
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.a
> >>>>pach>
> >>>> e.org
> >>>><
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fe.org%
> >>>>2F&data=02%7C01%7C%7C581cf191f4d745137c4008d4da8530d6%7Cfa7b1b5a7b34438
> >>>>794aed2c178decee1%7C0%7C0%7C636373712971951815&sdata=aY%2BocRBKdLSJNW7r
> >>>>0X4YnZ239BbsJWprJgTncaEESNQ%3D&reserved=0>%2Ffoundation%2Fmarks%2Fresou
> >>>>rces&data=02%7C01%7C%7Cef18c5e74b0141378
> >>>>
> >>>>79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363736093
> >>>>056
> >>>>
> >>>>90124&sdata=OyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D&reserv
> >>>>ed=
> >>>> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message