[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[wtp-dev] Re: Javadoc generation
|
Becareful with that approach as it includes alot more information than you
actually need -- particularly the paths of your *.jar files of your
specific Eclipse install.
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
Friday, February 18, 2005 2:29 PM
To: Michael Elder/Cambridge/IBM@IBMUS
cc: Arthur Ryman/Toronto/IBM@IBMCA, Chris Brealey/Toronto/IBM@IBMCA, Chuck
Bridgham/Raleigh/IBM@IBMUS, Craig Salter/Toronto/IBM@IBMCA, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jason A Sholl/Raleigh/IBM@IBMUS, Jeffrey
Liu/Toronto/IBM@IBMCA, Kathy Chan/Toronto/IBM@IBMCA, Keith
Chong/Toronto/IBM@IBMCA, Kit Lo/Raleigh/IBM@IBMUS, Lawrence E
Dunnell/Redmond/IBM@IBMUS, Lawrence Mandel/Toronto/IBM@IBMCA, Michael
Elder/Cambridge/IBM@IBMUS, Nitin Dahyabhai/Raleigh/IBM@IBMUS, Phillip
Avery/Raleigh/IBM@IBMUS, Sheila Sholars/Santa Teresa/IBM@IBMUS, Timothy
Deboer/Toronto/IBM@IBMCA, Vijay Bhadriraju/Raleigh/IBM@IBMUS
From: Amy Wu/Raleigh/IBM@IBMUS
Subject: Re: Javadoc generation
For the lazy, to get the info that needs to be included in the
javadoc.properties file, you could go to File->Export->Javadoc and use the
wizard to select everything you want to JavaDoc for. Then on the last page
of the wizard check "Save the settings of this Javadoc export as an Ant
script" The only downside is that you will have to generate the javadoc,
you can't just get the ant script (though that might be good because you
can see what your javadoc will look like)
______________________________
Amy Wu
Structured Source Editor
919.254.0299, T/L 444.0299
amywu@xxxxxxxxxx
Michael Elder/Cambridge/IBM
Michael Elder/Cambridge/IBM
02/18/2005 01:57 PM
To
Michael Elder/Cambridge/IBM@IBMUS
cc
Arthur Ryman/Toronto/IBM@IBMCA, Chris Brealey/Toronto/IBM@IBMCA, Chuck
Bridgham/Raleigh/IBM@IBMUS, Craig Salter/Toronto/IBM@IBMCA, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jason A Sholl/Raleigh/IBM@IBMUS, Jeffrey
Liu/Toronto/IBM@IBMCA, Kathy Chan/Toronto/IBM@IBMCA, Keith
Chong/Toronto/IBM@IBMCA, Kit Lo/Raleigh/IBM@IBMUS, Lawrence E
Dunnell/Redmond/IBM@IBMUS, Nitin Dahyabhai/Raleigh/IBM@IBMUS, Phillip
Avery/Raleigh/IBM@IBMUS, Sheila Sholars/Santa Teresa/IBM@IBMUS, Timothy
Deboer/Toronto/IBM@IBMCA, Vijay Bhadriraju/Raleigh/IBM@IBMUS, Amy
Wu/Raleigh/IBM@IBMUS, Lawrence Mandel/Toronto/IBM@IBMCA
Subject
Re: Javadoc generation
Also, there's room for descriptions of the components in the WST subproject
on the overview page. The overview page is taken from
org.eclipse.wst.doc.isv/api-overview/overview.xml. Would component owners
please update these descriptions? Thanks!
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
Friday, February 18, 2005 1:54 PM
To: Lawrence Mandel/Toronto/IBM@IBMCA
cc: Arthur Ryman/Toronto/IBM@IBMCA, Chris Brealey/Toronto/IBM@IBMCA, Chuck
Bridgham/Raleigh/IBM@IBMUS, Craig Salter/Toronto/IBM@IBMCA, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jason A Sholl/Raleigh/IBM@IBMUS, Jeffrey
Liu/Toronto/IBM@IBMCA, Kathy Chan/Toronto/IBM@IBMCA, Keith
Chong/Toronto/IBM@IBMCA, Kit Lo/Raleigh/IBM@IBMUS, Lawrence E
Dunnell/Redmond/IBM@IBMUS, Nitin Dahyabhai/Raleigh/IBM@IBMUS, Phillip
Avery/Raleigh/IBM@IBMUS, Sheila Sholars/Santa Teresa/IBM@IBMUS, Timothy
Deboer/Toronto/IBM@IBMCA, Vijay Bhadriraju/Raleigh/IBM@IBMUS, Amy
Wu/Raleigh/IBM@IBMUS
From: Michael Elder/Cambridge/IBM@IBMUS
Subject: Re: Javadoc generation
Extended Team:
There is a new directory under wst/components named "doc" wherein the
new "org.eclipse.wst.doc.isv" plugin lives. This plugin has an Ant script
named "javadoc.xml" that handles the details of building the Javdoc for all
WST components.
To add your API to the generation process, update the
org.eclipse.wst.doc.isv/javadoc.properties file to include your (1) source
folder container(s) for API, (2) API packages to document, and (3) the bin
directory of the plugin. Each of these paths assumes that
org.eclipse.wst.doc.isv is peer to all other plugins that contain API.
To create a package description file, begin with
org.eclipse.wst.doc.isv/template_package.xml and put it in your API package
as "package.xml". The first sentence should be a general summary of the
package -- this will appear on the overview page beside the package name.
This file has some standard templates that have been used through the J2EE
doc process, and we would encourage other teams to adopt these for
consistency. There is a comment in the file as well that must be removed
before XSLT will run on the file. The comment includes information about
how to link images directly into the Javadoc.
If you'd like to see an example of how this is done, see
wst/common/org.eclipse.wst.common.modulecore/modulecore/org.eclipse.wst.common.modulecore.
The API are available on the website now
(http://www.eclipse.org/webtools/wst/api/index.html) but I'm not currently
anticipating that this be a long term solution. This will allow us to make
them available to users though until the build plan is fully hammered out.
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
Friday, February 18, 2005 1:08 PM
To: Amy Wu/Raleigh/IBM@IBMUS
cc: Arthur Ryman/Toronto/IBM@IBMCA, Chris Brealey/Toronto/IBM@IBMCA, Chuck
Bridgham/Raleigh/IBM@IBMUS, Craig Salter/Toronto/IBM@IBMCA, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jason A Sholl/Raleigh/IBM@IBMUS, Jeffrey
Liu/Toronto/IBM@IBMCA, Kathy Chan/Toronto/IBM@IBMCA, Keith
Chong/Toronto/IBM@IBMCA, Kit Lo/Raleigh/IBM@IBMUS, Lawrence E
Dunnell/Redmond/IBM@IBMUS, Michael Elder/Cambridge/IBM@IBMUS, Nitin
Dahyabhai/Raleigh/IBM@IBMUS, Phillip Avery/Raleigh/IBM@IBMUS, Sheila
Sholars/Santa Teresa/IBM@IBMUS, Timothy Deboer/Toronto/IBM@IBMCA, Vijay
Bhadriraju/Raleigh/IBM@IBMUS
From: Lawrence Mandel/Toronto/IBM@IBMCA
Subject: Re: Javadoc generation
Amy,
I think this is the correct way to do things. We will have one help plugin
for WST and one for JST and will have one JavaDoc plugin for WST and one
for JST.
Is this what you meant?
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
Amy Wu/Raleigh/IBM@IBMUS
Amy Wu/Raleigh/IBM@IBMUS
02/18/2005 11:59 AM
To
Lawrence Mandel/Toronto/IBM@IBMCA
cc
Arthur Ryman/Toronto/IBM@IBMCA, Chris Brealey/Toronto/IBM@IBMCA, Chuck
Bridgham/Raleigh/IBM@IBMUS, Craig Salter/Toronto/IBM@IBMCA, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jason A Sholl/Raleigh/IBM@IBMUS, Jeffrey
Liu/Toronto/IBM@IBMCA, Kathy Chan/Toronto/IBM@IBMCA, Keith
Chong/Toronto/IBM@IBMCA, Kit Lo/Raleigh/IBM@IBMUS, Lawrence E
Dunnell/Redmond/IBM@IBMUS, Michael Elder/Cambridge/IBM@IBMUS, Nitin
Dahyabhai/Raleigh/IBM@IBMUS, Phillip Avery/Raleigh/IBM@IBMUS, Sheila
Sholars/Santa Teresa/IBM@IBMUS, Timothy Deboer/Toronto/IBM@IBMCA, Vijay
Bhadriraju/Raleigh/IBM@IBMUS
Subject
Re: Javadoc generation(Document link: Lawrence Mandel)
In regards to:
One more question that I hope you can clarify. Are the doc plugins are
really just 'development time' plugins or are these 'runtime' plugins
(that be installed under eclipse/plugins on the end user's machine).
I'm curious to understand how these plugins relate to the 'end user'
documentation plugins (which were traditionally provided to us by the ID
folks). Are these one in the same?
My thoughts are that ID handles the 'end user' documentation..documentation
telling users how to use WTP. Developer documention, telling clients how
to develop on top of WTP is done by WTP developers. They should be
separate plugins. If you go to the eclipse download site and look at the
description for "Platform Runtime Binary" it says:
These drops contain only the Eclipse Platform with user documentation and
no source **and no programmer documentation**. The Java development tools
and Plug-in Development Environment are NOT included. You can use these
drops to help you package your tool plug-ins for redistribution when you
don't want to ship the entire SDK.
______________________________
Amy Wu
Structured Source Editor
919.254.0299, T/L 444.0299
amywu@xxxxxxxxxx
Lawrence Mandel/Toronto/IBM@IBMCA
Lawrence Mandel/Toronto/IBM@IBMCA
02/17/2005 05:32 PM
To
Michael Elder/Cambridge/IBM@IBMUS
cc
Amy Wu/Raleigh/IBM@IBMUS, Arthur Ryman/Toronto/IBM@IBMCA, Chris
Brealey/Toronto/IBM@IBMCA, Chuck Bridgham/Raleigh/IBM@IBMUS, Craig
Salter/Toronto/IBM@IBMCA, David M Williams/Raleigh/IBM@IBMUS, Der Ping
Chou/Redmond/IBM@IBMUS, Ella Belisario/Toronto/IBM@IBMCA, Elson
Yuen/Toronto/IBM@IBMCA, Geni Hutton/Toronto/IBM@IBMCA, Jason A
Sholl/Raleigh/IBM@IBMUS, Jeffrey Liu/Toronto/IBM@IBMCA, Kathy
Chan/Toronto/IBM@IBMCA, Keith Chong/Toronto/IBM@IBMCA, Kit
Lo/Raleigh/IBM@IBMUS, Lawrence E Dunnell/Redmond/IBM@IBMUS, Nitin
Dahyabhai/Raleigh/IBM@IBMUS, Phillip Avery/Raleigh/IBM@IBMUS, Sheila
Sholars/Santa Teresa/IBM@IBMUS, Timothy Deboer/Toronto/IBM@IBMCA, Vijay
Bhadriraju/Raleigh/IBM@IBMUS
Subject
Re: Javadoc generation(Document link: Amy Wu)
Coming from an ID standpoint, having one plugin per component such as
wst.server, jst.server, wst.common, jst.common, etc. will be too many help
plugins. We need to try and keep the number of help plugins down as
upstream products will have hundreds of help plugins and this will add to
their bloat. We'll probably be ok if we can stick to a component level in
WST such as XML, Web services, Data, Internet,etc. and have one JST help
plugin unless there are cases where we want to distribute a subset of JST
functionality.
Will WTP support vendors grabbing different pieces of functionality on a
CVS folder component level?
Will WTP have more packages available for download besides WTP and WST,
such as WSVT, XML, etc.?
Is it acceptable/understood that WTP will only provide granular help and
docs at the level that we provide downloadable packages? (ie. Do we need to
keep the help and docs fine grained to allow vendors to pick-up a small
piece of WTP functionality and only the help and docs that go with it as
opposed to a larger set of help and docs?)
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@xxxxxxxxxx
Michael Elder/Cambridge/IBM@IBMUS
Michael Elder/Cambridge/IBM@IBMUS
02/17/2005 04:34 PM
To
Craig Salter/Toronto/IBM@IBMCA
cc
Amy Wu/Raleigh/IBM@IBMUS, Arthur Ryman/Toronto/IBM@IBMCA, Chris
Brealey/Toronto/IBM@IBMCA, Chuck Bridgham/Raleigh/IBM@IBMUS, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jason A Sholl/Raleigh/IBM@IBMUS, Jeffrey
Liu/Toronto/IBM@IBMCA, Kathy Chan/Toronto/IBM@IBMCA, Keith
Chong/Toronto/IBM@IBMCA, Kit Lo/Raleigh/IBM@IBMUS, Lawrence E
Dunnell/Redmond/IBM@IBMUS, Lawrence Mandel/Toronto/IBM@IBMCA, Nitin
Dahyabhai/Raleigh/IBM@IBMUS, Phillip Avery/Raleigh/IBM@IBMUS, Sheila
Sholars/Santa Teresa/IBM@IBMUS, Timothy Deboer/Toronto/IBM@IBMCA, Vijay
Bhadriraju/Raleigh/IBM@IBMUS
Subject
Re: Javadoc generation
Hi Craig,
I'm not familiar with the ID process, so I can't say for sure
exactly. We're looking for a solution that will get us off the ground and
make our documentation available to our consumers in a coherent, consistent
form. We haven't discussed much how this documentation will be distributed
in an end-user product. Perhaps we can integrate these into the help
system.
Does anyone have any thoughts on this?
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
Thursday, February 17, 2005 4:29 PM
To: Michael Elder/Cambridge/IBM@IBMUS
cc: Amy Wu/Raleigh/IBM@IBMUS, Arthur Ryman/Toronto/IBM@IBMCA, Chris
Brealey/Toronto/IBM@IBMCA, Chuck Bridgham/Raleigh/IBM@IBMUS, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jason A Sholl/Raleigh/IBM@IBMUS, Jeffrey
Liu/Toronto/IBM@IBMCA, Kathy Chan/Toronto/IBM@IBMCA, Keith
Chong/Toronto/IBM@IBMCA, Kit Lo/Raleigh/IBM@IBMUS, Lawrence E
Dunnell/Redmond/IBM@IBMUS, Lawrence Mandel/Toronto/IBM@IBMCA, Nitin
Dahyabhai/Raleigh/IBM@IBMUS, Phillip Avery/Raleigh/IBM@IBMUS, Sheila
Sholars/Santa Teresa/IBM@IBMUS, Timothy Deboer/Toronto/IBM@IBMCA, Vijay
Bhadriraju/Raleigh/IBM@IBMUS
From: Craig Salter/Toronto/IBM@IBMCA
Subject: Re: Javadoc generation
Michael,
Thanks for the additional description... I think that has helped to clarify
matters. I'm glad to see that the 'doc' plugins are being separated into
their own 'doc' folder.
One more question that I hope you can clarify. Are the doc plugins are
really just 'development time' plugins or are these 'runtime' plugins (that
be installed under eclipse/plugins on the end user's machine). I'm curious
to understand how these plugins relate to the 'end user' documentation
plugins (which were traditionally provided to us by the ID folks). Are
these one in the same?
thanks
Craig
Craig Salter
Rational Studio XML Web Services
Internal Mail: D3/RY6/8200 /MKM
Phone: (905) 413-3918 TL: 969-3918 FAX: (905) 413-4920
Internet: csalter@xxxxxxxxxx Notes: Craig Salter/Toronto/IBM@IBMCA
Michael Elder/Cambridge/IBM@IBMUS
Michael Elder/Cambridge/IBM@IBMUS
02/17/2005 03:37 PM
To
Craig Salter/Toronto/IBM@IBMCA
cc
Amy Wu/Raleigh/IBM@IBMUS, Arthur Ryman/Toronto/IBM@IBMCA, Chris
Brealey/Toronto/IBM@IBMCA, Chuck Bridgham/Raleigh/IBM@IBMUS, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jeffrey Liu/Toronto/IBM@IBMCA, Kathy
Chan/Toronto/IBM@IBMCA, Keith Chong/Toronto/IBM@IBMCA, Kit
Lo/Raleigh/IBM@IBMUS, Lawrence E Dunnell/Redmond/IBM@IBMUS, Lawrence
Mandel/Toronto/IBM@IBMCA, Nitin Dahyabhai/Raleigh/IBM@IBMUS, Phillip
Avery/Raleigh/IBM@IBMUS, Sheila Sholars/Santa Teresa/IBM@IBMUS, Timothy
Deboer/Toronto/IBM@IBMCA, Vijay Bhadriraju/Raleigh/IBM@IBMUS, Jason A
Sholl/Raleigh/IBM@IBMUS
Subject
Re: Javadoc generation
I think the most appropriate approach is a single doc plugin per component
(one for wst.server, one for jst.servlet, etc). The reason I believe this
approach to be the correct one is to allow vendors to grab pieces of
functionality on a component level. I believe it was David Williams that
highlighted the need for this to me at some point several months ago when
we worked on the API for the M2 release.
I'd suggest that information relevant to the javadoc generation process be
pushed into a new "doc" plugin with the following organization in the repo:
<subproject>/
components/
<comp1>/
development/
plugins/
test/
doc/
org.eclipse.<subproj>.<comp1>.doc/
<comp2>/
development/
plugins/
test/
doc/
org.eclipse.<subproj>.<comp2>.doc/
...
One way to do this might be to setup the build.xml of these *.doc plugins
to just generate javadoc into a doc/ or api/ directory within the
respective plugin. Perhaps then use a feature to build the documentation,
and then drop all of the built *.doc plugins in a separate dist from the
download page when new builds are published.
Within each development plugin, and within each API package, component
owners would be required to supply a package.xml file that conformed to a
format similar to that of the website. The build.xml of the documentation
plugin could run an XSLT against these files before javadoc is generated,
and remove the generated version once javadoc completes.
Any images or resources referenced by the API Javadoc or the package.xml
files would need to be qualified up to the root. So if your package is
org.eclipse.foo.bar and you want to include an image (say a UML diagram) in
your package.xml, you would include an img tag with the following path:
<img src="../../../../overview/mydiagram.jpg" />
The actual "mydiagram.jpg" would be contained in a directory under the
documentation plugin, and when built, these resources would be copied into
a directory named "overview" relative to the location of the generated
Javadoc *.html. Note that "overview" is not an example, but a specific
requirement. Javadoc overview.html files typically refer to all of their
resources or images in a overview/ directory.
I think keeping most of this tightly integrated with the source code is the
correct approach because that's the approach of Javadoc API -- we put
comments and documentation right into the source code -- which should make
it more noticeable for us to maintain and limit the amount of extra junk
that users require to extend or use our APIs. One of the things that Jim
des Rivieres pointed out, developers tend not to read extra documentation
-- they use code assist. I think the closer to the code we can get the
docs, the better. Also the requirement for the package.html file being
contained by the API package is also a javadoc constraint.
Hope this answers your questions.
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
Thursday, February 17, 2005 3:18 PM
To: Michael Elder/Cambridge/IBM@IBMUS, Jason A Sholl/Raleigh/IBM@IBMUS
cc: Amy Wu/Raleigh/IBM@IBMUS, Arthur Ryman/Toronto/IBM@IBMCA, Chris
Brealey/Toronto/IBM@IBMCA, Chuck Bridgham/Raleigh/IBM@IBMUS, David M
Williams/Raleigh/IBM@IBMUS, Der Ping Chou/Redmond/IBM@IBMUS, Ella
Belisario/Toronto/IBM@IBMCA, Elson Yuen/Toronto/IBM@IBMCA, Geni
Hutton/Toronto/IBM@IBMCA, Jeffrey Liu/Toronto/IBM@IBMCA, Kathy
Chan/Toronto/IBM@IBMCA, Keith Chong/Toronto/IBM@IBMCA, Kit
Lo/Raleigh/IBM@IBMUS, Lawrence E Dunnell/Redmond/IBM@IBMUS, Lawrence
Mandel/Toronto/IBM@IBMCA, Nitin Dahyabhai/Raleigh/IBM@IBMUS, Phillip
Avery/Raleigh/IBM@IBMUS, Sheila Sholars/Santa Teresa/IBM@IBMUS, Timothy
Deboer/Toronto/IBM@IBMCA, Vijay Bhadriraju/Raleigh/IBM@IBMUS, Lawrence
Mandel/Toronto/IBM@IBMCA
From: Craig Salter/Toronto/IBM@IBMCA
Subject: Javadoc generation
Hi Michael ,
I was thinking about what you ware saying in the Telecon about generating
Javadoc for WTP. I think I heard you say that an additional 'javadoc'
plugin would be created for each existing plugin (correct me if I'm wrong).
What repository would these plugins be created in? Is it our 'source code'
repository or our 'web site' repository? If any properties files or
images are required on a per-plugin basis to produce the Java Doc, I'd
think it'd be best to have these in the 'web site' repository where they're
separated from our source code. BTW... it's my understanding that other
eclipse projects generate their Java Doc out to a single location for an
entire project. Is there a reason why we you'd want to generate out to a
more granular plugin level?
Please let me know if I've misunderstood anything.
thanks
Craig
Craig Salter
Rational Studio XML Web Services
Internal Mail: D3/RY6/8200 /MKM
Phone: (905) 413-3918 TL: 969-3918 FAX: (905) 413-4920
Internet: csalter@xxxxxxxxxx Notes: Craig Salter/Toronto/IBM@IBMCA
