I'd like to come back to this thread an handle it.
The number of modules is growing and it would be
cleaner to reorg all these modules.

So, unless someone objects, I will reorg the svn source
tree on friday.

On 7/28/06, Philip Dodds <[EMAIL PROTECTED]> wrote:
I put together a basic plan (with some help from Guillaume), here

http://goopen.org/confluence/display/SM/Source+Structure

The purpose of the new structure it two allow cleaner separation between:

1/ The JBI Container
2/ Deployables such as shared libraries/BC's/SE's
3/ Platform specific packaging projects
4/ Archetypes
5/ Tooling
6/ Sampels

By categorizing the source it should become easier to read and therefore
identifying what SE/BC's/SL's are available should become more obvious,  as
well as cleanly showing what is required for core Container functionality.

There are a couple of ommissions - first rather than one assembly (currently
apache-servicemix project) I would like to add a root directories called
assemblies and then create a few packaging (as previously mentioned)

ie.

assemblies
   \ core-only
   \ core-and-components
   etc.

The other is the servicemix-components package,  there are two ways to go
here:

1/ Break up the components into different service engines
2/ Turn the servicemix-components jar into an SE,  add a dependencies on the
servicemix-lwcontainer and then change all the libs to optional false

I'm not keen on the first way because I think the conversion to real SE's
will take some time and should be given space to make sure we are able to
address things like WSDL for services etc.

In the second option we end up with a large SE though I believe it will
provide all the functionality,  I was thinknig that this would be a special
packaging - ie. your can download just that big SE separate from the other
assemblies.

I would like to try and get a discussion going on this since once this is
out of the way we could then look to the work invovled in converting some of
the lw-container service engines into more complete JBI Service Engines
(using the service-engine architype as a basis) and also work on puting more
WSDL in place for those services :)

P




--
Cheers,
Guillaume Nodet

Reply via email to