Thoughts on restructuring

[Philip Dodds <ph...@gmail.com>]

I have been wondering about the possible restructuring of the ServiceMix
code tree and build to enable cleaner separation,  smaller/quicker builds,
and the ability to separate out releases.

The idea has been bounced around a bit on IRC and I wanted to put it out
there for peoples thoughts.

The basic idea is to break the current single build into three discreet
projects,  these would be :

ServiceMix JBI Container
ServiceMix Components
ServiceMix Tooling

The first would be purely the JBI Container with no Service Engines or
Components and no tooling (it would also not require any ServiceMix tooling
to build.  Thus it would consist of the following projects:

servicemix-core
servicemix-jbi
servicemix-services

This would be packaged with the assembly to create a pure JBI server without
any components.

The second would be the JBI Maven 2 Tooling that is available,  this would
also include the archetypes that we are currently putting in place.  These
are all currently Maven2 plugins and have a dependency on the ServiceMix
Core Container and therefore should be built second.  It would consist of
the following projects:

jbi-maven-plugin
servicemix-binding-component
servicemix-http-consumer-service-unit
servicemix-http-provider-service-unit
servicemix-jms-consumer-service-unit
servicemix-jms-provider-service-unit
servicemix-jsr181-wsdl-first-service-unit
servicemix-service-assembly
servicemix-service-engine
servicemix-service-unit
servicemix-shared-library

The final project would be the ServiceMix JBI Components/Shared Libraries
which is dependent on both the Core and the Tooling,  this would contain:

servicemix-beanflow
servicemix-bpe
servicemix-components
servicemix-common
servicemix-eip
servicemix-http
servicemix-jms
servicemix-jsr181
servicemix-lwcontainer
servicemix-sca
servicemix-soap
servicemix-wsn2005

The projects that would be left that need consideration would be :

servicemix-web
servicemix-console

Also I would like to bring up the idea of updating the Tooling versions so
that they are in sync with the Core and Components (ie
3.0-incubating-SNAPSHOT). Currently we have a situation where we often hold
both the ServiceMix version and the tooling version though I would think it
would be easier to make them the same version.

Philip

Re: Thoughts on restructuring

[Philip Dodds <ph...@gmail.com>]

Maybe another thing is cleaner separation of the packagings of ServiceMix,
such that we can have the stand-alone project,  then the TomCat WAR
deployment, JBoss Deployment (obviously outside Apache) and Geronimo
deployment as separate downloads.  I was just thinking this might reduce the
size of each download.

Another thought i wonder if we could take something like IzPack (now moving
to ASL) and actually create an installer for each - I believe there is a
Maven2 plugin in the works (might even be complete).

As a side I wonder whether you could create an installer based on Maven
embedded that you pick the projects and it assemblys them for you on your
machine from the repos - then you could re-open the installer and choose
update?

P

On 7/7/06, Philip Dodds <ph...@gmail.com> wrote:
>
> Cool idea :)
>
> P
>
> On 7/7/06, James Strachan <ja...@gmail.com> wrote:
>
> > On 7/7/06, Philip Dodds <ph...@gmail.com> wrote:
> > > Yeah - actually we might want to do something like :
> > >
> > > * container
> > > * core tooling (just currently the jbi-maven-plugin)
> > > * components
> > > * archetypes
> > > * other tooling like web applications, portal stuff, high end tools,
> > > eclipse tooling etc
> > >
> > > Since the archetypes are sort out outside of the tooling world and I
> > can see
> > > there being quite a few archetypes.
> >
> > Agreed. We might get clever one day and auto-generate some instances
> > from the artifacts and try deploy them in servicemix as an integration
> > test.
> >
> > --
> >
> > James
> > -------
> > http://radio.weblogs.com/0112098/
> >
>
>

Re: Thoughts on restructuring

[Philip Dodds <ph...@gmail.com>]

Cool idea :)

P

