| [stp-dev] regarding the SOAS framework... |
|
Hi all, 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. 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. -
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. -
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 -
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 -
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. Regards, d. |