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" <tras...@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 <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%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-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
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
