+1 for taking the current Naming Conventions and making them
general for all projects. They’re very valuable guidelines and will
help with both consistency and preventing name clashes.
My preference is that we figure out a way to enforce what’s
pretty much a de facto standard: only Eclipse Platform components and
project short names can exist in the top-level org.eclipse.* namespace. It
should be perfectly fine to have two bittorrent facilities in Eclipse, but this
will only work well if the bundles includes the project names. Since
Platform is already holding some valuable parts of the org.eclipse namespace
that can make for good project names, I also think it would be good for
Platform to have to consult with whatever body governs the naming before using
more (e.g., if a related project is in the proposal pipeline).
Mik
From:
eclipse.org-architecture-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-architecture-council-bounces@xxxxxxxxxxx] On Behalf Of John
Arthorne
Sent: Thursday, February 14, 2008 1:07 PM
To: eclipse.org-architecture-council@xxxxxxxxxxx
Subject: [eclipse.org-architecture-council] Bundle and Java package
naming
During today's architecture council meeting,
I raised the topic of management of the org.eclipse.* namespace of bundle and
package names. I just wanted to elaborate here so other architecture council
members who were unable to attend can comment. We generally follow the
convention that each project owns one or more "level three"
namespaces (org.eclipse.<project>), but as far as I can tell, there is no
formal management of the allocation of these names to projects. There is
potential for confusion, or even runtime problems, if plug-ins from multiple
projects end up with the same names, and the plug-ins end up being delivered
together (for example in the Eclipse release train, or in Eclipse-based
products). Doug raised the example of org.eclipse.pdt.*, which could mean
Python tools, PHP tools, Perl tools, etc. I regularly run across cases where
projects are assuming ownership of names other than
org.eclipse.<theirOwnProjectName>.*. Merely by way of example, I
saw this note today about a plug-in in ECF called "org.eclipse.bittorrent":
http://dev.eclipse.org/mhonarc/lists/equinox-dev/msg03680.html
This one is not likely to collide with other
projects, but it illustrates that this does happen today. Other names,
particularly three letter acronyms (TLAs), have a higher potential for collision
across projects. My question to the architecture council was: is there a
need for more management of bundle and package names, and can the architecture
council help in this area. For example, we could maintain a list of the name
allocations so that projects can see what is available. Should this be managed
by the EMO, possibly in consultation with the arch council? Can we help by
taking the Eclipse top-level project naming conventions
(http://wiki.eclipse.org/Naming_Conventions), and generalize them into a set of
conventions/guidelines for all Eclipse projects?
Thoughts, comments, flames?
|
