Community
Participate
Working Groups
Given some recent events (e.g. see bug 330312) I think it would help future communication if the EDP said more about project namespaces. A couple of improvements I don't think would be controversial, but perhaps one point would be. I haven't thought much about exact wording, or which exactly which sections of EDP, but will just comment on the concepts and perhaps wording will be more obvious after community discussion. First, I think the "docuware" for creation reviews, re-org reviews, and probably move reviews, should list explicitly what the proposed namespace for the proposed project would be. As far as I know, this has to be done currently only at provisioning time, but seems some community review would help communication and avoid surprises (both for the new project, and the community) and provide an explicit document trail for who has what. For some previous discussion about this topic, see the following (old) mailing message: http://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg00338.html and the documents and bugs it references. Second, the rules about "how to do it" should be spelled out, or, at least give a link to http://wiki.eclipse.org/index.php/Naming_Conventions (though that document might have to be improved some for this purpose?) But the main rule is simply org.eclipse.<subproject>.<component>[.*] where "subproject" is shortname or abbreviation for the project, and the rest is up to the project. Third, it should be specified, up front, that this is the (only) namespace the project can release code for. This might be controversial. I think some have always assumed this to be the case. But, according to EPL License people can make modifications to source and redistribute it ... so for example, someone could provide a whole new "org.eclipse.emf" package at sourceforge, but this "EDP rule" would say they can not do so at the Eclipse Foundation itself. IMHO, that is ok and good, since, IMHO, the Eclipse Foundation should present a unified face to the rest of the world, even if places like sourceforge might have a different implementation of "org.eclipse.emf...". And also, practically speaking, there have been some nightmarish conflicts resulting from the way Apache projects have "re-released" other Apache packages and I would think we'd want to avoid as much of that as possible for "official" Eclipse Foundation projects. (I have no idea what Apache's rules are about this ... and perhaps the cases I've seen were exceptions to the rules?) Given recent events, I'm sure even if people agree with the above three additions or clarifications to the EDP, the next question will be "well, how are exceptions handled". And for that, I'm not sure. If we need to specify an exception process, for cases where there is "overlap", I suspect it'd involve approval from the projects involved and the PMCs involved, and maybe even the Planning Council and Architecture Council (but, honestly, I think most "business" like this at Eclipse is project-to-project, so not sure the Councils need to be very involved approval (maybe just give advice, etc.). I should emphasize, while "solving" this problem in future EDP document, it should not be done in the spirit of effecting or controlling what happens with the current ObjectTeam case ... that should be handled separately ... I really am opening this simply as a possible improvement for the future. But ... I do think it needs to be officially "settled". If I am wrong, and projects are free to re-release other projects (patched) code, I'm sure there's some in WTP that would be tempted to have their own version of EMF. :) That is, more seriously, setting a precedent might open a flood gate. Lastly, I'm also not sure what to do about current projects, as many of us don't follow the exact right rules, and while no one would ever suggest we break adopters by changing current ones, at some point, someone may want to have "in use" namespaces documented? Which would be a lot of work :( Thanks for considering these issues. Others opinions, clarifications, or additional issues would be most welcome.
See also http://wiki.eclipse.org/Naming_Conventions which say: 1) The first package name segment after org.eclipse is generally the subproject name, followed by the component name. 2) The plug-in namespace is managed hierarchically; do not create plug-in without prior approval from the owner of the enclosing namespace. For me this implies that a project must not use the namespace of another project - at least not without prior approval.
(In reply to comment #1) > ... > For me this implies that a project must not use the namespace of another > project - at least not without prior approval. This makes sense to me. Projects should own their namespaces. Any other use of the namespace requires the pre-approval of the owner. I would also argue that, approval could be withdrawn at a later date. In other words, working in some other project's namespace is *risky*, and should be avoided if it is at all possible.
Just to be clear, are we talking about the namespace of the packages, bundles, or both? I know there is a convention by which we link the two namespaces (bundle org.eclipse.foo likely has a package org.eclipse.foo). But it is entirely possible to include the package org.eclipse.jdt in that foo bundle.
For reference, I raised this with the arch council a few years ago. The conclusion at the time was that the EMO controls the bundle/package namespace, based on the naming guidelines on the wiki: http://dev.eclipse.org/mhonarc/lists/eclipse.org-architecture-council/msg00338.html There is a bug open against the EMO to provide tools to check/enforce this: https://bugs.eclipse.org/bugs/show_bug.cgi?id=219259 I think the most important aspect is that a project should be made aware when others are using their namespace. Declaring the intended namespace in review docuware is good, but not sufficient. Most of us don't have time to read every single review that comes out to make sure we aren't affected. I suggest wording like "exceptions must be approved by the PMC or project lead whose namespace is being used." If approval is considered too much, then exceptions should at least be acknowledged by the affeced PMC, to record that they are aware of the usage. In some cases there might be technical approaches available to avoid the namespace reuse, or other approaches such as hosting the forked code within the originating project.
(In reply to comment #3) > Just to be clear, are we talking about the namespace of the packages, bundles, > or both? I know there is a convention by which we link the two namespaces > (bundle org.eclipse.foo likely has a package org.eclipse.foo). But it is > entirely possible to include the package org.eclipse.jdt in that foo bundle. Yes, that could for example happen when splitting things. But it should only be done with approval from the PMC that owns that package name (e.g. org.eclipse.jdt).
Assiging to AC for their input. I don't think this should be entrenced in the EDP as we've taken effort to avoid language/environment-specific language. I do, however, agree that projects should take ownership of their namespace and that we should consider adding some words to the Naming Conventions wiki page suggesting that the rules outlined for Java package names be applied to bundle names. I'm inclined to leave the use of the word component as I don't believe that there is any specific connection to the old EDP concept of components.
The other comments in this bug have been a little inconsistent regarding the cardinalities of the project <--> namespace(s) relationship. I know that some projects (including mine) currently "own" multiple namespaces and I hope that continues to be possible as long as they're unique.
(In reply to comment #7) > The other comments in this bug have been a little inconsistent regarding the > cardinalities of the project <--> namespace(s) relationship. I know that > some projects (including mine) currently "own" multiple namespaces and I > hope that continues to be possible as long as they're unique. I believe that multiple namespaces is fine, but should be considered an exception rather than a rule.
So, what--if anything--should we include in the EDP? I can add a line/paragraph in section 4.2 "Code and Releases" e.g. "Namespaces are assigned to a project by the EMO. All project source code must be organized in the assigned namespaces." or "Project source code must be organized in namespaces assigned to the project by the EMO." Do we need to make explicit that the project should work with their PMC to petition the EMO to assign additional namespaces, or is that reasonably implied?
(In reply to Wayne Beaton from comment #9) I think your first direction is fine ... and you know how I like to be wordy ... I'd expand to say following ... but, please edit, so its shorter and makes sense in context: = = = = = = Namespaces are assigned to a project by the EMO. All project source code must be organized in the assigned namespaces and projects can only release code under their own name space (that is, they can not releases another Eclipse project's code). The usual form is org.eclipse.<project>.[*] Projects should work with their PMCs and the EMO if there are exceptions to this rule, and with their mentors and PMC if there are questions about what should be used after the <project> name. = = = = =
There were some underlying assumptions that I haven't articulated. Eclipse has moved beyond everything being Java/OSGi. We can't bake a Java-specific in the EDP. With this restriction, I don't think that we can say much more than what I proposed in Comment #9. We can then use a policy document to provide language-specific guidance. http://wiki.eclipse.org/Development_Resources/HOWTO/The_Eclipse_Code_Namespace_Policy How about: -- Namespaces are assigned to a project by the EMO. All project source code must be organized in the assigned namespaces and projects can only release code under their own name space (that is, they cannot infringe on another Eclipse project's namespace). Projects should work with their PMCs and the EMO to request exceptions to this rule, and with their mentors and PMC if there are questions regarding the use of the namespace. --
(In reply to Wayne Beaton from comment #11) > > -- > Namespaces are assigned to a project by the EMO. All project source code > must be organized in the assigned namespaces and projects can only release > code under their own name space (that is, they cannot infringe on another > Eclipse project's namespace). Projects should work with their PMCs and the > EMO to request exceptions to this rule, and with their mentors and PMC if > there are questions regarding the use of the namespace. > -- Sounds perfect to me.
(In reply to Wayne Beaton from comment #9) > Do we need to make explicit that the project should work with their PMC to > petition the EMO to assign additional namespaces, or is that reasonably > implied? I think a GO from the PMC won't hurt. (In reply to David Williams from comment #12) > (In reply to Wayne Beaton from comment #11) > > > > > -- > > Namespaces are assigned to a project by the EMO. All project source code > > must be organized in the assigned namespaces and projects can only release > > code under their own name space (that is, they cannot infringe on another > > Eclipse project's namespace). Projects should work with their PMCs and the > > EMO to request exceptions to this rule, and with their mentors and PMC if > > there are questions regarding the use of the namespace. > > -- > > Sounds perfect to me. +1.
In your blog you asked for input on similar conventions for JavaScript. I'm no JavaScript expert but we have wrestled with this in Orion for a couple of years now. The only namespace that matters in browser-side JavaScript is the DOM of each web page. JavaScript can pollute the DOM through use of global or implicitly defined variables. This creates risk of collision with other scripts within the DOM namespace. The simple rule we've arrived at in Orion is: "Never use globals." If you don't use globals all namespace concerns go away. Instead each script defines only local variables. An AMD loader [1] is used to export and bind these variables to local variables in other scripts and no globals are ever created. [1] https://github.com/amdjs/amdjs-api/wiki/AMD In the Node.js world module names need to be unique if you want do be able to install them via NPM. There are no established conventions in that world yet on how to name modules to avoid collisions but since just about everyone registers their modules with NPM, the only real rule is whoever registers a module name first wins. I think this community will eventually grow up and realize it needs some better naming conventions but that hasn't happened yet.
I've added the namespace statement to the draft document. http://eclipse.org/projects/dev_process/development_process_2014/#4_2_Code_and_Releases (I've pushed the change, but it's not appeared on the public site yet) I'm going to mark this bug as FIXED. If we decide to modify this inclusion during draft review, we can either reopen this bug or create a new one.
