Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] Who's been monkeying with our CVS Modules?

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.





Back to the top