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

[rcernich@xxxxxxxxxx]

Hey David,

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

Done.  https://bugs.eclipse.org/bugs/show_bug.cgi?id=161733


>  - rename those elements and the dependant APIs you mentioned?

Done.  https://bugs.eclipse.org/bugs/show_bug.cgi?id=161736


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

Please create a BZ entry with your requirements.  How would you be
accessing the functionality (programmatically, through the UI)?  What
attributes would you like to modify/specify?  Etc.


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

The deployment profile could be created in any project.  Cross project
dependencies are handle similarly to the way other development tools within
Eclipse are handled.  For example, in a Java project, you only have access
to classes defined within that project and all the projects referenced by
that project.  I don't see this as being any different.  I see it as being
consistent with other dev tools within Eclipse.


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

That is doable with the configurablePackage extension.  Look at the classes
within the org.eclipse.stp.soas.deploy.core.ui.configuration package.  The
documentation is sparse, to say the least, so here's a quick explanation.
These are used to contribute property pages for editing a package's
configuration.  The mechanism used is very similar to the basic property
page and preference page dialog within Eclipse, with the exception that you
need to provide the "nodes" for the pages.  A "node" is represented in the
tree on the left-hand side of the dialog and is associated with a "page"
displayed on the right.  You should use ConfigurationNode as the base class
for your nodes.  You should use ConfigurationPage as the base class for
your page implementations.  The main difference are the
IConfigurationNode.save() and needsSave() methods.  These can be used for
updating the state of the configuration.  The impetus for these methods, as
opposed to using the default behavior in the PreferenceDialog, was to
prevent save() from being called on nodes whose state may have already been
saved by a parent or child node.  For the most part, you should be able to
simply use performOk() on your page for updating the configuration.  Here's
a little example of an implementation for
IConfigurationPageFactory.contribute():

      pm.addToRoot(new MyConfigurationNode());
      pm.addTo("myConfigurationNodeId", MyConfigurationChildNode());

BZ entry requesting improved documentation for these APIs.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=161748

Also, there is some goofiness in the way the configuration validator APIs
are defined.  A packageConstructor specifies a validator which is used by
the framework to validate the package prior to deployment or package
creation.  It is also used by the deployment profile builder to validate
the deployment profile (i.e. to generate errors in the problems view).
IPackageConfiguration also specifies a validate() method, which is unused
by the framework.

BZ entry requesting these APIs be cleaned up.
https://bugs.eclipse.org/bugs/post_bug.cgi

Please feel free to create BZ entries for anything you find missing, broken
or things that could be improved.

Please let me know if you have any other questions, comments, concerns....

Rob