You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/07/02 16:56:31 UTC

[DISCUSS] Split container and components release cycles ?

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/

Re: [DISCUSS] Split container and components release cycles ?

Posted by Terry Cox <te...@meta-concepts.com>.
> If we go that way, how could we deal with the examples ?
> I guess they would either require the use to download the components,
> or be available on a separate distros (and thus have their own
> release cycle too). 

Ideally needs a Maven-like dependency management system for components 
so that you can declare the versions that you need and they are 
downloaded from a repository and installed.

-- 
Terry

Re: [DISCUSS] Split container and components release cycles ?

Posted by Eduardo Burgos <eb...@gmail.com>.
I vote for not splitting releases. The way it is now, we dont need to worry
about versions as everything is the same number. External components (like
Apache Ode) have their own versions already so...



On 7/3/07, Guillaume Nodet <gn...@gmail.com> wrote:
>
> I was mainly refering to the examples that come with the default
> distribution of
> ServiceMix.  The distribution includes the container, some configuration
> files,
> JBI components and demos.
>
> We already have some TCK stuff which is not available publicly due to the
> need
> for an NDA mainly.
>
> But I agree with you on the test harness, integration tests and all.
>
> On 7/3/07, Kit Plummer <ki...@gmail.com> wrote:
> > On 7/3/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > > If we go that way, how could we deal with the examples ?
> > > I guess they would either require the use to download the components,
> > > or be available on a separate distros (and thus have their own
> > > release cycle too).
> > >
> > > On 7/2/07, Guillaume Nodet <gn...@gmail.com> 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/
> > > >
> > >
> > >
> > > --
> > > Cheers,
> > > Guillaume Nodet
> > > ------------------------
> > > Principal Engineer, IONA
> > > Blog: http://gnodet.blogspot.com/
> > >
> >
> > Testing the integration of multiple components?  Is this what you mean
> > by examples Guillaume?
> >
> > Yes, this could be tricky.   There needs to be a JBI TCKish thing,
> > that can evaluate BCs, SEs and SAs too.  Something that can validate
> > compliance...
> >
> > I realize this is probably a bit off-track from where the division
> > discussion was going - but, in the end there needs to be a way to
> > ensure components work - without a manual integration.  Test cases can
> > handle some of the load - say for "stock" components.  But, it will
> > most likely be up to the component developers to do the testing (and
> > it would be nice if there was  an easy "test harness" to drop the
> > component in to to validate.
> >
> > Kit
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>

Re: [DISCUSS] Split container and components release cycles ?

Posted by Guillaume Nodet <gn...@gmail.com>.
I was mainly refering to the examples that come with the default
distribution of
ServiceMix.  The distribution includes the container, some configuration files,
JBI components and demos.

We already have some TCK stuff which is not available publicly due to the need
for an NDA mainly.

But I agree with you on the test harness, integration tests and all.

On 7/3/07, Kit Plummer <ki...@gmail.com> wrote:
> On 7/3/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > If we go that way, how could we deal with the examples ?
> > I guess they would either require the use to download the components,
> > or be available on a separate distros (and thus have their own
> > release cycle too).
> >
> > On 7/2/07, Guillaume Nodet <gn...@gmail.com> 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/
> > >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Principal Engineer, IONA
> > Blog: http://gnodet.blogspot.com/
> >
>
> Testing the integration of multiple components?  Is this what you mean
> by examples Guillaume?
>
> Yes, this could be tricky.   There needs to be a JBI TCKish thing,
> that can evaluate BCs, SEs and SAs too.  Something that can validate
> compliance...
>
> I realize this is probably a bit off-track from where the division
> discussion was going - but, in the end there needs to be a way to
> ensure components work - without a manual integration.  Test cases can
> handle some of the load - say for "stock" components.  But, it will
> most likely be up to the component developers to do the testing (and
> it would be nice if there was  an easy "test harness" to drop the
> component in to to validate.
>
> Kit
>


-- 
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Split container and components release cycles ?

Posted by Kit Plummer <ki...@gmail.com>.
On 7/3/07, Guillaume Nodet <gn...@gmail.com> wrote:
> If we go that way, how could we deal with the examples ?
> I guess they would either require the use to download the components,
> or be available on a separate distros (and thus have their own
> release cycle too).
>
> On 7/2/07, Guillaume Nodet <gn...@gmail.com> 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/
> >
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Principal Engineer, IONA
> Blog: http://gnodet.blogspot.com/
>

Testing the integration of multiple components?  Is this what you mean
by examples Guillaume?

Yes, this could be tricky.   There needs to be a JBI TCKish thing,
that can evaluate BCs, SEs and SAs too.  Something that can validate
compliance...

I realize this is probably a bit off-track from where the division
discussion was going - but, in the end there needs to be a way to
ensure components work - without a manual integration.  Test cases can
handle some of the load - say for "stock" components.  But, it will
most likely be up to the component developers to do the testing (and
it would be nice if there was  an easy "test harness" to drop the
component in to to validate.

Kit

Re: [DISCUSS] Split container and components release cycles ?

Posted by Guillaume Nodet <gn...@gmail.com>.
If we go that way, how could we deal with the examples ?
I guess they would either require the use to download the components,
or be available on a separate distros (and thus have their own
release cycle too).

On 7/2/07, Guillaume Nodet <gn...@gmail.com> 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/
>


-- 
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Split container and components release cycles ?

Posted by Kit Plummer <ki...@gmail.com>.
On 7/6/07, Bruce Snyder <br...@gmail.com> wrote:
> On 7/2/07, Guillaume Nodet <gn...@gmail.com> 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 ?
>
> Given the growing size of the distribution
>
> The first issue I worry is making sure that the container version can
> handle a particular component version. This can probably be remedied
> by adding some type of version check method down in the
> AsynBaseLifeCycle
>
> The second issue I worry about are the examples that ship with the
> distribution, i.e., basic, bridge, file, loan-broker,  servicemix-web,
> ws-sec and wsdl-first. How will we manage appropriate versions of
> these for the components that they use? I suppose the easiest way to
> manage this is to keep the examples with the container.

I believe this was Guillaume's concern as well.  What you've described
as a core set of components should accommodate this versioning issue.
>
> A third issue we should consider is how users will download the
> container and each separate component. It would probably behoove us to
> continue to release a container distribution with what we identify as
> a core set of components that will always be included in the SMX
> distribution. This will help to minimize the pain that newbies might
> experience in the separate downloads. That and we need to improve the
> documentation to include a step-by-step walk through of getting
> started - I can't stress this enough. (We need documentation
> contributions in bad way!).

Agree completely.  The SMX documentation is quite bad - not
necessarily in content or quantity - but, organization.  Any authors
out there?

I actually find the Wiki format to be pretty painful.  It's usefulness
is solely around capturing continuity - not in presentation.

If the documentation is organized well, and tooling exists - I see a
point where you can check/uncheck components from select lists - and
maybe even a maturity scale.  Anyone ever use jEdit?

>
> Lastly, I think that some experimentation is needed to prove this out.
> I wouldn't advise carrying this out for the next release. We should
> take some time to prove this out and allow folks to test out not only
> the software, but also the new docs that state how to go about using
> this new style of distribution.

For sure.  This dialog is a good start.  OpenESB is worth looking at too.

Re: [DISCUSS] Split container and components release cycles ?

Posted by Guillaume Nodet <gn...@gmail.com>.
I agree that we need to deal with these points somehow, but I think we
already have the problem: we do not ship Ode, yet the examples use it.
Maybe one solution would be to have extensions that could be
downloaded and installed easily in one click from the console. If
library versionning is handled correctly, we sould not have to worry
about compatibility .
I think both points could be handled by using OSGi, provided that we
make sure that the components are independent from the container.

On 7/6/07, Bruce Snyder <br...@gmail.com> wrote:
> On 7/2/07, Guillaume Nodet <gn...@gmail.com> 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 ?
>
> Given the growing size of the distribution
>
> The first issue I worry is making sure that the container version can
> handle a particular component version. This can probably be remedied
> by adding some type of version check method down in the
> AsynBaseLifeCycle
>
> The second issue I worry about are the examples that ship with the
> distribution, i.e., basic, bridge, file, loan-broker,  servicemix-web,
> ws-sec and wsdl-first. How will we manage appropriate versions of
> these for the components that they use? I suppose the easiest way to
> manage this is to keep the examples with the container.
>
> A third issue we should consider is how users will download the
> container and each separate component. It would probably behoove us to
> continue to release a container distribution with what we identify as
> a core set of components that will always be included in the SMX
> distribution. This will help to minimize the pain that newbies might
> experience in the separate downloads. That and we need to improve the
> documentation to include a step-by-step walk through of getting
> started - I can't stress this enough. (We need documentation
> contributions in bad way!).
>
> Lastly, I think that some experimentation is needed to prove this out.
> I wouldn't advise carrying this out for the next release. We should
> take some time to prove this out and allow folks to test out not only
> the software, but also the new docs that state how to go about using
> this new style of distribution.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache Geronimo - http://geronimo.apache.org/
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Castor - http://castor.org/
>


-- 
Cheers,
Guillaume Nodet
------------------------
Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Split container and components release cycles ?

Posted by Bruce Snyder <br...@gmail.com>.
On 7/2/07, Guillaume Nodet <gn...@gmail.com> 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 ?

Given the growing size of the distribution

The first issue I worry is making sure that the container version can
handle a particular component version. This can probably be remedied
by adding some type of version check method down in the
AsynBaseLifeCycle

The second issue I worry about are the examples that ship with the
distribution, i.e., basic, bridge, file, loan-broker,  servicemix-web,
ws-sec and wsdl-first. How will we manage appropriate versions of
these for the components that they use? I suppose the easiest way to
manage this is to keep the examples with the container.

A third issue we should consider is how users will download the
container and each separate component. It would probably behoove us to
continue to release a container distribution with what we identify as
a core set of components that will always be included in the SMX
distribution. This will help to minimize the pain that newbies might
experience in the separate downloads. That and we need to improve the
documentation to include a step-by-step walk through of getting
started - I can't stress this enough. (We need documentation
contributions in bad way!).

Lastly, I think that some experimentation is needed to prove this out.
I wouldn't advise carrying this out for the next release. We should
take some time to prove this out and allow folks to test out not only
the software, but also the new docs that state how to go about using
this new style of distribution.

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

Apache Geronimo - http://geronimo.apache.org/
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Castor - http://castor.org/

Re: [DISCUSS] Split container and components release cycles ?

Posted by Thomas Termin <tt...@blue-elephant-systems.com>.
I think it is a good idea! But it might be hard to test eventually.

Cheers,
Thomas

Guillaume Nodet 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 ?
> 


Re: [DISCUSS] Split container and components release cycles ?

Posted by Brian O'Neill <bo...@alumni.brown.edu>.
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 <ki...@gmail.com> 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 <gn...@gmail.com> 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

Re: [DISCUSS] Split container and components release cycles ?

Posted by Kit Plummer <ki...@gmail.com>.
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 <gn...@gmail.com> 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

Re: [DISCUSS] Split container and components release cycles ?

Posted by Terry Cox <te...@meta-concepts.com>.
I think it would certainly help to drill out some of the general 
component lifecycle management issues.

-- 
Terry