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

["Beaurpere, David" <David.Beaurpere@xxxxxxxx>]

Hi rob,

Sorry for the late reply,

Regarding "technology" extension elements: Yes I have read the PDF a
while ago and it was a very useful introduction. I like the sort of
loose mapping they allow but, for the sake of keeping track of things,
would it make sense to log bugzilla entries to:
 - add documentation to the extension point itself?
 - rename those elements and the dependant APIs you mentioned?

Regarding the staging location: I understand that each generated package
has to be in a distinct location. The only thing that I was hoping for
was to get some control over the location and naming of the base staging
directory in order to integrate SOAS extensions more easily to bigger
tools.

Regarding the editor only loading logical packages from the current
projects and its references: doesn't it goes against the overall goal of
the SOAS framework (i.e. facilitate the deployment of heterogeneous
applications in a repeatable manner)? Or is the expectation to have the
users create a new "deployment" project, set reference to all the
projects containing artifacts they want to deploy (java/c++,
j2ee/JBI/SCA...) and then create a deployment profile in that project?

Regarding the lack manual mechanism to capture extra information: I'll
have a look at the configurablePackage you mentioned. One of the things
I would like to do is to allow the users to overwrite basic properties
of the generated package. A simple example would be to change the name
of the produced archive file (assuming that the package takes the form
of such a file)


Cheers,
d.  

-----Original Message-----
From: stp-dev-bounces@xxxxxxxxxxx [mailto:stp-dev-bounces@xxxxxxxxxxx]
On Behalf Of rcernich@xxxxxxxxxx
Sent: 17 October 2006 18:46
To: STP Dev list
Subject: Re: [stp-dev] regarding the SOAS framework...

Hey David,

Responses inline.

> A while ago, Johnson and I experimented with the SOAS framework as
> preparation work for the celtix/cxf SC tooling. Overall it worked
> great and we got a prototype working in a very short time.
>

Good to hear.


> Now we are looking to actually start coding something that we will
> be able to commit and in that context, we have a few questions
> regarding the framework.
>
> I am just going to put them all there and see where it goes:
>
> -        The "logicalPackage" extension element targets only files
> as "anchor" to deployable artifacts. This actually caused us trouble
> as our service implementations do not have such a file to represent
> them as an entity (they are just a bunch of file in a folder with
> some simple meta-data attached to it). As a work-around we targeted
> a file that appends to be generated "most" of the time, but then we
> used it only to process file paths relative to its location (the
> content of the file wasn't related). Would it be possible to widen
> the range of targeted resources to IContainers like IFolder and
> IProjects? In the same context the "fileExtension" shouldn't be
mandatory.
>
I think it would be good to expand to IResource.  This would be a more
flexible implementation.  Once expanded to work with all resource types,
I
do agree that fileExtension should be made optional.  This would depend
on
how the design fleshes out for supporting other resource types.

Currently, the fileExtension element is used to narrow the list of
extensions that might support a particular file.

In the meantime, to get you going, you could look at using the .project
file for your "logical" package.  You'd have to implement the
supportValidator to check to see if the containing project is of your
nature, etc.  This is not ideal since the .project file is hidden by
default and would require users to deploy the .project file as opposed
to
the project.

I've created a BZ entry for this enhancement.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=161283

> -        The set of "technology" extension elements got me running
> in circle for a while. I don't know if it was due to the naming or
> simply to my brain but, ever way, would it be possible to get some
> extra docs in the extension point schemas? Also the structure of
> those extension elements is not always consistent, especially around
> the range version number being supported.

There is some additional documentation on the wiki site.  Let me know if
you find it helpful or not.
http://wiki.eclipse.org/images/4/46/DeploymentFrameworkOverview_v0.2.pdf

Basically, the technology elements are ill named.  They are used to tie
logical/configurable package types to servers types.  The technologyMap
should be deprecated and the information contained within should be
generated from the information specified within the deployDriver
extensions.  I'm not sure off the top of my head which portions of the
framework utilize this map, but I do recall it required refactoring more
code than I had time, so I left it in to keep things working.


> -        The staging location used by the packager is not
> configurable (or rather I didn't find how): the framework always
> generates a "deployment" folder in the projects containing its
> related "deployment profile" and the internal structure of that
> folder seems itself hard coded (based on the "logicalPackage"
> definition). Would it still be possible to have some level of
> configuration regarding the generation of those folder structures? I
> understand the need of being able the uniqueness of the paths being
> used by the packagers, but for example:
> o       We would have liked rename this folder ".staging", ".
> deployment" or similar so that they get filtered out by the package
navigator.
> o       our own code generators produced folder called "deploy" (not
> at the root of the project though) which could be a cause of confusion

This is configurable through the project properties.  Explanation
follows...

The folder structure is created this way because a package may be
targeted
to several servers, each of which may use a customized configuration,
and
each of which may be of a different type.  A deployment profile not only
allows a package to be targeted for deployment to multiple servers, but
it
also allows the package to be configured for each of those servers
(assuming the package type supports configuration).  Also, since logical
packages may be deployed to servers of different types, an assumption is
made that the artifacts created by the package constructors are not
compatible.

A contrived example would be deploying an SCA module file to both a
tuscany
and service mix runtimes through a deployment profile.  Let's also say
that
one or more properties within the module are overridden for the service
mix
target.  When the profile builds the packages, there will be a default
build for the tuscany target (since its configuration was not
specialized)
and a server specific build for the service mix target (since its
configuration was specialized).  If another service mix server was
targeted, without any changes to the module's default configuration, a
default build for the service mix target will also be generated.


> -        The editor seems to list only the logical packages from the
> project of the "deployment profile" being edited. I do not know if
> it's a bug or not, but I think it would be much more useful if it
> was opened to all the projects in the current workspace

That is correct.  It only lists packages in the current project.  It
will
also list packages defined within referenced projects.


> -        No manual mechanism to capture extra information for the
> packaging. As it stands the editor does not allow the user to
> capture such data so we have either to hope that the logical package
> and the target will together contains all necessary data or we have
> to stick to "defaults". I guess we could have the
> "IPackageConstructor" instance to spawn some dialog and get the data
> from there but then this information would not be stored with the
> deployment profile file. Note that this is not a problem for the
> deployment as we can get the connection profile pages to capture
> everything we need.

You might try using a configurablePackage if you wish to give the user
the
ability to customize details within the package profile.  This
configuration information will be stored in the deployment profile.
However, by design, the package profile should contain all the
information
necessary to construct a package.

If using a configurable package will not work for you, please give me
more
details as to your exact problem so we can add the necessary
enhancements
to the framework.

Also note, a deployment profile file is not required to execute a
deployment.  It is provided to enable repeatable deployments and
deployments of one or more packages to one or more servers.  The intent
of
the deployment profile (and framework) was to provide a mechanism for
deploying heterogeneous applications.

With all that, the user is still given the ability to right-click a
package
or package profile and deploy it.  In that context, the user is
presented
with a list of applicable servers.  The user selects a server and the
deployment is executed.  Similar functionality is provided for
packaging,
however the user is presented with a list of server types (if more than
one
server type is associated with the selected profile's logical package
type).

Also, I would be happy to hear your thoughts after using the framework.
What was easy?  What was hard?  What you wanted to do, but couldn't?
General impression?  (I've got thick skin. ;-))

Hope that helps.
Rob