[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] Practice makes perfect


The files for #1 have been deleted....  folders are still there, I'll add the "obsolete.txt" file..

Thanks - Chuck

Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email:  cbridgha@xxxxxxxxxx
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

To
wtp-dev@xxxxxxxxxxx
cc
Subject
[wtp-dev] Practice makes perfect






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").


org.eclipse.jst.j2ee.jca.ui

org.eclipse.jst.servlet.ui


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.


org.eclipse.wst.xsd.editor, and
org.eclipse.wst.wsdl.editor


4. Just to pick on one example, which is clean enough to make a good example (that's a complement),
It seems
org.eclipse.wst.xml.validation

could be a "model only" plugin except for one little "validate action".
Couldn't that action be moved to the xml.ui plugin, so xml.validation is purely model-side?



5.  The following plugins still have Eclipse flagged "unused imports"

org.eclipse.wst.validation

org.eclipse.wst.wsdl

org.eclipse.wst.wsdl.editor

org.eclipse.wst.xsd.editor


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 anyway).
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 study.
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.