Re: [wtp-dev] The Big Picture

[David M Williams <david_williams@xxxxxxxxxx>]

Yes, we all agree to that! 

I will add, though, that the more concrete
use-cases people can come up with that they are most interested in, the
better, 

The code is tangled for historical reasons,
But, we've actually made great progress in the last release untangling
some of it, some small, some large. 
For example, we can not run WST without
the JDK! Much requested! And a subset of that is running the XML Editor
with just the Eclipse Platform ... well, plus some of the 
smaller pieces of EMF and tiny GEF.
Any one know why those got done? Because some prominent users/adopters
told us they needed it badly. And kept telling us. 
And got their friends and families to
tell us. :)  [Nah, Bob was very polite about it] :) 

So, dear readers, put on your creative
caps and capture some use cases for us. (Not that we could do them all,
but then we'd be able to pick feasible ones to guide next steps). 

Here's some I've heard of from various
sources -- just to get the ideas flowing. 

    Have full Web Services
tools, with no EJB tools. (sorry, I've never heard the reverse ... not
sure that'd make as much sense, but that's why we ask). 
    Have JSP and Servlets
but none of the other (cool) JEE stuff. 
    
Thanks,

Rob Stryker <rob.stryker@xxxxxxxxxx>
Sent by: wtp-dev-bounces@xxxxxxxxxxx

09/06/2007 04:31 AM

Please respond to
"General discussion of project-wide or architectural issues."        <wtp-dev@xxxxxxxxxxx>

To	"General discussion of project-wide or architectural issues." <wtp-dev@xxxxxxxxxxx>
cc
Subject	Re: [wtp-dev] The Big Picture

I think allowing adopters to consume only subsets
of WTP is an important 
goal.
It's also important to allow adopters to be able to plug in their own 
implementation of certain pieces if they decide the WTP-provided 
implementation could be improved upon.

I'm not terribly knowledgeable on some parts of WTP, but I still think
these are important goals all-around and should be adhered to as much as
possible. If the parts really are as interconnected as they seem, that
doesn't sound good. Adopters will need to consume all-or-nothing, and 
that's not a good position to be in... at least not for an open 
community. It may be a fine position for proprietary software ;)

- Rob Stryker
JBoss Tools / RHDS

David M Williams wrote:
>
> > Contact me either privately or publicly on this list and I will
be 
> glad to help.
>
> I know I'm always harping on this, but "public" is the only
way to go 
> for our Eclipse open source development.
>
> This is a good discussion and I did misunderstand part of what you
> were saying at first.
>
> I'd be interested in the utility. Is it EPL? In our repository 
> somewhere? Or, did you mean you could perform the
> analyses and make the end result available?
>
> I'm not sure I understand the project-circularity issue, since if
> divided into features and interwoven, there is no circularity ...
though
> it's fine to investigate, I think I just don't appreciate it much.
> Glad to hear the comments and observations though.
>
> One thing I think that can/needs to be improved is our own 
> "violations" of our own API across project feature boundaries.
> We should look for easy ways to minimize those.
> One example I saw some posts about was one of your and Kathy's 
> findings (or was a Peter while Kathy was out?) that there are some
> "common" plugins that are not planned to be API, and used
only by 
> webservices, so why not move them "up" into the web services
feature?
>
> I think it'd be great if we make incremental progress like that, in
> our "project-feature boundaries".
>
> The other possibility .. and I mean this as just a possibility ...
is 
> that some plugins in some features seem to be "separate plugins"
for
> no particularly good reason. While there's not great harm in having
> them separate, there is some small harm, some performance impacts
> of having lots of bundles, and it makes things look more confusing
to 
> see scores of plugins. But, I emphasize, maybe there is good 
> architectural or
> packaging reasons for having them separate and I'm just not aware
of 
> it. Just to randomly pick a possible example:
>
> org.eclipse.jst.j2ee.ejb
> org.eclipse.jst.j2ee.ejb.annotation.model
> org.eclipse.jst.j2ee.ejb.annotations.emitter
> org.eclipse.jst.j2ee.ejb.annotations.ui
> org.eclipse.jst.j2ee.ejb.annotations.xdoclet
>
> I'm all for a "model/core vs. UI" split in plugins, but
not sure why 
> we'd need 5 of these for what sounds like to my naive reading like
> very related plugins.
>
> Thanks for starting the discussion.
>
>
>
>
>
>
> *"Konstantin Komissarchik" <kosta@xxxxxxx>*
> Sent by: wtp-dev-bounces@xxxxxxxxxxx
>
> 09/04/2007 11:52 PM
> Please respond to
> "General discussion of project-wide or architectural issues."
      
