John,
It's always struck me as unnatural for a component's packages not to be
rooted on the component. Consider too that in EMF we have
components-soon-to-be-subprojects where the subproject name is
effectively two part, e.g., emf.compare, emf.ecoretools, emf.cdo, and
so on. I agree that consistency is nice though I wonder how the
placement of internal creates confusion. It seems reasonable to argue
that if I'm looking for all the packages of a component that I can look
within its namespace...
John Arthorne wrote:
The e4 package names don't follow
the
Eclipse project conventions [1], or any other convention as far as I
can
tell. In particular, the position of "internal" in package names
isn't consistent across e4 bundles, for example:
org.eclipse.e4.ui.model.internal.application
(internal is 6th segment)
org.eclipse.e4.ui.model.internal.workbench
org.eclipse.e4.workbench.ui.internal
Neither of which match the Eclipse
convention
of:
org.eclipse.<subproject>.internal.<component>.*
(internal is always 4th segment)
Or the Eclipse 3.x packages:
org.eclipse.ui.internal.application
(internal is 4th segment)
There are also some css packages
that
use "impl" as part of the package name rather than "internal",
presumably for the same purpose?
Unlike the test bundle/package names
we mentioned earlier, the existing convention is currently followed
consistently
across the other Eclipse projects (org.eclipse.jdt.internal.*,
org.eclipse.equinox.internal.*,
org.eclipse.pde.internal.*).
The e4 bundles also don't
consistently
follow the convention that the bundle id matches the dominant Java
package
(bundle org.eclipse.e4.ui.workbench contains packages
org.eclipse.e4.workbench.ui.*).
While I'd like to see us revert back
to following the Eclipse conventions, we can discuss picking a new
convention
in e4 if that makes sense. Ultimately my main concern is about
consistency,
as these naming differences create confusion and are generally
impossible
to fix after the first release.
Thoughts?
[1] -
http://wiki.eclipse.org/Naming_Conventions#Java_Packages
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev
|
