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
On 7/6/07, Bruce Snyder [EMAIL PROTECTED] wrote:
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
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
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
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
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
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 [EMAIL PROTECTED] wrote:
I was mainly refering to the examples
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:
