You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Abhishek Tiwari <ab...@apache.org> on 2017/08/03 00:40:47 UTC
Urgent: Regarding Java package name change to org.apache.*
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.
Regards,
Abhishek
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Von Gosling <vo...@apache.org>.
> 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.
In fact, Apache RocketMQ Community has ever struggle with this issue. Consider more than 100 subsidiary corporations and 1000+ applications using rocketmq 3.x version(before incubator, not naming org.apache.*), we are not planning to change the package originally until some new version changed dramatically. On the other hand, we resort to maven shade to workaround for backwards incompatibility. So, I are very pleased to introduce this way for guys, if we hope to avoid the cost of downstream migrations and backwards incompatibility :-)
Best Regards
Von Gosling
> 在 2017年8月3日，08:54，Roman Shaposhnik <ro...@shaposhnik.org> 写道：
>
> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <abti@apache.org <ma...@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.
>
> 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.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by "John D. Ament" <jo...@apache.org>.
On Thu, Aug 3, 2017 at 8:42 AM Shane Curcuru <as...@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 <ro...@shaposhnik.org>
> > wrote:
> >
> >> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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.
>
Sure, its here [1]. There are two TLPs that I know have this issue -
Polygene and Groovy. There's a few others as well, I'm sure.
[1]:
https://lists.apache.org/thread.html/15550f5bf622ae3070b558505c8a0fd0ce3b23df3012d57de8b6d9f3@%3Cgeneral.incubator.apache.org%3E
>
> 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://www.apache.org/foundation/marks/resources
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Wade Chandler <wa...@apache.org>.
>
>
> On Aug 3, 2017, at 12:25, Alex Harui <ah...@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
NetBeans uses org.netbeans, and the domain is also being donated to Apache. It is not just an IDE, but is also a rich client platform, like Eclipse, so I don’t think just a reverse domain name should be justification for MUST. Surely part of the decision takes into consideration the life of the project along with what that reverse domain is.
> 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?
Thanks,
Wade
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Greg Stein <gs...@gmail.com>.
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 <jo...@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 <ah...@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" <an...@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 <ah...@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
> > >>><ma...@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
> > >>>>><ro...@shaposhnik.org>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
> > >>>><ma...@incubator.apache.org>
> > >>>> For additional commands, e-mail: general-help@incubator.apache.org
> > >>>><ma...@incubator.apache.org>
> > >>>>
> > >>>
> > >>>
> > >>> ------------------------------------------------------------
> ---------
> > >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > >>><ma...@incubator.apache.org>
> > >>> For additional commands, e-mail: general-help@incubator.apache.org
> > >>><ma...@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
> >
>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
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 <jo...@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 <ah...@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" <an...@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 <ah...@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
>>>>> <ma...@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
>>>>>>> <ro...@shaposhnik.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
>>>>>> <ma...@incubator.apache.org>
>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>> <ma...@incubator.apache.org>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> <ma...@incubator.apache.org>
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>> <ma...@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
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by sebb <se...@gmail.com>.
On 4 August 2017 at 12:17, Shane Curcuru <as...@shanecurcuru.org> wrote:
> Andy Seaborne wrote on 8/4/17 5:00 AM:
>> On 03/08/17 23:20, John D. Ament wrote:
>>> Which must's do you see greg?
>>>
>>> On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tr...@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?
>
> Because in some cases, the donating company may continue to market
> around the name, leading existing or completely new users to assume that
> the company still runs the project. When a project comes to Apache,
> it's an *Apache* project.
>
> That's obvious to those of us who read this list. It's not obvious to
> the average developer (i.e. potential future contributor), nor to the
> average CTO or other manager who decides if their employees are allowed
> to contribute to FOSS project X or if they're going to buy support from
> the original donating company.
>
> So the answer is: "it depends" on how the package name will be used in
> code examples or common use cases, and seen by new developers evaluating
> use of this software product.
>
>>>>> 1) package names with reverse domains MUST be renamed
>>>>> before graduation or have an IPMC approved plan for renaming
>>
>> SHOULD
>> (i.e. it needs a justification but isn't absolutely prohibited)
>
> It depends. Trying to start thinking about what matters from a brand
> perspective:
>
> - Renaming is a MUST if the reverse domain name starts with com.*
>
> - Renaming is a MUST if the domain name is not being legally transferred
> to the ASF before graduation.
>
> - Renaming is a MUST if parts of the domain name are still claimed as
> trademarks by the donating party.
>
> - Other reverse domain names *really* should change to org.apache;
> otherwise it's just confusing.
>
Not only confusing - there's also the issue of who 'owns' the top
package domain, i.e. who gets to decide what sub-package names can be
used.
> -- The criteria should be applied strictly for the packages that are the
> "main" class or the primary API programming interface for the most
> common functionality of the product. All other packages (utilities,
> shims, standards, etc.) have more freedom in keeping existing names.
>
> - Functionality-derived package names - that's up to the community; I
> can definitely see it making sense to stick with existing names.
Again, the community needs to consider whether they have complete
control over the package names they are currently using and may wish
to use in future.
Using org.apache.project.* means that potential clashes are limited to
the ASF project.
> ...snip...
>
> --
>
> - Shane
> https://www.apache.org/foundation/marks/resources
>
> ---------------------------------------------------------------------
> 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
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Wade Chandler <wa...@apache.org>.
On Aug 4, 2017 10:37, "Andy Seaborne" <an...@apache.org> wrote:
On 04/08/17 13:09, Shane Curcuru wrote:
> John D. Ament wrote on 8/4/17 7:59 AM:
>
>> On Fri, Aug 4, 2017 at 7:17 AM Shane Curcuru <as...@shanecurcuru.org>
>> wrote:
>>
> ...snip...
>
>> - Other reverse domain names *really* should change to org.apache;
>>> otherwise it's just confusing.
>>>
>>>
>>> Agreed. The one caveat to all this is the implementation of javax.
>> namespace which is typically required and managed by the Geronimo TLP
>> (typically).
>>
> ...snip...
>
> Good point - any package names where there's a well-known technical
> standard that specifies package names takes precedence for naming.
> That's what a normal user would expect, and they also (typically)
> understand there's a difference between the standard API names and the
> actual implementation of the API they've downloaded.
>
>
We seem to have lost the community impact. Projects with a existing
pre-ASF history can have a halo of support in tutorials, books, etc (not
from the donating corp) that all contribute to the success of a project.
The principle that the project outputs come from Apache can be achieved in
various ways. State the principle not the mechanism.
I agree with this. The move to Apache should be seen as a positive by
everyone including users. If the first thing they have to do is change
package names just to go from what may likely be a trivial update likewise,
that is not very positive; especially if a domain and name, trademarks, are
donated to Apache. There is also the notion of having artifacts that still
run on older versions of a system as well in some cases, such as plugins
and 3rd party library creators, so heavier support burden.
Anyways, I am just addressing all the worry about Apache branding etc. That
branding will be every where; lists, sites, articles, etc. I seriously do
not believe a stable and well known projects package names will be a major
source of confusion. It seems to me, most people I have talked to or worked
with in the industry know how open source donations work, and package names
are generally not the major indicator of ownership when transfers happen;
folks tend to be aware of ecosystem changes and impacts. Maybe some young
and junior folks not yet schooled in the way of the Jedi will have some,
but that is the role of mentoring.
IMHO, thanks,
Wade
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Andy Seaborne <an...@apache.org>.
On 04/08/17 13:09, Shane Curcuru wrote:
> John D. Ament wrote on 8/4/17 7:59 AM:
>> On Fri, Aug 4, 2017 at 7:17 AM Shane Curcuru <as...@shanecurcuru.org> wrote:
> ...snip...
>>> - Other reverse domain names *really* should change to org.apache;
>>> otherwise it's just confusing.
>>>
>>>
>> Agreed. The one caveat to all this is the implementation of javax.
>> namespace which is typically required and managed by the Geronimo TLP
>> (typically).
> ...snip...
>
> Good point - any package names where there's a well-known technical
> standard that specifies package names takes precedence for naming.
> That's what a normal user would expect, and they also (typically)
> understand there's a difference between the standard API names and the
> actual implementation of the API they've downloaded.
>
We seem to have lost the community impact. Projects with a existing
pre-ASF history can have a halo of support in tutorials, books, etc (not
from the donating corp) that all contribute to the success of a project.
The principle that the project outputs come from Apache can be achieved
in various ways. State the principle not the mechanism.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Shane Curcuru <as...@shanecurcuru.org>.
John D. Ament wrote on 8/4/17 7:59 AM:
> On Fri, Aug 4, 2017 at 7:17 AM Shane Curcuru <as...@shanecurcuru.org> wrote:
...snip...
>> - Other reverse domain names *really* should change to org.apache;
>> otherwise it's just confusing.
>>
>>
> Agreed. The one caveat to all this is the implementation of javax.
> namespace which is typically required and managed by the Geronimo TLP
> (typically).
...snip...
Good point - any package names where there's a well-known technical
standard that specifies package names takes precedence for naming.
That's what a normal user would expect, and they also (typically)
understand there's a difference between the standard API names and the
actual implementation of the API they've downloaded.
--
- Shane
https://www.apache.org/foundation/marks/resources
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by "John D. Ament" <jo...@apache.org>.
On Fri, Aug 4, 2017 at 7:17 AM Shane Curcuru <as...@shanecurcuru.org> wrote:
> Andy Seaborne wrote on 8/4/17 5:00 AM:
> > On 03/08/17 23:20, John D. Ament wrote:
> >> Which must's do you see greg?
> >>
> >> On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tr...@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?
>
> Because in some cases, the donating company may continue to market
> around the name, leading existing or completely new users to assume that
> the company still runs the project. When a project comes to Apache,
> it's an *Apache* project.
>
> That's obvious to those of us who read this list. It's not obvious to
> the average developer (i.e. potential future contributor), nor to the
> average CTO or other manager who decides if their employees are allowed
> to contribute to FOSS project X or if they're going to buy support from
> the original donating company.
>
> So the answer is: "it depends" on how the package name will be used in
> code examples or common use cases, and seen by new developers evaluating
> use of this software product.
>
> >>>> 1) package names with reverse domains MUST be renamed
> >>>> before graduation or have an IPMC approved plan for renaming
> >
> > SHOULD
> > (i.e. it needs a justification but isn't absolutely prohibited)
>
> It depends. Trying to start thinking about what matters from a brand
> perspective:
>
> - Renaming is a MUST if the reverse domain name starts with com.*
>
>
Agreed.
> - Renaming is a MUST if the domain name is not being legally transferred
> to the ASF before graduation.
>
>
I would say unless there is strong evidence that the name will be
transferred.
> - Renaming is a MUST if parts of the domain name are still claimed as
> trademarks by the donating party.
>
>
Agreed.
> - Other reverse domain names *really* should change to org.apache;
> otherwise it's just confusing.
>
>
Agreed. The one caveat to all this is the implementation of javax.
namespace which is typically required and managed by the Geronimo TLP
(typically).
> -- The criteria should be applied strictly for the packages that are the
> "main" class or the primary API programming interface for the most
> common functionality of the product. All other packages (utilities,
> shims, standards, etc.) have more freedom in keeping existing names.
>
> - Functionality-derived package names - that's up to the community; I
> can definitely see it making sense to stick with existing names.
>
> ...snip...
>
> --
>
> - Shane
> https://www.apache.org/foundation/marks/resources
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Andy Seaborne wrote on 8/4/17 5:00 AM:
> On 03/08/17 23:20, John D. Ament wrote:
>> Which must's do you see greg?
>>
>> On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tr...@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?
Because in some cases, the donating company may continue to market
around the name, leading existing or completely new users to assume that
the company still runs the project. When a project comes to Apache,
it's an *Apache* project.
That's obvious to those of us who read this list. It's not obvious to
the average developer (i.e. potential future contributor), nor to the
average CTO or other manager who decides if their employees are allowed
to contribute to FOSS project X or if they're going to buy support from
the original donating company.
So the answer is: "it depends" on how the package name will be used in
code examples or common use cases, and seen by new developers evaluating
use of this software product.
>>>> 1) package names with reverse domains MUST be renamed
>>>> before graduation or have an IPMC approved plan for renaming
>
> SHOULD
> (i.e. it needs a justification but isn't absolutely prohibited)
It depends. Trying to start thinking about what matters from a brand
perspective:
- Renaming is a MUST if the reverse domain name starts with com.*
- Renaming is a MUST if the domain name is not being legally transferred
to the ASF before graduation.
- Renaming is a MUST if parts of the domain name are still claimed as
trademarks by the donating party.
- Other reverse domain names *really* should change to org.apache;
otherwise it's just confusing.
-- The criteria should be applied strictly for the packages that are the
"main" class or the primary API programming interface for the most
common functionality of the product. All other packages (utilities,
shims, standards, etc.) have more freedom in keeping existing names.
- Functionality-derived package names - that's up to the community; I
can definitely see it making sense to stick with existing names.
...snip...
--
- Shane
https://www.apache.org/foundation/marks/resources
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Andy Seaborne <an...@apache.org>.
On 03/08/17 23:20, John D. Ament wrote:
> Which must's do you see greg?
>
> On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tr...@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?
>>> 1) package names with reverse domains MUST be renamed
>>> before graduation or have an IPMC approved plan for renaming
SHOULD
(i.e. it needs a justification but isn't absolutely prohibited)
>>> 2) Projects who expect that their future users outnumber
>>> current users are highly encouraged to rename packages
+1
>>> 3) Other projects are not required to rename packages and
>>> backward compatibility is sufficient reason to not rename packages.
So there seem to be several cases:
Donated names should be fine. (What about Maven coordinates here?)
.com really ought to migrate at the first convenient moment.
Non-donated, non-".com", less pressure but ought to migrate.
(Maven coordinates MUST change on entering the incubator.)
Andy
>> 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 <jo...@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 <ah...@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" <an...@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 <ah...@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
>>>>>>> <ma...@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
>>>>>>>>> <ro...@shaposhnik.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
>>>>>>>> <ma...@incubator.apache.org>
>>>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>>>> <ma...@incubator.apache.org>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------
>> ---------
>>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>>> <ma...@incubator.apache.org>
>>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>>> <ma...@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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by "John D. Ament" <jo...@apache.org>.
Which must's do you see greg?
On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tr...@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 <jo...@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 <ah...@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" <an...@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 <ah...@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
> >>>>> <ma...@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
> >>>>>>> <ro...@shaposhnik.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
> >>>>>> <ma...@incubator.apache.org>
> >>>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>>> <ma...@incubator.apache.org>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ---------
> >>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>>> <ma...@incubator.apache.org>
> >>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>> <ma...@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
>
>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Abhishek Tiwari <ab...@apache.org>.
Thanks all for your replies. We decided to bite the bullet and do it since
we are half way already through our work. We will try to address backward
incompatibilities via package shims, and special handling of configs.
On a side note, I think for matters such as these Incubator should document
the official wording once and for all, so that future incubating projects
can plan ahead and have clarity.
Thanks again,
Abhishek
On Thu, Aug 3, 2017 at 10:08 AM, Greg Trasuk <tr...@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 <jo...@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 <ah...@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" <an...@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 <ah...@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
> >>>>> <ma...@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
> >>>>>>> <ro...@shaposhnik.org>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
> >>>>>> <ma...@incubator.apache.org>
> >>>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>>> <ma...@incubator.apache.org>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> ------------------------------------------------------------
> ---------
> >>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>>>> <ma...@incubator.apache.org>
> >>>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>>> <ma...@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
>
>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Greg Trasuk <tr...@stratuscom.com>.
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 <jo...@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 <ah...@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" <an...@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 <ah...@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
>>>>> <ma...@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
>>>>>>> <ro...@shaposhnik.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
>>>>>> <ma...@incubator.apache.org>
>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>> <ma...@incubator.apache.org>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>> <ma...@incubator.apache.org>
>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>> <ma...@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
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by "John D. Ament" <jo...@apache.org>.
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 <ah...@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" <an...@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 <ah...@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
> >>><ma...@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
> >>>>><ro...@shaposhnik.org>
> >>>>> wrote:
> >>>>>
> >>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
> >>>><ma...@incubator.apache.org>
> >>>> For additional commands, e-mail: general-help@incubator.apache.org
> >>>><ma...@incubator.apache.org>
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> >>><ma...@incubator.apache.org>
> >>> For additional commands, e-mail: general-help@incubator.apache.org
> >>><ma...@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
>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <an...@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 <ah...@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
>>><ma...@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
>>>>><ro...@shaposhnik.org>
>>>>> wrote:
>>>>>
>>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
>>>><ma...@incubator.apache.org>
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>><ma...@incubator.apache.org>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>><ma...@incubator.apache.org>
>>> For additional commands, e-mail: general-help@incubator.apache.org
>>><ma...@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
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Andy Seaborne <an...@apache.org>.
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 <ah...@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 <ma...@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 <ro...@shaposhnik.org>
>>>> wrote:
>>>>
>>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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 <ma...@incubator.apache.org>
>>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Julian Hyde <jh...@apache.org>.
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.
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.
Julian
> On Aug 3, 2017, at 7:37 AM, Alex Harui <ah...@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 <ma...@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 <ro...@shaposhnik.org>
>>> wrote:
>>>
>>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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 <ma...@incubator.apache.org>
>> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org <ma...@incubator.apache.org>
> For additional commands, e-mail: general-help@incubator.apache.org <ma...@incubator.apache.org>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Shane Curcuru <as...@shanecurcuru.org>.
Alex Harui wrote on 8/3/17 10:37 AM:
> 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).
This is the only significant point for me. I would be -1 on TLPs
continuing to ship a com.company.* package for the primary code for the
project
*If* there is a long history of use and expectations of compatibility,
and *if* the package names are not reverse-domains but are just
component names, then that's fine to keep the package 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
Any packages that use the reversed domain name prefix.
> 2) there is no recommendation for other package prefixes
It's still a best practice to use org.apache.*, unless the package
prefix is long-used and is based on component or functionality names.
--
- Shane
https://www.apache.org/foundation/marks/resources
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Alex Harui <ah...@adobe.com.INVALID>.
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" <as...@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 <ro...@shaposhnik.org>
>> wrote:
>>
>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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
>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
>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
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Shane Curcuru <as...@shanecurcuru.org>.
John D. Ament wrote on 8/2/17 9:13 PM:
> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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://www.apache.org/foundation/marks/resources
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Aug 3, 2017 at 2:42 AM, Andy Seaborne <an...@apache.org> wrote:
> On 03/08/17 05:13, Roman Shaposhnik wrote:
>
>> On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament <jo...@apache.org>
>> wrote:
>>
>>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik <ro...@shaposhnik.org>
>>> wrote:
>>>
>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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.
>>>
>>
>> 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:
>> http://markmail.org/message/2bsrtgckuuihhnv4
>> 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.
Cheers,
-g
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Andy Seaborne <an...@apache.org>.
On 03/08/17 05:13, Roman Shaposhnik wrote:
> On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament <jo...@apache.org> wrote:
>> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik <ro...@shaposhnik.org>
>> wrote:
>>
>>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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.
>
> 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:
> http://markmail.org/message/2bsrtgckuuihhnv4
> 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.
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament <jo...@apache.org> wrote:
> On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
>
>> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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.
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:
http://markmail.org/message/2bsrtgckuuihhnv4
during your graduation VOTE -- it is better to think about rename now.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by "John D. Ament" <jo...@apache.org>.
On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik <ro...@shaposhnik.org>
wrote:
> On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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.
> 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.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>
Re: Urgent: Regarding Java package name change to org.apache.*
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari <ab...@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.
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.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org