incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "P. Taylor Goetz" <ptgo...@gmail.com>
Subject Re: Urgent: Regarding Java package name change to org.apache.*
Date Thu, 03 Aug 2017 22:40:30 GMT
When Storm was incubating, our package names started with backtype.* and storm.* and it stayed
that way through graduation and there was never any mention of a need to change. In fact,
Storm only moved to org.apache.* with the 1.0 release in April 2016, about 1.5 years after
graduation.

There are implications for Heron since it maintains backtype.* and storm.* packages presumably
for backward compatibility with older versions of Storm. I’m not sure what that means.

I think it would be prudent to better clarify and document the policy around this.

-Taylor

> 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%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
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message