Skip to main content

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

> -        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.

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
> 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

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

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

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.

Back to the top