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