[wtp-dev] new map files

[David M Williams <david_williams@xxxxxxxxxx>]

I did update the map files as proposed
(very early) this morning and all seemed to go well. I'll make the following
observations, though. 

I did not implement Chris's suggestions
of having j2ee web services as a separate map file. If it proves problematic
we certainly can. But if/when we do, I like to be clear if 
that means the arch. doc. subsystems
should be changed, or if its just a "check in" convenience due
to separate teams? The arch. doc. subsystems should be changed, I think,

only if we think its conceptually correct
and actual possible client need to think of installing everything include
J2EE WebServices, but not installing J2EE EJB's (or JCA's). 

There was a compile problem 
in the "test build" (see N20050204
build)
in org.eclipse.wst.common.emfworkbench.integration
but pretty sure that's not a result
of the map file changes ... since was broken in my dev. env. too. 

I did notice one "dependancy"
problem. In a fresh workspace, we should be able to select map files one
by one, and load them one by one in 
dependancy order ... eg. wst-common
first, wst-xml second, etc.   This all went well except for jst-j2ee-basic
... it seems in depends on some 
things in jst-j2ee-advanced .... not
sure If I split it up wrong, or if there's more refactoring planned for
the components involved. Chuck, can you check?

I'm assuming (and suggesting) that "tests"
and "performance tests" all go in the same correspond 'test'
map file, but I may have mix together a wst common test plugin with a wst
common test feature? (Jeffrey, please propose correction if needed). 

Once I saw the whole list of map files
listed, I saw they are much read better as a sorted list if 'test' came
at the end of the name, instead of right after the sub-project name.
(this did change some existing test
ones, though). 

minor point: I also changed the cvs
type to "text" (ascii-ko) .. instead of binary ... I think that
allows some improvements in merging, though that need should be rare, 
but does restrict to ascii characters,
so if anyone develops on non-western/latin locale machines, please use
care that all the special characters like '@' are correctly maintained
in CVS
(I'm pretty sure they will be, but just
not positive). 

From here on, component leads can change
or create new map files as needed (following the same scheme and logic,
of course, for consistency) but a note here might be nice 
when you do.  For component teams
that share a subsystem, its business as usual, only hopefully less sharing
now. 

Tip: The releng 'release' function should
work the same, only now you can better narrow in on your specific map files
needed, and its actually a nice "sanity check" to over select
(your components) projects and leave the "release only if changed"
box checked, so you'll immediately see (on next wizard page) in projects
that changed in HEAD which you didn't expect to. 

Tip: with the releng plugin installed,
it should work better now  to "load released projects" to
get the latest (released) code loaded from CVS for only those subsystems
you depend on. (for code you are working on, though, you still need to
check out directly from CVS to have the 'HEAD' version, or else you'll
make changes, then find you can not check in).

Thanks all.