On 7/7/06, James Strachan <ja...@gmail.com> wrote:
>
> On 7/7/06, Philip Dodds <ph...@gmail.com> wrote:
> > Yeah - actually we might want to do something like :
> >
> > * container
> > * core tooling (just currently the jbi-maven-plugin)
> > * components
> > * archetypes
> > * other tooling like web applications, portal stuff, high end tools,
> > eclipse tooling etc
> >
> > Since the archetypes are sort out outside of the tooling world and I can
> see
> > there being quite a few archetypes.
>
> Agreed. We might get clever one day and auto-generate some instances
> from the artifacts and try deploy them in servicemix as an integration
> test.
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>

Re: Thoughts on restructuring

[James Strachan <ja...@gmail.com>]

On 7/7/06, Philip Dodds <ph...@gmail.com> wrote:
> Yeah - actually we might want to do something like :
>
> * container
> * core tooling (just currently the jbi-maven-plugin)
> * components
> * archetypes
> * other tooling like web applications, portal stuff, high end tools,
> eclipse tooling etc
>
> Since the archetypes are sort out outside of the tooling world and I can see
> there being quite a few archetypes.

Agreed. We might get clever one day and auto-generate some instances
from the artifacts and try deploy them in servicemix as an integration
test.

-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Thoughts on restructuring

[Philip Dodds <ph...@gmail.com>]

Yeah - actually we might want to do something like :

* container
* core tooling (just currently the jbi-maven-plugin)
* components
* archetypes
* other tooling like web applications, portal stuff, high end tools,
eclipse tooling etc

Since the archetypes are sort out outside of the tooling world and I can see
there being quite a few archetypes.

P


