incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: Urgent: Regarding Java package name change to org.apache.*
Date Thu, 03 Aug 2017 08:28:42 GMT
On Thu, Aug 3, 2017 at 2:42 AM, Andy Seaborne <> wrote:

> On 03/08/17 05:13, Roman Shaposhnik wrote:
>> On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament <>
>> wrote:
>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik <>
>>> wrote:
>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <> 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.
>> I'm not a policy wonk, but for every single podling I've witnessed this
>> has been a very strong bias to be in o.a namespace.
>> Speaking as an IPMC member I would like to see new projects migrate
>> into o.a namespace unless there's a really good reason not to.
>> Or to put it another way, if you want to avoid threads like this one:
>> during your graduation VOTE -- it is better to think about rename now.
> Jena was in a similar position with the main APIs under non o.a package
> spaces.
> We waited until a major version came along and that was several years
> after graduation.  While it had always been the intent to change, we could
> see that there was going to be major version hop due to othe factors and we
> didn't want to do it twice. We did move non-API code under o.a much earlier
> on an piecemeal basis.
> Jena users also have data with URI naming based on host names from our
> origins in HP. We have not moved those to a.o names but encourage migration
> though outputting some warnings when it is encountered and can easily
> changed.
> I think it sends a positive signal to new contributors to make the package
> change but it isn't always practical to do so by graduation. The user
> community is already impacted by moving the mailing lists and web sites etc.
> For JVM-related projects, the maven coordinates change on entering
> incubation. That is a strong enough signal.

Apache Subversion created a new org.apache.subversion API, and then rebuilt
our old org.tigris API on top of that. The old API is deprecated but still
available. It was also a great chance to refine the API after feedback from
users, and to drop ugly approaches. Much cleaner.

I'd definitely recommend constructing a new API within the org.apache
namespace, and deprecating the old. If you can't do it by graduation, then
get it on the roadmap as a high priority. Keep the old around as (say) a
separate compatibility package, layered onto the new API/naming.


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