On Thu, Jun 5, 2008 at 1:18 AM, Lars Heinemann <[EMAIL PROTECTED]> wrote:
> On Thursday 05 June 2008 07:29:27 Chris Custine wrote: > > Following up on this old thread, I have started to experiment with > > separating the SMX3 components into their own projects locally and I have > > some more details to review. If anyone has anything else to add feel > free > > to add your thoughts. These ideas below are just intended to start the > > discussion... > > > > 1). I have assumed that we would want each component to have its own > > trunk/branches/tags structure in SVN in order to do releases for each > > component separately. > > Example: > > -> components > > -> bindings > > -> servicemix-cxf-bc > > -> trunk > > -> branches > > -> tags > > -> servicemix-file > > -> trunk > > -> branches > > -> tags > > -> servicemix-ftp > > -> trunk > > -> branches > > -> tags > > -> ... > > -> serviceengines > > -> servicemix-bean > > -> trunk > > -> branches > > -> tags > > -> servicemix-camel > > -> trunk > > -> branches > > -> tags > > -> servicemix-cxf-se > > -> trunk > > -> branches > > -> tags > > -> ... > > > > This seems logical in order to avoid creating an entire release of > > ServiceMix when all we need is a specific fix for a single component. > Does > > anyone have specific opinions on this or suggestions for different > > names/structure? > > > --> Agreed. This would be a good structure. But as Bruce already mentioned, > the serviceengines name should be shortened. Yep, oversight on my part. > > > > > 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? > The single build module that includes all components would simply be a convenience for developers and CI build servers. Components would certainly be maintained, released and distributed separately from one another. > > > > 3). Because the components are going to be separate from any SMX > version, > > we will need some strategy for testing the components against SMX3 or > SMX4 > > or both in the same build (I am thinking we could use profiles). The > real > > question is how to do this now that the components will live on their > own. > > Ideas are welcomed... > > > --> No real idea here. The use of profiles sounds logical imho. > > > This is going to be an interesting process, so any feedback is welcome. > > > > Chris > > > > > > <http://directory.apache.org> > > > -- Chris Custine My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org
