Re: [stp-dev] regarding the SOAS framework...

[rcernich@xxxxxxxxxx]

Hi Johnson,

> Besides directly adding action and launch extension, I think another
option
> is to reuse the server runtime framework in WTP. That means SOAS
> logical/physical package and package constructor + WTP server runtime
> framework.

I'm hesitant to tie the deployment framework directly to the WTP server
runtime for a couple of reasons.

1.  The UI is not very extensible.  The only objects which are contributed
to the view are the packages deployed from the workspace.  The connection
profile framework is built atop the common navigator framework allowing all
types of content to be displayed for servers.  I think this is a limitation
in that there may be other objects on the server which may be useful to the
developer.  In an SOA context, these may be services deployed on the server
that a developer might like to use in their system.  In a JEE context,
these may be other components on the server that a developer might like to
use in their application.  In either case, unless the objects are
associated with objects in the workspace, they will not show up in the
view.  (This may be a limitation of my knowledge of the WTP framework, but
I could not figure out how to do this after a few days working with the WTP
framework.)

2.  The project seems to be the main object in the workspace used to define
deployable items.  I have been able to use files to identify packages,
however I could not figure out how to create unique identifiers for them,
which made it difficult to distinguish between individual packages (if the
file names are identical, so are the package names).  Given that the
meta-data for a deployable object in an SCA system is defined within a
file, the WTP framework may prove limiting.

3.  Launch support is scheduled to be added to the connection profile
framework in a future release.

Overall, I found the functionality between the two frameworks to be
complimentary.  Some of the differences are highlighted above (e.g. WTP is
integrated with launch configurations, DTP supports a more customized view,
STP supports a more flexible way to identify packages).  My impression was
that the WTP framework was great if you were working with a server type
similar to a JEE or web server, but required a lot of work if you were
trying to implement it for a different type of server.

My preferred approach would be to find a way to integrate the WTP server
runtime with the connection profile and deployment frameworks.  A
connection profile could be used to represent a WTP type server.  The
existing content should be very easy to plug into the explorer view by
creating a navigator extension that simply delegates to the exiting
provider used by the servers view.  For packaging and deployment, it should
be very easy to delegate to the existing WTP implementation from an STP
deploymentExtension.

FYI, there has been a defect opened aimed at defining a common architecture
for defining server runtime information within Eclipse.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=159169

Best regards,
Rob