Skip to main content

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





Back to the top