On 7/7/06, James Strachan <ja...@gmail.com> wrote:
>
> I agree with all of that; some refactoring of the build would be a
> good thing. Using a common version number is a good thing too.
>
> Just a thought; I wonder if we should split the tooling into 'maven
> tooling' which will often be a core dependency on component's builds -
> with other tooling (like eclipse tooling or servicemix-web or
> servicemix-console and so forth). Otherwise we might get circular
> dependencies. e.g. things like servicemix-web or portals and the like
> will probably be dependent on almost everything in the servicemix
> project - so we probably need some tooling stuff built last - not
> before the components.
>
> e.g.  build order something like...
>
> * container
> * core tooling (mostly just maven plugins I think?)
> * components
> * other tooling like web applications, portal stuff, high end tools,
> eclipse tooling etc
>
> so maybe the order is: container, maven plugins, components, tools?
>
> On 7/7/06, Philip Dodds <ph...@gmail.com> wrote:
> > I have been wondering about the possible restructuring of the ServiceMix
> > code tree and build to enable cleaner separation,  smaller/quicker
> builds,
> > and the ability to separate out releases.
> >
> > The idea has been bounced around a bit on IRC and I wanted to put it out
> > there for peoples thoughts.
> >
> > The basic idea is to break the current single build into three discreet
> > projects,  these would be :
> >
> > ServiceMix JBI Container
> > ServiceMix Components
> > ServiceMix Tooling
> >
> > The first would be purely the JBI Container with no Service Engines or
> > Components and no tooling (it would also not require any ServiceMix
> tooling
> > to build.  Thus it would consist of the following projects:
> >
> > servicemix-core
> > servicemix-jbi
> > servicemix-services
> >
> > This would be packaged with the assembly to create a pure JBI server
> without
> > any components.
> >
> > The second would be the JBI Maven 2 Tooling that is available,  this
> would
> > also include the archetypes that we are currently putting in
> place.  These
> > are all currently Maven2 plugins and have a dependency on the ServiceMix
> > Core Container and therefore should be built second.  It would consist
> of
> > the following projects:
> >
> > jbi-maven-plugin
> > servicemix-binding-component
> > servicemix-http-consumer-service-unit
> > servicemix-http-provider-service-unit
> > servicemix-jms-consumer-service-unit
> > servicemix-jms-provider-service-unit
> > servicemix-jsr181-wsdl-first-service-unit
> > servicemix-service-assembly
> > servicemix-service-engine
> > servicemix-service-unit
> > servicemix-shared-library
> >
> > The final project would be the ServiceMix JBI Components/Shared
> Libraries
> > which is dependent on both the Core and the Tooling,  this would
> contain:
> >
> > servicemix-beanflow
> > servicemix-bpe
> > servicemix-components
> > servicemix-common
> > servicemix-eip
> > servicemix-http
> > servicemix-jms
> > servicemix-jsr181
> > servicemix-lwcontainer
> > servicemix-sca
> > servicemix-soap
> > servicemix-wsn2005
> >
> > The projects that would be left that need consideration would be :
> >
> > servicemix-web
> > servicemix-console
> >
> > Also I would like to bring up the idea of updating the Tooling versions
> so
> > that they are in sync with the Core and Components (ie
> > 3.0-incubating-SNAPSHOT). Currently we have a situation where we often
> hold
> > both the ServiceMix version and the tooling version though I would think
> it
> > would be easier to make them the same version.
> >
> > Philip
> >
> >
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>

Re: Thoughts on restructuring

[James Strachan <ja...@gmail.com>]

I agree with all of that; some refactoring of the build would be a
good thing. Using a common version number is a good thing too.

Just a thought; I wonder if we should split the tooling into 'maven
tooling' which will often be a core dependency on component's builds -
with other tooling (like eclipse tooling or servicemix-web or
servicemix-console and so forth). Otherwise we might get circular
dependencies. e.g. things like servicemix-web or portals and the like
will probably be dependent on almost everything in the servicemix
project - so we probably need some tooling stuff built last - not
before the components.

e.g.  build order something like...

* container
* core tooling (mostly just maven plugins I think?)
* components
* other tooling like web applications, portal stuff, high end tools,
eclipse tooling etc

so maybe the order is: container, maven plugins, components, tools?

On 7/7/06, Philip Dodds <ph...@gmail.com> wrote:
> I have been wondering about the possible restructuring of the ServiceMix
> code tree and build to enable cleaner separation,  smaller/quicker builds,
> and the ability to separate out releases.
>
> The idea has been bounced around a bit on IRC and I wanted to put it out
> there for peoples thoughts.
>
> The basic idea is to break the current single build into three discreet
> projects,  these would be :
>
> ServiceMix JBI Container
> ServiceMix Components
> ServiceMix Tooling
>
> The first would be purely the JBI Container with no Service Engines or
> Components and no tooling (it would also not require any ServiceMix tooling
> to build.  Thus it would consist of the following projects:
>
> servicemix-core
> servicemix-jbi
> servicemix-services
>
> This would be packaged with the assembly to create a pure JBI server without
> any components.
>
> The second would be the JBI Maven 2 Tooling that is available,  this would
> also include the archetypes that we are currently putting in place.  These
> are all currently Maven2 plugins and have a dependency on the ServiceMix
> Core Container and therefore should be built second.  It would consist of
> the following projects:
>
> jbi-maven-plugin
> servicemix-binding-component
> servicemix-http-consumer-service-unit
> servicemix-http-provider-service-unit
> servicemix-jms-consumer-service-unit
> servicemix-jms-provider-service-unit
> servicemix-jsr181-wsdl-first-service-unit
> servicemix-service-assembly
> servicemix-service-engine
> servicemix-service-unit
> servicemix-shared-library
>
> The final project would be the ServiceMix JBI Components/Shared Libraries
> which is dependent on both the Core and the Tooling,  this would contain:
>
> servicemix-beanflow
> servicemix-bpe
> servicemix-components
> servicemix-common
> servicemix-eip
> servicemix-http
> servicemix-jms
> servicemix-jsr181
> servicemix-lwcontainer
> servicemix-sca
> servicemix-soap
> servicemix-wsn2005
>
> The projects that would be left that need consideration would be :
>
> servicemix-web
> servicemix-console
>
> Also I would like to bring up the idea of updating the Tooling versions so
> that they are in sync with the Core and Components (ie
> 3.0-incubating-SNAPSHOT). Currently we have a situation where we often hold
> both the ServiceMix version and the tooling version though I would think it
> would be easier to make them the same version.
>
> Philip
>
>


-- 

James
-------
http://radio.weblogs.com/0112098/

Re: Thoughts on restructuring

[Terry Cox <te...@meta-concepts.com>]

To add my bit to this idea. I am discovering that in order to develop 
components, you end up with lots of dependencies back into the 
ServiceMix project, most especially if you wish to be able to run unit 
tests that instantiate a container in order to test components. This in 
turn means that there are dependencies upon jars that are only in the 
local maven repository if the current ServiceMix snapshot has been built 
on the local machine. This obviously only occurs is you are developing 
against a snapshot, but it is still an issue.

If the Servicemix build was refactored in such a way that the core jars 
could be published independently, it would be easier to maintain a 
development team working against a snapshot release without having to 
run full builds everywhere, or try to keep a site proxy updated with all 
the bits of ServiceMix.

Terry

Re: Thoughts on restructuring

[Philip Dodds <ph...@gmail.com>]

I think what we need to do is actually break the projects up - so that there
isn't a big project for everything - in this case you would be able to build
the Core container without tooling,  then build the tooling (if you wanted
it - or wanted to build the components) and finally build the components (if
you need them).

P

On 7/12/06, Guillaume Nodet <gn...@gmail.com> wrote:
>
> +1 to refactor if anything can be made easier.
> However, there is still one problem.
> Maven hqs a limitation and we can not compile the jbi plugin and use it
> in the same build (on a clean machine).  That' s why you have to do
>   mvn -N install
>    cd tooling
>   mvn install
>   cd ..
>   mvn install
>
> to build the first time.
> I'm not sure this problem will be solved soon and the only workaround
> i see for that
> is to have different lifecycles and versions for container / tooling /
> components.
> But I think we can live with the above steps to build servicemix.
>
> Cheers,
> Guillaume Nodet
>
> On 7/7/06, Philip Dodds <ph...@gmail.com> wrote:
> > I have been wondering about the possible restructuring of the ServiceMix
> > code tree and build to enable cleaner separation,  smaller/quicker
> builds,
> > and the ability to separate out releases.
> >
> > The idea has been bounced around a bit on IRC and I wanted to put it out
> > there for peoples thoughts.
> >
> > The basic idea is to break the current single build into three discreet
> > projects,  these would be :
> >
> > ServiceMix JBI Container
> > ServiceMix Components
> > ServiceMix Tooling
> >
> > The first would be purely the JBI Container with no Service Engines or
> > Components and no tooling (it would also not require any ServiceMix
> tooling
> > to build.  Thus it would consist of the following projects:
> >
> > servicemix-core
> > servicemix-jbi
> > servicemix-services
> >
> > This would be packaged with the assembly to create a pure JBI server
> without
> > any components.
> >
> > The second would be the JBI Maven 2 Tooling that is available,  this
> would
> > also include the archetypes that we are currently putting in
> place.  These
> > are all currently Maven2 plugins and have a dependency on the ServiceMix
> > Core Container and therefore should be built second.  It would consist
> of
> > the following projects:
> >
> > jbi-maven-plugin
> > servicemix-binding-component
> > servicemix-http-consumer-service-unit
> > servicemix-http-provider-service-unit
> > servicemix-jms-consumer-service-unit
> > servicemix-jms-provider-service-unit
> > servicemix-jsr181-wsdl-first-service-unit
> > servicemix-service-assembly
> > servicemix-service-engine
> > servicemix-service-unit
> > servicemix-shared-library
> >
> > The final project would be the ServiceMix JBI Components/Shared
> Libraries
> > which is dependent on both the Core and the Tooling,  this would
> contain:
> >
> > servicemix-beanflow
> > servicemix-bpe
> > servicemix-components
> > servicemix-common
> > servicemix-eip
> > servicemix-http
> > servicemix-jms
> > servicemix-jsr181
> > servicemix-lwcontainer
> > servicemix-sca
> > servicemix-soap
> > servicemix-wsn2005
> >
> > The projects that would be left that need consideration would be :
> >
> > servicemix-web
> > servicemix-console
> >
> > Also I would like to bring up the idea of updating the Tooling versions
> so
> > that they are in sync with the Core and Components (ie
> > 3.0-incubating-SNAPSHOT). Currently we have a situation where we often
> hold
> > both the ServiceMix version and the tooling version though I would think
> it
> > would be easier to make them the same version.
> >
> > Philip
> >
> >
>

Re: Thoughts on restructuring

[Guillaume Nodet <gn...@gmail.com>]

+1 to refactor if anything can be made easier.
However, there is still one problem.
Maven hqs a limitation and we can not compile the jbi plugin and use it
in the same build (on a clean machine).  That' s why you have to do
  mvn -N install
   cd tooling
  mvn install
  cd ..
  mvn install

to build the first time.
I'm not sure this problem will be solved soon and the only workaround
i see for that
is to have different lifecycles and versions for container / tooling /
components.
But I think we can live with the above steps to build servicemix.

Cheers,
Guillaume Nodet

On 7/7/06, Philip Dodds <ph...@gmail.com> wrote:
> I have been wondering about the possible restructuring of the ServiceMix
> code tree and build to enable cleaner separation,  smaller/quicker builds,
> and the ability to separate out releases.
>
> The idea has been bounced around a bit on IRC and I wanted to put it out
> there for peoples thoughts.
>
> The basic idea is to break the current single build into three discreet
> projects,  these would be :
>
> ServiceMix JBI Container
> ServiceMix Components
> ServiceMix Tooling
>
> The first would be purely the JBI Container with no Service Engines or
> Components and no tooling (it would also not require any ServiceMix tooling
> to build.  Thus it would consist of the following projects:
>
> servicemix-core
> servicemix-jbi
> servicemix-services
>
> This would be packaged with the assembly to create a pure JBI server without
> any components.
>
> The second would be the JBI Maven 2 Tooling that is available,  this would
> also include the archetypes that we are currently putting in place.  These
> are all currently Maven2 plugins and have a dependency on the ServiceMix
> Core Container and therefore should be built second.  It would consist of
> the following projects:
>
> jbi-maven-plugin
> servicemix-binding-component
> servicemix-http-consumer-service-unit
> servicemix-http-provider-service-unit
> servicemix-jms-consumer-service-unit
> servicemix-jms-provider-service-unit
> servicemix-jsr181-wsdl-first-service-unit
> servicemix-service-assembly
> servicemix-service-engine
> servicemix-service-unit
> servicemix-shared-library
>
> The final project would be the ServiceMix JBI Components/Shared Libraries
> which is dependent on both the Core and the Tooling,  this would contain:
>
> servicemix-beanflow
> servicemix-bpe
> servicemix-components
> servicemix-common
> servicemix-eip
> servicemix-http
> servicemix-jms
> servicemix-jsr181
> servicemix-lwcontainer
> servicemix-sca
> servicemix-soap
> servicemix-wsn2005
>
> The projects that would be left that need consideration would be :
>
> servicemix-web
> servicemix-console
>
> Also I would like to bring up the idea of updating the Tooling versions so
> that they are in sync with the Core and Components (ie
> 3.0-incubating-SNAPSHOT). Currently we have a situation where we often hold
> both the ServiceMix version and the tooling version though I would think it
> would be easier to make them the same version.
>
> Philip
>
>