I think it's a good idea to move this code out of the integration
branch. I prefer to keep the integration branch for its original
purpose of providing a stable environment for developing and testing
end to end scennarios.
I agree that it's important not to destabilize trunk by adding this
code. This could be achieved by separating it from the rest of trunk
by putting it in a separate module that is not part of the main
build profile.
If there is potential to use this code in other parts of the trunk
code (Sebastien suggested a few possibilities), then this would be a
good reason to put it in trunk rather than a sandbox. I'm not clear
on whether this usage is something that might happen soon or is a little
further out. If this expected usage is a near-term thing, then I think
it makes sense to put the code in trunk. If there isn't any immediate
need to use it elsewhere, then it could go into a sandbox for now.
Simon
Jim Marino wrote:
On Mar 19, 2007, at 10:40 PM, Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
I'd like to start a discussion on how we could componentize our SCA
runtime kernel. I posted two diagrams on our Wiki at http://
cwiki.apache.org/confluence/display/TUSCANY/Componentizing+our
+runtime to help start the discussion.
One of the ideas is to allow for different integration strategies
with app servers and other runtime environments. Some integrations
may reuse the Tuscany kernel as a whole, but others will want to
reuse only a subset or replace parts with specific implementations.
A few examples come to mind:
- swap our POJO IOC container with another one already there in the
target app server;
- strip out the local assembly support when building a WSDL remote-
interface based (an SCA/BPEL container for example);
- strip out the federated deployment / discovery / distributed
wiring support when building a simple standalone runtime, or if your
app server already supports that and you'd like to integrate with it;
- replace the SCDL loaders if you're storing the assembly metadata
in a database instead of SCDL files;
- use a different handler/interceptor mechanism already in use in
your app server or a more dynamic invocation mechanism to support
scripting languages for example.
Another scenario I have in mind is to reuse parts of the Tuscany
kernel in validation tasks, codegen utilities, deployment and
management tools. For example I'd like to have an Ant task that
automates the generation of SDO or JAXB objects for an entire SCA
contribution. This task will need access to the SCA assembly model,
the SCA contribution model, maybe our Interface contract model as
well, but I don't want to drag the whole kernel for that. Similar
idea for deployment and management tasks.
A refactored/componentized kernel will also make it easier for
people to contribute to the individual pieces and exchange
components between our various initiatives.
For example I'd like to pull pieces of the trunk in the integration
branch, and it would be much easier if the single kernel/core module
was split in smaller independent modules (assembly model, SCA
contribution model, loaders, assembly wiring logic, invocation
framework etc...)
To help explore these ideas, I'm thinking about starting some
concrete work and try to pull some of the kernel code into
individual modules, probably start from the bottom of the stack and
have the assembly metadata and SCDL loaders in separate modules.
There's a lot of code, so I could use any help if people are
interested.
Thoughts?
I made some progress with an assembly model module, containing
interfaces representing the SCA 1.0 assembly model and a default
implementation of these interfaces.
The module is currently there: http://svn.apache.org/repos/asf/
incubator/tuscany/branches/sca-java-integration/sca/assembly. There's
additional test cases as well under http://svn.apache.org/
repos/asf/incubator/tuscany/branches/sca-java-integration/sca/scdl,
I'm planning to merge them into the assembly module soon. The
interfaces in assembly are different from the o.a.t.spi.model classes
in kernel/core. They are interfaces instead of classes, and I tried
to be as close as possible to the latest revision of SCA 1.0 spec.
I'd like your feedback and please let me know if you see any
inconsistencies with the SCA 1.0 spec. Next, I'd like to see if the
model loaders could be externalized as well in a separate module, but
this is going to be a little more complicated as the current loaders
have more dependencies, including circular dependencies with other
packages in kernel/core.
This work is starting to generate significant changes and new code
and I don't want to risk destabilizing the integration branch with it
so I'd like to continue to work on this somewhere in the trunk
instead. I'm thinking of moving the assembly model module to trunk
under java/sca/assembly, available for use by our various tools,
plugins, as well as the kernel and services modules if they need.
As you mentioned above, the approach taken is significantly different
than the design we have in trunk. To avoid destabilizing it, I'd
suggest starting this in a sandbox so that we can better understand how
it would integrate with our existing design without impacting existing
ongoing work.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
