[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [wtp-dev] The Big Picture
|
> 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
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._______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
