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 <johndam...@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 <aha...@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" <a...@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 <aha...@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" <a...@shanecurcuru.org >>>>> <mailto:a...@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 <a...@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-unsubscr...@incubator.apache.org >>>>>> <mailto:general-unsubscr...@incubator.apache.org> >>>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>>> <mailto:general-h...@incubator.apache.org> >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>> <mailto:general-unsubscr...@incubator.apache.org> >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>> <mailto:general-h...@incubator.apache.org> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
