You make some good points Gert. I was thinking that the ServiceMix releases themselves will always contain a bundling of the latest and greatest components, much like the Eclipse Callisto release. Then we are free to update the components individually between those releases.
You might be right about not needing a single large CI build. Having a single component build only when it is changed would really cut down the overhead of our CI builds and make them more consistent. My only thought is that I would hate to be the one getting them all set up that way :-) The great thing about setting up a module with svn-externals is that we have the flexibility to checkout/build the entire component set together or as individual components. I can see both options being useful depending on what a developer is trying to accomplish. Chris On Thu, Jun 5, 2008 at 2:19 AM, Gert Vanthienen <[EMAIL PROTECTED]> wrote: > L.S., > > Perhaps we don't want to build everything in a single build script, but I > do think we should keep on providing a single-download-solution for our new > users. > Having separate release cycles for the components would be a big advantage > for new components (like servicemix-mail which isn't easily available to > users now until 3.3 has been released) and for improvements on existing > components (like all the changes that have gone in servicemix-cxf-* lately). > An existing ServiceMix user wouldn't have a problem with downloading a (new > version of) component for these use cases. > > However, in the past, new users already had problems with ServiceMix 3.1 > when they needed to install a component before being able to use it, I don't > think we want to put the burden on them to download the components they > need. You would expect an ESB to have at least a set of core components > available when you download it. We will probably have to create at least > two distributions: container only and container with a good set of > components. > For me, this doesn't mean we desperately need a single build though. Just > adding the latest, released versions of all components (which would have > been built/released independently) would be OK as well. For the CI builds, > wouldn't it be better to have seperate build definitions for every component > to avoid that a single component build failure will result in not having CI > builds for all the other components? Having a single components/trunk to > check out all components/.../trunk in a single operation (using > svn:externals) would still be a good thing for us as developers, but I'm not > convinced about the need for a single build. > > > Gert > > > > > > > > > > Lars Heinemann wrote: > >> >> >> >>> 2). Any change like the first item above breaks the ability to build all >>> of the components in a single maven build. One way to get around this is >>> to have a specific module somewhere that uses svn externals to get all >>> components so that a single build can cover all components. I think this >>> would primarily be for convenience in testing and for CI builds. I am >>> thinking that we would only need the trunk of each component. >>> >>> >>> >> --> I see no reason to build everything in one build script. Why not split >> away the components completely and let the user download them on demand? >> Most customers only use some of the components so why bother them having >> all? >> >> >> >> > > -- Chris Custine My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org
