Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Bundle and Java package naming


They third spot name of course has to be managed, and is supposed to reflect the project name, and long ago I was told these are "owned and allocated" by the EMO. Naturally, there are exceptions, for example the Eclipse Platform didn't follow these rules since it started before there was ever any perception of what Eclipse would become. And others change their projects, such as WTP, so in many cases we continue to use the old project names, instead of new ones, so as to not break adopters.

But, I can't find in writing where that's said (that the EMO owns and assigns them) and in fact, according to a note in
http://www.eclipse.org/projects/project_provisioning_request.php
it sounds pretty much left up to who ever fills out the form to get a project provisioned. (if that document is still current).
<quote>
Typical component names are org.eclipse.[shortname].[component]. The short name is some variation of the project's Descriptive Name - the Acronym, a shortened version, or even the whole name. The project's optional Nickname is not a valid short name for CVS/SVN components
</quote>

Where 'project' in the above means 'subproject' of the top level project ... explicitly not the top level project.

So, I don't mind a "clearing committee" of a small group of Eclipse Architects that would maintain the list, and should give stamp of approval to newly proposed short names.
But ... I think the ability to agree or guide the descriptive quality of the name or acronym is limited. I personally think PDT is fine and just as descriptive as JDT or PDE. (and, there were other
reasons to avoid 'php', anyway, for this case).

But, seems the current rules are sufficient to say that  "org.eclipse.bittorrent" is wrong, and worth a bug, and should be changed (unless there is undue impact on adopters code).

Similarly I've never perceived the naming conventions to be all that Platform specific, and have often used them to open bugs on how projects use their own custom settings files in a project (and, they've all agreed, saw the merit of it, and changed).

I think that other than the third spot being for the project name, the rest of the naming conventions should be suggested guidelines. For example, I've never liked the recommendation on the placement of 'tests' and 'examples', have never understood it, and it doesn't seem followed by that many people.

So, I nominate John to head up this subcommittee to be formed by 3 or 4 people he chooses, and to be a rotating assignment. :)
Their first task would be to draft a short document on their role, and how to fit into the "project provisioning" process ... that we could all discuss and vote to agreement, and then off they'd go.




From: John Arthorne <John_Arthorne@xxxxxxxxxx>
To: eclipse.org-architecture-council@xxxxxxxxxxx
Date: 02/14/2008 04:07 PM
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?
_______________________________________________
eclipse.org-architecture-council mailing list
eclipse.org-architecture-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-architecture-council


Back to the top