incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: Urgent: Regarding Java package name change to org.apache.*
Date Sat, 05 Aug 2017 02:24:53 GMT
And remember: like Apache Subversion, the project can keep a
*compatibility* layer around using the old name. But "all" new development
work would occur under the new org.apache name...


On Thu, Aug 3, 2017 at 11:34 AM, John D. Ament <johndament@apache.org>
wrote:

> 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%7C581cf191f4d745137c4008d4da85
> 30d6%7Cfa7b1b5a7b34438
> > >>>>794aed2c178decee1%7C0%7C0%7C636373712971951815&sdata=aY%
> 2BocRBKdLSJNW7r
> > >>>>0X4YnZ239BbsJWprJgTncaEESNQ%3D&reserved=0>%2Ffoundation%
> 2Fmarks%2Fresou
> > >>>>rces&data=02%7C01%7C%7Cef18c5e74b0141378
> > >>>>
> > >>>>79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178de
> cee1%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