I concur with Kit. I'm new to the ServiceMix side of things, but I believe the split has helped OpenESB. They have split off the components into a separate project entirely: http://open-jbi-components.dev.java.net (OJC) vs. http://open-esb.dev.java.net.
Then, there are even components (ours) that are developed entirely separate from that : http://sip-bc.dev.java.net http://xmpp-bc.dev.java.net http://uddi-bc.dev.java.net http://rss-bc.dev.java.net We push code into the OJC build process. In fact, we are working towards portability of those components (to ServiceMix). So we would love for a way to "contribute" those components and get them integrated into the CI/Test environment, but remain independent of the specific container and release cycles. best, brian On 7/2/07, Kit Plummer <[EMAIL PROTECTED]> wrote:
Considering the volatility of each - it would make sense to split the release cycles. As long as there is some integration/test mechanism that guarantees (or at a minimum specifies) container version interoperability this should be fine. Kit On 7/2/07, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > I'd like to start a discussion on splitting the container and > components release cycles. What do people think about that ? > Should we keep the container and all the components in a single > release like we have done so far, or should we split these releases > and release the components separately from the container ? > > -- > Cheers, > Guillaume Nodet > ------------------------ > Principal Engineer, IONA > Blog: http://gnodet.blogspot.com/ > -- Kit Plummer Nobody-in-Charge @ Black:Hole:Logic http://www.blackholelogic.com
-- Brian ONeill Source Equity (http://www.sourceequity.com) jBIZint (http://www.jbizint.org) Technical Architect, Gestalt LLC (http://www.gestalt-llc.com) mobile:215.588.6024
