Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "WTP CVS Restructuring"
(→WST and JST) |
(→Principles) |
||
| Line 76: | Line 76: | ||
The above examples show a few points related to this restructuring. | The above examples show a few points related to this restructuring. | ||
| − | # The best top-level name should | + | # The best top-level directory name should be similar to what the access group name will be: toplevel.subproject.component-subcomponent. We do not currently have components controlled by access restrictions, so I think we in webtools need only define the toplevel.subproject groups for now, hence the top level directories can be simply the subproject name, since 'webtools' is in its own cvs repository, so 'webtools' does not need to be part of the directory name. Also note that component and subcomponents can be added in the future, but best to start off with simplest, and add detail later, when needed. |
| − | # Thus, everyone in a | + | # Thus, everyone in a particular Eclipse subproject can be associated with a top level webtools directory, and automatically get access to everything in that directory, without the need for more complicated administration. |
| − | # Note the previous "assembly" features and plugins will be become part of releng subproject. These are the | + | # Note the previous "assembly" features and plugins will be become part of releng subproject. These are the Eclipse product plugins, and the features that define our builds. Each project will be responsible for their own features delivered to WTP (currently called the build-component features). |
| − | # | + | # Note the example in source editing where what used to be directories, xml and xsd, are no longer distinguished by cvs directories, but all the plugins flattened under sourceediting/plugins. |
## Conceptually and architecturally, xml and xsd could still be called 'components' but they do not have separate access control, so it's a bit overkill (and ultimately restrictive) to define them in separate cvs directories. | ## Conceptually and architecturally, xml and xsd could still be called 'components' but they do not have separate access control, so it's a bit overkill (and ultimately restrictive) to define them in separate cvs directories. | ||
| − | ## Note that the "access control" for components such as xml and xsd is (still) social in nature. Legally, in | + | ## Note that the "access control" for components such as xml and xsd is (still) social in nature. Legally, and in principle, anyone in the source editing project could change the code there, but in practice, there are individuals or small teams that normally do. Others, even in the same project, usually would attach a patch to a bugzilla if they wanted one of those experts to review and commit the code. |
| − | + | ||
==Detailed Listings== | ==Detailed Listings== | ||
Revision as of 23:55, 15 October 2007
Contents
Purpose
In an effort to standardized groups on dev.eclipse.org especially in light of our recent WTP Refactoring, the page is to propose and document how to restructure our CVS directories, so their access can be managed by associating directories with Unix Groups. In principle, we could leave all the directories the way they are now, and just carefully assign the Unix groups on a directory by directory bases ... but, this would be very complicated, error prone, and hard to scale in the future.
The document will start by focusing on the old wst and jst directories, as they need the most work, and other subprojects addressed later, towards the end of this proposal.
WST and JST
These initial WTP projects were created with the following sort of hierarchy -- abbreviated and idealized here to simplify explaining the principles of the restructuring.
wst
components
assembly
features
plugins
server
features
plugins
tests
xml
features
plugins
org.eclipse.wst.xml.core
org.eclipse.wst.xml.ui
tests
examples
development
thirdparty
xsd
plugins
org.eclipse.wst.xsd.core
org.eclipse.wst.xsd.ui
tests
The new proposed structure would look as follows
webtools.maps
releng.common
releng.sourceediting
releng.servertools
releng.webservices
releng.datatools
releng.jeetools
releng.ejbtools
releng.dali
releng.jsf
webtools.releng
features
plugins
org.eclipse.wtp.releng
org.eclipse.wtp.releng.tests
org.eclipse.wtp.releng.webupdatesite
releng.builder
releng.control
releng.wtpbuilder
releng.wtptools
working
sourceediting
features
plugins
org.eclipse.wst.xml.core
org.eclipse.wst.xml.ui
org.eclipse.wst.xsd.core
org.eclipse.wst.xsd.ui
tests
examples
development
thirdparty
servertools
features
plugins
tests
Principles
The above examples show a few points related to this restructuring.
- The best top-level directory name should be similar to what the access group name will be: toplevel.subproject.component-subcomponent. We do not currently have components controlled by access restrictions, so I think we in webtools need only define the toplevel.subproject groups for now, hence the top level directories can be simply the subproject name, since 'webtools' is in its own cvs repository, so 'webtools' does not need to be part of the directory name. Also note that component and subcomponents can be added in the future, but best to start off with simplest, and add detail later, when needed.
- Thus, everyone in a particular Eclipse subproject can be associated with a top level webtools directory, and automatically get access to everything in that directory, without the need for more complicated administration.
- Note the previous "assembly" features and plugins will be become part of releng subproject. These are the Eclipse product plugins, and the features that define our builds. Each project will be responsible for their own features delivered to WTP (currently called the build-component features).
- Note the example in source editing where what used to be directories, xml and xsd, are no longer distinguished by cvs directories, but all the plugins flattened under sourceediting/plugins.
- Conceptually and architecturally, xml and xsd could still be called 'components' but they do not have separate access control, so it's a bit overkill (and ultimately restrictive) to define them in separate cvs directories.
- Note that the "access control" for components such as xml and xsd is (still) social in nature. Legally, and in principle, anyone in the source editing project could change the code there, but in practice, there are individuals or small teams that normally do. Others, even in the same project, usually would attach a patch to a bugzilla if they wanted one of those experts to review and commit the code.
Detailed Listings
The following are the detailed listing of directories in what would be their new structure.
- webtools.common
- webtools.servertools
- webtools.datatools
- webtools.sourceediting
- webtools.webservices
- webtools.jeetools
- webtools.ejbtools
- webtools.releng
To Do Items
- change maps to use module names only, to divide up the change, so once restructuring is done, only the modules file has to be changed, and builds will keep working. Note: there are probably some, JSF or JPA files that will have to be added to modules file. (Remember, any old builds, if they had to be re-created, would have to be changed, but that's unlikely to be needed).
- try using CVS snapshots, on local, test machines with some move scripts to test to be sure we've accounted for everything.
Reference and Notes
Committers can see our current CVS directories
/home/data/cvs/webtools
Snapshots of our CVS can be obtained at
http://archive.eclipse.org/arch/