incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Simons <>
Subject Re: JavaHL package namespace / migration / compatability
Date Wed, 18 Nov 2009 18:22:20 GMT
On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman <> wrote:
> On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
> <> wrote:
>> As Hyrum suggests, we can use org.apache.subversion.* if we want to
>> create a new (better) Java interface within our versioning rules - but
>> that isn't necessary nor should it be a pre-req for graduation.
> IMNSHO, either Subversion address this issue pre-graduation, OR we
> remove the package name change requirement for ALL incubating
> projects, leaving it up to the project post-graduation to address it.

Any reference to this being a requirement? I looked for it the other
day but didn't find anything.

"If its not documented rule it is not a rule".

> It has been a contentious issue in the past, and will be so in the
> future, and I am not going to defend ASF's position if it doesn't
> apply to everyone.
> I would actually like to hear from more Java-centric developers of
> Board and IPMC what they think about this...

I wouldn't say I'm java-centric but I do a lot of it :)

I think package renaming is in many cases required for branding or
trademark reasons (which goes both ways --
was an issue once, would be today, but on the upside
"import org.apache" may make people feel nice and cosy, too).

I think<foo> or org.tigris.<foo> is not that big an issue to
keep (for a while), if there's good enough reasons (like api
compatibility for an established codebase).

Beyond that, I personally think the java standards for package naming
are really a mixed blessing, and if a project wanted to break them
(say subversion decided to go with subversion.<stuff> instead of
org.apache.subversion.<stuff>), fine, good luck to them. Regardless of
the stupidity of the rules (or the stupidity of breaking the rules),
we as incubator should really not even try to enforce these kinds of
standards; projects should make their own decisions about that.



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message