Re: [eclipse.org-architecture-council] Bundle and Java package naming

[David M Williams <david_williams@xxxxxxxxxx>]

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