I ran across this blog from Mike: http://milinkovich.blogspot.com/2006/04/seeking-balance.html
referring to John's post (http://www.xlml.com/aehso/2006/03/14/jcp-rubberstamping-and-eclipseorg-project-disarray/)
and I'd like to take this criticism and run with it. I think the STP deployment
framework is a perfect example of the "cracks" that John mentions.
I really do fear that we are about
to reinvent alot of the pieces in the WTP Server Tools API. I know there
is some coordination going through the PMCs (I think), but I'd like to
encourage the STP PMC to open the discussion up about the design of the
deployment framework to the STP community through the stp-dev mailing list,
rather than the stp-pmc mailing list.
I think there are some misconceptions
about what the WTP Server Tools API supports. As John points out, the WTP
Server Tools API is not J2EE-specific. It operates around a generic "Connection"
object, and I think that most servers use the standard JMX API for communication
between servers, but this is not required. The "Technology Types"
concept which is to be introduced under an STP Server Tool API is exactly
that of WTP Project Facets -- which are also generic ways to add information
to a project about what kind of development the project can support.
The WTP Server Tools API and Project
Facet API have had more scrutiny and overview than any other API in WTP.
They are the core of what WTP has been developing since its early days,
since they are so fundamental to an integrated Enterprise development platform.
WTP will almost certainly never agree to drop their API and replace it
with a DTP "Connection Profile" as so many WTP adopters already
have significant dependencies to this API.
WTP will also *NOT DEPEND* on DTP. The
RDB functionality is being moved out of WTP, but DTP and WTP are to be
sibling projects. If clients need Database integration, then they are free
to pick up DTP and WTP; but this is *not* required. There will be no hard
dependency between the two projects, and I have confirmed this with a member
of the WTP Architecture Group. Therefore, they are even less likely to
consider replacing their server integration API with the DTP version.
I think that any deployment framework
that STP produces has to be "connection neutral". I would encourage
that integration into Enterprise Service Buses (ESBs) or SCA containers
(like Tuscany) simply re-use the WTP Server Tools framework, as it provides
a way to define new servers, monitor server connections, and in conjunction
with Project Facets, allows Eclipse projects to be configured with the
appropriate build path configuration or other functionality. Any platform
built on STP cannot require clients to redefine integration with existing
J2EE servers; nor expose "new" server views for monitoring running
servers. The Web Tools Platform already has a server monitor view for any
type of server. It is not J2EE server specific. Also, as there is already
extensive support for Apache Tomcat -- and even a base Apache server (I
believe), it should be easy to add the server definition for the Apache
Tuscany sever through this framework as well.
I appreciate the fact that there are
individuals who have invested sizeable effort into a server integration
piece in isolation, but we have to consider what is best for the STP platform;
and I truly believe that any new server integration framework with new
concepts that mirror existing functionality in already well-reviewed platforms
is a severe error. That said, I'm sure that there are some pieces that
can be re-used from this effort; but any pieces that deal with defining
"new connections" or "new servers" or that expose new
views for monitoring or deploying applications to a server are likely to
splinter the Eclipse ecosystem architecture even more. I also think
these will lead to new usability concerns if existing users who are familiar
with WTP or DTP pick up the STP functionality and then have new Enterprise
project creation paths that are incompatible with WTP projects.
It has been a long process for WTP
to build the server tool and facet API and establish adoption of these
concepts and API. Let's take that and run with it so that we can get off
the ground more quickly; rather than undergoing the same effort that they've
had to endure for the server integration piece.