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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > >
