[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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
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 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
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.