[wtp-dev] Who's been monkeying with our CVS Modules?

[David M Williams <david_williams@xxxxxxxxxx>]

Ok, it was me. 

As I mentioned in our status
call, I've defined some CVS modules
(in the 'modules' file of CVSROOT)
that will change the "Repository
Exploring" view of webtools,
and some behavior. All for the better. So
now instead of 10 or so "modules"
in our webtools repository view,
there's about 315! One for each
plugin and feature in the build (in
the map files). So, on the one
hand, 300 top level directories is too
many and too confusing to some,
but ...

1. Some people have commented
that its too hard to find a plugin or
feature they want to load, so,
this is an attempt to improve on that.
[1]  We currently can only
define this at the "top" level, though
eventually I'd like to define
alias for our "component features" as
well, so we can represent our
"feature hierarchy", but will wait to get
a response on a "tree view"
bug. [2]

2. Most important (the reason
I did this now), the "Refresh Branches"
operation of the repository will
now work to actually find all of our
projects that have been branched
for R1_5_maintenance!


A few "policy" notes:


I propose we keep these modules
defined to always be what ever is in
our build. We can soon add JSF
if they'd like, if this seems to
work for everyone, but so far
have only WST and JST.

This means there will always
be "deeper" directories that won't be
represented at the top level
.. these might be old ones, some of those
"development" ones
some of us have created for temporary or tools
work. I propose we leave these
"deep" and hidden from casual exploring. 

Any build "scripts",
etc., should continue to refer to the "full"
version of the repository location,
since the module "aliases" can
change or be removed as the project
changes over time. (but the full
cvs repository names won't change).

Three odd cases to watch out
for: 

The equinox servlet project that
is in our map file is not 
representable this way, since
it comes from another project
So, you can't "check out"
to your workspace, except from its 
home project. Or, better, get
that jar from your target. [3]

We have two (high level) projects
where the feature and plugin IDs are
the same. org.eclipse.wst and
org.eclipse.jst. 
This is ok in map files, but
can't work in the modules file. 
So, I added ".feature"
the module name for the features, and 
having the model name different
from its ID will forever be 
confusing (from previous experience
:) 

I just thought I'd write all
this down for reference and explanation. 
So, let me know if problems or
comments. 

I'm hoping this will help us
keep straight on which plugin/features 
have been branched and which
are continuing head-only development.

Thanks, 





[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=119273

[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=152818

[3] http://download.eclipse.org/eclipse/equinox/