>  <wtp-dev@xxxxxxxxxxx>
>
>
>                  
> To
>                  "General
discussion of project-wide or architectural issues." 
> <wtp-dev@xxxxxxxxxxx>
> cc
>                  
> Subject
>                  RE:
[wtp-dev] The Big Picture
>
>
>
>                  
>
>
>
>
>
> I understand that the change in the project definitions do not imply
> the changes in the feature definitions. My intention for this e-mail
> was to stimulate a discussion; to take stock of where we are and where
> we want to go. I have provided in this e-mail what I think is a pretty
> valuable insight into how our code base is put together. What I am
> hoping is that project leads (and in fact all of the committers) would
> take a look at this information and say "yeah, this makes sense
> because of x" or "this could be improved". The "non-java"
and "java" 
> split will continue to make sense for at least some projects, but
that 
> requirement by itself does not justify or explain circular 
> dependencies at project level. I suspect that each of these cases
are 
> unique and there may be multiple things contributing to the 
> circularity. Some of these may even be unavoidable. It is not my 
> intention to take a hard line on this issue. I merely want to see
if 
> there is interest in improving our high-level architecture, in 
> straightening out the dependency graph where possible, in making it
> easy for adopters to consume sub-sets of WTP, in making it easier
for 
> the project teams to work on their projects without having to build
> all of WTP and generally in making WTP more "platform quality".
If 
> anyone is interested in pursuing this further, the utility that I
> wrote makes it easy to ask complicated questions about dependencies
> that would be very time-consuming and error-prone to answer by hand.
> It also makes it easy to play the "what if" games with component
> composition. Contact me either privately or publicly on this list
and 
> I will be glad to help.
>  
> Thanks,
>  
> - Konstantin
>  
>
> *From:* wtp-dev-bounces@xxxxxxxxxxx 
> [mailto:wtp-dev-bounces@xxxxxxxxxxx] *On Behalf Of *David M Williams*
> Sent:* Tuesday, September 04, 2007 7:03 PM*
> To:* General discussion of project-wide or architectural issues.*
> Subject:* RE: [wtp-dev] The Big Picture
>
>
> Yes, the recent changes in the project definitions does not imply
> change in the feature definitions. The features are what they are
and 
> will stay that way (unless there's other reasons to change them).
> We can certainly make improvements, but I would expect most of the
> projects to always have at least a "non-Java" part and a
"java" part. 
> And, yes, there will always be some inter-leaving in the whole of
WTP. 
>  I see no issue with that, and was never my goal to have project
> specific builds ... hmm, at one point, that was even one of the FAQ's,
> but it seems to have been lost somewhere in editing. Sorry for that.
>
>
> > The Java EE <-> Common cycle is due to jst.common.frameworks
> > depending on wst.web. This seems wrong to me. This builds right
now
> > because by the time jst.common builds, all of wst has been compiled,
> > but I think jst.common should only be able to see wst.common.
>
> This is a good goal, but I'm not sure requirement .. and more 
> important, I am not sure what wst.web is contributing, or, honestly,
> where it belongs. It was one of the odd cases, and I may have guessed
> wrong where it belonged.
>
>
>
>
>
>
> *"Konstantin Komissarchik" <kosta@xxxxxxx>*
> Sent by: wtp-dev-bounces@xxxxxxxxxxx
>
> 09/04/2007 09:27 PM
> Please respond to
> "General discussion of project-wide or architectural issues."
      
>  <wtp-dev@xxxxxxxxxxx>
>
>                  
> To
>                  "General
discussion of project-wide or architectural issues." 
> <wtp-dev@xxxxxxxxxxx>
> cc
>                  
> Subject
>                  RE:
[wtp-dev] The Big Picture
>
>
>
>
>                  
>
>
>
>
>
>
> One of my goal was to better understand the new organization as 
> specified by the project refactoring proposal, so using existing 
> features would not work for that since they have yet to be updated
to 
> reflect this. Part of this process (at least as far as it applies
to 
> common) is to drive the creation of new features.
>  
> So... If you look at the component listings in my e-mail, you will
> notice that WST and JST parts co-mingle (just like they do in the
> project refactoring proposal). Now, if under each of the new projects
> we define a WST and a JST component and graph dependencies of those
> components, then we would not end up with any cycles (the build works,
> as you point out). Is that good enough? Is it ok to have cycles at
> project-level as long as we can define components such as no cycles
> would exists? How would you build such a structure once the codebase
> is re-organized based on the project refactoring proposal? We wouldn't
> be able to have a project-level build since a top-level driver would
> need to know how to weave builds of components of different projects
> such that cycles are avoided.
>  
> The Java EE <-> Common cycle is due to jst.common.frameworks
depending 
> on wst.web. This seems wrong to me. This builds right now because
by 
> the time jst.common builds, all of wst has been compiled, but I think
> jst.common should only be able to see wst.common.
>  
> - Konstantin
>  
>  
> *
> From:* wtp-dev-bounces@xxxxxxxxxxx 
> [mailto:wtp-dev-bounces@xxxxxxxxxxx] *On Behalf Of *David M Williams*
> Sent:* Tuesday, September 04, 2007 5:57 PM*
> To:* General discussion of project-wide or architectural issues.*
> Subject:* Re: [wtp-dev] The Big Picture
>
>
> I'm not sure I understand, but if you are saying that Common depends
> on Java EE, then I think something is amiss.
> The way our build works, it wouldn't compile if that was the case.
>
> Does your analysis also take into account the WST/JST split?
>
> I think the way to approach this would be more along the lines of
our 
> defined features?
>
> Or, am I simply not understanding?
>
> thanks,
>
>
> *"Konstantin Komissarchik" <kosta@xxxxxxx>*
> Sent by: wtp-dev-bounces@xxxxxxxxxxx
>
> 09/04/2007 08:19 PM
> Please respond to
> "General discussion of project-wide or architectural issues."
      
>  <wtp-dev@xxxxxxxxxxx>
>
>
>                  
> To
>                  "General
discussion of project-wide or architectural issues." 
> <wtp-dev@xxxxxxxxxxx>
> cc
>                  
> Subject
>                  [wtp-dev]
The Big Picture
>
>
>
>
>
>                  
>
>
>
>
>
>
>
> So in my quest to understand the "Common Project", I've
been writing a 
> little utility that can analyze plugin dependencies and produce a
> component-to-component dependencies (given component definitions).
> Until today, I've been mostly focused on understanding how the rest
of 
> WTP depends on common, but today I decided to let my utility show
me 
> the rest of the picture. Attached is the result.
>
> I knew the dependency lines were not going to be clean, but I was
a 
> bit surprised by the result. There are four simple circles that can
be 
> easily spotted...
>
> Java EE <-> Common (yikes!)
> Java EE <-> EJB
> Java EE <-> Server Tools
> Java EE <-> Web Services
>
> More complicated circles are also present, but these are harder to
> spot. One example is Web Services -> EJB -> Java EE -> Web
Services.
>
> It strikes me that we either have a lot of work ahead of us on 
> refactoring the dependencies or these boxes aren't quite right. Maybe
> a bit of both.
>
> Thoughts? Does any of this come as a surprise?
>
> I used information found in 
> http://www.eclipse.org/webtools/devProcess/wtpProjects/Refactor%20WTP%20Proposal.pdf
> <http://www.eclipse.org/webtools/devProcess/wtpProjects/Refactor%20WTP%20Proposal.pdf>
> as the definition of the component boundaries. I then ran my utility
> against 3.0 M1 installation which included WTP SDK and WTP automated
> tests. Let me know if the component membership as listed is not 
> accurate and needs to be tweaked. The only two plugins that are not
> accounted for are org.eclipse.wst and org.eclipse.jst. Not sure where
> these would end up.
>
> Common Component
>
> org.eclipse.jem
> org.eclipse.jem.beaninfo
> org.eclipse.jem.proxy
> org.eclipse.jem.tests
> org.eclipse.jem.ui
> org.eclipse.jem.util
> org.eclipse.jem.workbench
> org.eclipse.jst.common.annotations.controller
> org.eclipse.jst.common.annotations.core
> org.eclipse.jst.common.annotations.ui
> org.eclipse.jst.common.frameworks
> org.eclipse.jst.common.project.facet.core
> org.eclipse.jst.validation.sample
> org.eclipse.jst.validation.test
> org.eclipse.wst.command.env
> org.eclipse.wst.command.env.core
> org.eclipse.wst.command.env.doc.user
> org.eclipse.wst.command.env.infopop
> org.eclipse.wst.command.env.ui
> org.eclipse.wst.common.core
> org.eclipse.wst.common.emf
> org.eclipse.wst.common.emfworkbench.integration
> org.eclipse.wst.common.environment
> org.eclipse.wst.common.frameworks
> org.eclipse.wst.common.frameworks.ui
> org.eclipse.wst.common.infopop
> org.eclipse.wst.common.modulecore
> org.eclipse.wst.common.project.facet.core
> org.eclipse.wst.common.project.facet.core.tests
> org.eclipse.wst.common.project.facet.ui
> org.eclipse.wst.common.project.facet.ui.tests
> org.eclipse.wst.common.snippets
> org.eclipse.wst.common.snippets.tests
> org.eclipse.wst.common.tests
> org.eclipse.wst.common.tests.collector
> org.eclipse.wst.common.tests.ui
> org.eclipse.wst.common.ui
> org.eclipse.wst.common.ui.properties
> org.eclipse.wst.common.uriresolver
> org.eclipse.wst.internet.cache
> org.eclipse.wst.internet.cache.tests
> org.eclipse.wst.validation
> org.eclipse.wst.validation.infopop
> org.eclipse.wst.validation.ui
>
> Server Component
>
> org.eclipse.jst.server.core
> org.eclipse.jst.server.core.tests
> org.eclipse.jst.server.generic.core
> org.eclipse.jst.server.generic.jboss
> org.eclipse.jst.server.generic.jonas
> org.eclipse.jst.server.generic.oc4j
> org.eclipse.jst.server.generic.tests
> org.eclipse.jst.server.generic.ui
> org.eclipse.jst.server.installable
> org.eclipse.jst.server.preview.adapter
> org.eclipse.jst.server.tomcat.core
> org.eclipse.jst.server.tomcat.core.tests
> org.eclipse.jst.server.tomcat.ui
> org.eclipse.jst.server.tomcat.ui.tests
> org.eclipse.jst.server.ui
> org.eclipse.jst.server.ui.doc.user
> org.eclipse.jst.server.ui.infopop
> org.eclipse.jst.server.ui.tests
> org.eclipse.jst.server.websphere.core
> org.eclipse.wst.internet.monitor.core
> org.eclipse.wst.internet.monitor.ui
> org.eclipse.wst.internet.monitor.ui.tests
> org.eclipse.wst.server.core
> org.eclipse.wst.server.core.tests
> org.eclipse.wst.server.http.core
> org.eclipse.wst.server.http.core.tests
> org.eclipse.wst.server.http.ui
> org.eclipse.wst.server.preview
> org.eclipse.wst.server.preview.adapter
> org.eclipse.wst.server.ui
> org.eclipse.wst.server.ui.doc.user
> org.eclipse.wst.server.ui.infopop
> org.eclipse.wst.server.ui.tests
>
> Source Editors Component
>
> org.eclipse.jst.jsp.core
> org.eclipse.jst.jsp.core.tests
> org.eclipse.jst.jsp.tests.encoding
> org.eclipse.jst.jsp.ui
> org.eclipse.jst.jsp.ui.infopop
> org.eclipse.jst.jsp.ui.tests
> org.eclipse.jst.standard.schemas
> org.eclipse.wst.css.core
> org.eclipse.wst.css.core.tests
> org.eclipse.wst.css.tests.encoding
> org.eclipse.wst.css.ui
> org.eclipse.wst.css.ui.tests
> org.eclipse.wst.dtd.core
> org.eclipse.wst.dtd.ui
> org.eclipse.wst.dtd.ui.infopop
> org.eclipse.wst.dtd.ui.tests
> org.eclipse.wst.dtdeditor.doc.user
> org.eclipse.wst.html.core
> org.eclipse.wst.html.core.tests
> org.eclipse.wst.html.tests.encoding
> org.eclipse.wst.html.ui
> org.eclipse.wst.html.ui.infopop
> org.eclipse.wst.html.ui.tests
> org.eclipse.wst._javascript_.core
> org.eclipse.wst._javascript_.ui
> org.eclipse.wst._javascript_.ui.infopop
> org.eclipse.wst.sse.core
> org.eclipse.wst.sse.core.tests
> org.eclipse.wst.sse.doc.user
> org.eclipse.wst.sse.ui
> org.eclipse.wst.sse.ui.infopop
> org.eclipse.wst.sse.ui.tests
> org.eclipse.wst.standard.schemas
> org.eclipse.wst.xml.core
> org.eclipse.wst.xml.core.tests
> org.eclipse.wst.xml.tests.encoding
> org.eclipse.wst.xml.ui
> org.eclipse.wst.xml.ui.infopop
> org.eclipse.wst.xml.ui.tests
> org.eclipse.wst.xml.validation.tests
> org.eclipse.wst.xmleditor.doc.user
> org.eclipse.wst.xsd.core
> org.eclipse.wst.xsd.ui
> org.eclipse.wst.xsd.validation.tests
> org.eclipse.wst.xsdeditor.doc.user
>
> Web Services Component
>
> org.eclipse.jst.ws
> org.eclipse.jst.ws.axis.consumption.core
> org.eclipse.jst.ws.axis.consumption.core.tests
> org.eclipse.jst.ws.axis.consumption.ui
> org.eclipse.jst.ws.axis.creation.ui
> org.eclipse.jst.ws.axis.infopop
> org.eclipse.jst.ws.axis.ui.doc.user
> org.eclipse.jst.ws.axis2.consumption.core
> org.eclipse.jst.ws.axis2.consumption.ui
> org.eclipse.jst.ws.axis2.core
> org.eclipse.jst.ws.axis2.creation.core
> org.eclipse.jst.ws.axis2.creation.ui
> org.eclipse.jst.ws.axis2.ui
> org.eclipse.jst.ws.consumption
> org.eclipse.jst.ws.consumption.infopop
> org.eclipse.jst.ws.consumption.ui
> org.eclipse.jst.ws.consumption.ui.doc.user
> org.eclipse.jst.ws.creation.ejb.ui
> org.eclipse.jst.ws.creation.ui
> org.eclipse.jst.ws.doc.user
> org.eclipse.jst.ws.infopop
> org.eclipse.jst.ws.tests
> org.eclipse.jst.ws.uddiregistry
> org.eclipse.jst.ws.ui
> org.eclipse.wst.ws
> org.eclipse.wst.ws.explorer
> org.eclipse.wst.ws.infopop
> org.eclipse.wst.ws.parser
> org.eclipse.wst.ws.tests
> org.eclipse.wst.ws.ui
> org.eclipse.wst.wsdl
> org.eclipse.wst.wsdl.tests
> org.eclipse.wst.wsdl.tests.ui
> org.eclipse.wst.wsdl.ui
> org.eclipse.wst.wsdl.ui.doc.user
> org.eclipse.wst.wsdl.validation
> org.eclipse.wst.wsdl.validation.tests
> org.eclipse.wst.wsi
> org.eclipse.wst.wsi.tests
> org.eclipse.wst.wsi.ui
> org.eclipse.wst.wsi.ui.doc.user
>
> Java EE Tools Component
>
> org.eclipse.jst.doc.isv
> org.eclipse.jst.j2ee
> org.eclipse.jst.j2ee.core
> org.eclipse.jst.j2ee.core.tests
> org.eclipse.jst.j2ee.doc.user
> org.eclipse.jst.j2ee.infopop
> org.eclipse.jst.j2ee.jca
> org.eclipse.jst.j2ee.jca.ui
> org.eclipse.jst.j2ee.navigator.ui
> org.eclipse.jst.j2ee.tests
> org.eclipse.jst.j2ee.ui
> org.eclipse.jst.j2ee.web
> org.eclipse.jst.j2ee.webservice
> org.eclipse.jst.j2ee.webservice.ui
> org.eclipse.jst.j2ee.xdoclet.runtime
> org.eclipse.jst.jee
> org.eclipse.jst.jee.ui
> org.eclipse.jst.jee.web
> org.eclipse.jst.servlet.tests
> org.eclipse.jst.servlet.ui
> org.eclipse.jst.servlet.ui.infopop
> org.eclipse.wst.doc.isv
> org.eclipse.wst.doc.user
> org.eclipse.wst.web
> org.eclipse.wst.web.ui
> org.eclipse.wst.web.ui.infopop
> org.eclipse.wst.webtools.doc.user
>
> EJB Tools Component
>
> org.eclipse.jst.ejb.doc.user
> org.eclipse.jst.ejb.ui
> org.eclipse.jst.j2ee.ejb
> org.eclipse.jst.j2ee.ejb.annotation.model
> org.eclipse.jst.j2ee.ejb.annotations.emitter
> org.eclipse.jst.j2ee.ejb.annotations.ui
> org.eclipse.jst.j2ee.ejb.annotations.xdoclet
> org.eclipse.jst.jee.ejb
>
> JSF Component
>
> org.eclipse.jst.jsf.common
> org.eclipse.jst.jsf.common.ui
> org.eclipse.jst.jsf.contentassist.tests
> org.eclipse.jst.jsf.context.symbol.tests
> org.eclipse.jst.jsf.core
> org.eclipse.jst.jsf.core.tests
> org.eclipse.jst.jsf.designtime.tests
> org.eclipse.jst.jsf.doc.dev
> org.eclipse.jst.jsf.doc.user
> org.eclipse.jst.jsf.facesconfig
> org.eclipse.jst.jsf.facesconfig.ui
> org.eclipse.jst.jsf.metadata.tests
> org.eclipse.jst.jsf.metadataprocessingtests2
> org.eclipse.jst.jsf.standard.tagsupport
> org.eclipse.jst.jsf.test.util
> org.eclipse.jst.jsf.ui
> org.eclipse.jst.jsf.ui.tests
> org.eclipse.jst.pagedesigner
> org.eclipse.jst.pagedesigner.jsf.ui
> org.eclipse.jst.pagedesigner.jsp.core
>
> JPT Component
>
> org.eclipse.jpt
> org.eclipse.jpt.core
> org.eclipse.jpt.core.tests
> org.eclipse.jpt.core.tests.extension.resource
> org.eclipse.jpt.db
> org.eclipse.jpt.db.ui
> org.eclipse.jpt.doc.user
> org.eclipse.jpt.gen
> org.eclipse.jpt.ui
> org.eclipse.jpt.utility
> org.eclipse.jpt.utility.tests
>
>  
>
>                  
>
>                  
>                  
 *Konstantin Komissarchik*
> Staff Software Engineer
> Phone: 206.926.2962
> IM: kosta0120 on Yahoo
> kosta@xxxxxxx <mailto:kosta@xxxxxxx>        
               
          *BEA Systems, Inc.*
> 999 North Northlake Way
> Seattle, WA 98103
> www.bea.com <http://www.bea.com/>        
         
>                  
 Barring that natural _expression_ of villainy which we all
have, the 
> man looked honest enough.
>                    
                     
         
>
>
>
>                    
                     
        *Mark Twain         
>      *
>
>
>
>
>
>
>
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not the 
> intended recipient, and have received this message in error, please
> immediately return this by email and then delete it. 
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
>
> Notice: This email message, together with any attachments, may contain

> information of BEA Systems, Inc., its subsidiaries
and affiliated 
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not the 
> intended recipient, and have received this message in error, please
> immediately return this by email and then delete it. 
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
>
> Notice: This email message, together with any attachments, may contain
> information of BEA Systems, Inc., its subsidiaries and affiliated
> entities, that may be confidential, proprietary, copyrighted and/or
> legally privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not the 
> intended recipient, and have received this message in error, please
> immediately return this by email and then delete it. 
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev
>   

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev