incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <a...@apache.org>
Subject Re: Urgent: Regarding Java package name change to org.apache.*
Date Thu, 03 Aug 2017 15:34:46 GMT


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.apach <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apach>
>>> e.org <http://e.org/>%2Ffoundation%2Fmarks%2Fresources&data=02%7C01%7C%7Cef18c5e74b0141378
>>> 79a08d4da6d0e5c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6363736093056
>>> 90124&sdata=OyrEoidSvoONvFJksGYjhhz%2FatAd4b%2FyjmHcfoGeI%2B0%3D&reserved=
>>> 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


Mime
View raw message