Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] new map files

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.

Back to the top