The files for #1 have been deleted....
folders are still there, I'll add the "obsolete.txt"
Thanks - Chuck
Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Phone: 919-254-1848 (T/L: 444)
David M Williams/Raleigh/IBM@IBMUS Sent by: wtp-dev-admin@xxxxxxxxxxx
11/18/2004 11:39 PM
Please respond to
[wtp-dev] Practice makes
Looking at the recent I-build and cvs contents, I thought I'd make a few
observations here on the mailing list, instead of opening bugzillas ...
so hopefully we can all profit from a little "group discussion"
and a little "group learning". Eventually, as these types
of things become isolated issues, I'll just open bugs or feature requests.
[And, I know there's already plans and work going on in some areas, like
getting junit tests in the builds, so am just hoping notes like this raises
our project awareness of some of these "quality" issues, its
not to lay blame or cause embarrassment .. well, not too much anyway :)
1. Looks like following two plugins were checked in to CVS with a /bin
directory before bin was added to .cvsignore file. Remember, once its there
in CVS, you can't ignore it. Please correct, otherwise it always shows
up as a "changed project". (I believe there is a way ... turn
off autobuild, remove bin from cvsignore, delete bin, synchronize so bin
is 'deleted' from repository, then add to cvsignore before regenerating
bin, commit cvsignore. (I don't know about current Eclipse, but at this
point you might have to delete whole project from workspace and re-checkout
for it to "take").
2. several plugins (too many to list) have their jars compiled to a 'runtime'
directory. There's no strict problem with that, and I guess its not explicitly
covered by other written conventions, but I know I find it a little confusing
("runtime" meaning something to do with servers, external binaries,
etc). I think the Eclipse convention is to have the jar in the "root"
of the plugin, unless someone knows of some other pro or con, I'll suggest
we have our compiled jars in root of plugin, and reserve "runtime"
to contain special binary jars that come from some other source that happen
to be required by that plugin.
3. I think the following should pretty clearly be "ui" instead
of "editor", according to our naming conventions.
4. Just to pick on one example, which is clean enough to make a good example
(that's a complement),
could be a "model only" plugin except for one little "validate
Couldn't that action be moved to the xml.ui plugin, so xml.validation is
5. The following plugins still have Eclipse flagged "unused
But, I'll admit, I noticed in the build logs there were many others, including
some of my own teams plugins, that had unused imports flagged, even though
not flagged in Eclipse. Upon investigation, I see the reason for that is
that those "imports" are used only for JavaDoc. Eclipse won't
call those an error, though the
build compiler will. I believe the only cure for this is to use fully qualified
name in JavaDoc, when its not otherwise needed for an 'import'.
(In some cases, this problem might just be due to "old" javadoc
I'll update our "practices" document with the convention to use
fully qualified names in javadoc. You may need to "manually"
check the build logs,
and "manually" fix cases only flagged there. Current versions
of Eclipse will automatically use the fully qualified name in that context
if Eclipse tools used (Alt-Shift-J).
It is important to cleanup our compiler warnings so it'll be obvious when
there's a warning we should heed. As it is, there's too many to look at
and some of them might be indicating something important.
6. And, not to leave out one of my components, I know sse.core indirectly
pre-reqs SWT, but that's known issue with FormatStratgy. Kit Lo is
looking into that
(we think its either been fixed in base Eclipse 3.1 (with alternative available),
or there's a fix in mind .. we will verify and follow though).
Keep in mind, this list is just scratches the surface from a few minutes
Please read http://www.eclipse.org/webtools/development/WTPDevelopmentPractice.html
and practice, practice, practice :)
I always fear notes like this will seem "negative" ... which
is not my intent. In fact, I'm very happy we've finally got a recent (fairly)
clean I-build to look at, so these issues can be concretely discussed ...
so thanks and congratulations to everyone who helped make this build happen.