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 >
