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 <[EMAIL PROTECTED]> 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 <[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 > > -- James ------- http://radio.weblogs.com/0112098/
