I'd be in favour of a distinct name like org.eclipse.jgit too instead of egit.core -given that licensing is different between the .egit. and .jgit. packages, hiding it behind an obscure egit.core name might lead to confusion. At least this way, the rule for knowing licensing is easily identifiable and can be distinguished between the two, both in code and on the website.
Alex
Sent from my (new) iPhone
Why not just call it org.eclipse.jgit. It would be highly unlikely you end up with a namespace clash in the future. I'm sure we'd never allow a project named jgit anyway to avoid confusion with this one. I don't know why we get hung up on naming. I'm sure there's better use of our time.
The curmudgeon pragmatist, Doug. On Fri, Sep 25, 2009 at 7:40 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> wrote:
> Or you could consider the approach we've taken several times, mostly modeled
> on Platform, to make the dependencies explicit in the bundle names:
> * org.eclipse.egit.core (JGit stuff, runs happily on a Java classpath)
> * org.eclipse.egit.resources (core stuff coupled to workspace/resources,
> current stuff in core)
> * org.eclipse.egit.ui (coupled to workbench/UI)
OK, I'm going to propose that we name them as above. It means
renaming our current core bundle/package, but the UI bundle/package
can stay where it is.
org.eclipse.egit.jgit just bothers me, too many gits in the kitchen.
And like you, I don't like deep package namespaces.
--
|
