I am not a stakeholder in e4, but I do pay
attention to what is happening in the project and I thought I would add my two
cents to this discussion. I agree with John that having a convention for this
and sticking to it is extremely important. I also agree with Ed that the
conventions currently used by the platform are not the best. Some of the other
projects have already moved to the convention that separates api from internal
code as late as possible in the namespace. This keeps the code together and
makes it easier to move it across bundle boundaries as a unit (merging bundles,
splitting bundles, etc.).
For instance…
bundle id: org.eclipse.fproj.enablement.jdt
Packages:
org.eclipse.fproj.enablement.jdt
org.eclipse.fproj.enablement.jdt.internal
org.eclipse.fproj.enablement.jdt.libprov
org.eclipse.fproj.enablement.jdt.libprov.internal
In fact, I would argue that when
developing a new functional area, even when you don’t immediately have
any plans for API, it would be prudent to reserve location in the namespace for
future API additions.
org.eclipse.fproj.enablement.jdt.something.internal
<-- shipping in a particular release
org.eclipse.fproj.enablement.jdt.something
<-- reserved for future api additions
The above strategy allows you to keep
co-location API and internal code without moving the internal code after API is
added.
Hope this helps the discussion,
- Konstantin
Konstantin
Komissarchik
| Consulting Member of Technical Staff
Phone: +1 425 945 8445 | Mobile: +1 206 898 0611
Oracle
Eclipse Tooling
411 108th Ave NE, Suite 800
| Bellevue, WA 98004
From: e4-dev-bounces@xxxxxxxxxxx
[mailto:e4-dev-bounces@xxxxxxxxxxx] On Behalf
Of Ed Merks
Sent: Tuesday, February 10, 2009
9:42 AM
To: E4 Project developer mailing
list
Subject: Re: [e4-dev] Package
naming
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
