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 22:20:25 GMT
Which must's do you see greg?

On Aug 3, 2017 1:09 PM, "Greg Trasuk" <trasukg@stratuscom.com> wrote:

> Does this actually need to be policy?  What’s the harm to the foundation
> if a project continues to use a non-Apache package name, assuming that the
> code was donated appropriately?
>
> Certainly, it should be a goal for all projects to use o.a.* package
> names, but if you look around the Foundation’s projects, you’re probably
> going to find lots of non-o.a.* packages.  So it seems like this is another
> case of “Incubator has one (sort-of) policy, while the rest of the
> Foundation does its own thing” cases.  And that being the case, it seems
> like an unreasonable imposition on podlings.
>
> I’d suggest taking out the MUSTs wherever possible, and having mentors
> make “should”, or maybe even “oughta” recommendations.  Apache is already
> seen as unfriendly enough to podlings.
>
> Cheers,
>
> Greg.
> > On Aug 3, 2017, at 12:34 PM, 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
> >>
>
>
> ---------------------------------------------------------------------
> 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