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/11/28 21:43:27 UTC
Reorganizing the svn tree
I'm think about reorganizing the svn tree to be more modular.
Something like:
https://svn.apache.org/repos/asf/servicemix
* m2-repo
* sandbox
* scripts
* site
* smx3
** branches
** tags
** trunk
* smx4
** ...
This will be usefull so that we can have two trunks: one for smx3 and
another for smx4.
Basically, it's just about moving trunk/tags/branches into a subdir for
servicemix 3 related work
and create a new area for servicemix 4 work.
I'm thinking we want to make servicemix 4 more modular and release the
runtime asap, then releasing bits when they are ready (I'm thinking about
the JBI layer first, etc...). The next step is to build a usable assembly /
binary distribution which will contain all the modules at a given time.
In that direction, we could have a "bundles" subtree in smx4 which would
contain OSGified jars that other modules would need. One of the advantages
is that we can release things more often, depends on less snapshots and have
a build time much faster when you are working on a given module (when
working on the JBI layer, there's no real need to build openejb or cxf
bundles, etc..)
So the smx4 subtree would look like
smx4
* pom
** branches
** tags
** trunk
* bundles
** branches
** tags
** trunk
* runtime
** branches
** tags
** trunk
* jbi
** branches
** tags
** trunk
* ...
Even for bundles, we should release them early and independantly as working
with snapshots is always a pain imho.
In addition, splitting things would avoid lenghty builds, having failing /
unstable test impacting the whole build. Of course we would still have a
module with the whole binary distribution.
I'm thinking the main downside is that patches involving more than one
component would be more difficult to apply and would have to be splitted,
but i think it's worth it.
Thoughts, ideas ?
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Freeman Fang <fr...@iona.com>.
+1
Guillaume Nodet wrote:
> I'm think about reorganizing the svn tree to be more modular.
> Something like:
>
> https://svn.apache.org/repos/asf/servicemix
> * m2-repo
> * sandbox
> * scripts
> * site
> * smx3
> ** branches
> ** tags
> ** trunk
> * smx4
> ** ...
>
> This will be usefull so that we can have two trunks: one for smx3 and
> another for smx4.
> Basically, it's just about moving trunk/tags/branches into a subdir for
> servicemix 3 related work
> and create a new area for servicemix 4 work.
>
> I'm thinking we want to make servicemix 4 more modular and release the
> runtime asap, then releasing bits when they are ready (I'm thinking about
> the JBI layer first, etc...). The next step is to build a usable assembly /
> binary distribution which will contain all the modules at a given time.
>
> In that direction, we could have a "bundles" subtree in smx4 which would
> contain OSGified jars that other modules would need. One of the advantages
> is that we can release things more often, depends on less snapshots and have
> a build time much faster when you are working on a given module (when
> working on the JBI layer, there's no real need to build openejb or cxf
> bundles, etc..)
> So the smx4 subtree would look like
>
> smx4
> * pom
> ** branches
> ** tags
> ** trunk
> * bundles
> ** branches
> ** tags
> ** trunk
> * runtime
> ** branches
> ** tags
> ** trunk
> * jbi
> ** branches
> ** tags
> ** trunk
> * ...
>
> Even for bundles, we should release them early and independantly as working
> with snapshots is always a pain imho.
> In addition, splitting things would avoid lenghty builds, having failing /
> unstable test impacting the whole build. Of course we would still have a
> module with the whole binary distribution.
>
> I'm thinking the main downside is that patches involving more than one
> component would be more difficult to apply and would have to be splitted,
> but i think it's worth it.
>
> Thoughts, ideas ?
>
>
Re: Reorganizing the svn tree
Posted by "d.santosh" <rs...@gmail.com>.
+1
On Nov 28, 2007 5:13 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I'm think about reorganizing the svn tree to be more modular.
> Something like:
>
> https://svn.apache.org/repos/asf/servicemix
> * m2-repo
> * sandbox
> * scripts
> * site
> * smx3
> ** branches
> ** tags
> ** trunk
> * smx4
> ** ...
>
> This will be usefull so that we can have two trunks: one for smx3 and
> another for smx4.
> Basically, it's just about moving trunk/tags/branches into a subdir for
> servicemix 3 related work
> and create a new area for servicemix 4 work.
>
> I'm thinking we want to make servicemix 4 more modular and release the
> runtime asap, then releasing bits when they are ready (I'm thinking about
> the JBI layer first, etc...). The next step is to build a usable assembly
> /
> binary distribution which will contain all the modules at a given time.
>
> In that direction, we could have a "bundles" subtree in smx4 which would
> contain OSGified jars that other modules would need. One of the
> advantages
> is that we can release things more often, depends on less snapshots and
> have
> a build time much faster when you are working on a given module (when
> working on the JBI layer, there's no real need to build openejb or cxf
> bundles, etc..)
> So the smx4 subtree would look like
>
> smx4
> * pom
> ** branches
> ** tags
> ** trunk
> * bundles
> ** branches
> ** tags
> ** trunk
> * runtime
> ** branches
> ** tags
> ** trunk
> * jbi
> ** branches
> ** tags
> ** trunk
> * ...
>
> Even for bundles, we should release them early and independantly as
> working
> with snapshots is always a pain imho.
> In addition, splitting things would avoid lenghty builds, having failing /
> unstable test impacting the whole build. Of course we would still have a
> module with the whole binary distribution.
>
> I'm thinking the main downside is that patches involving more than one
> component would be more difficult to apply and would have to be splitted,
> but i think it's worth it.
>
> Thoughts, ideas ?
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
Re: Reorganizing the svn tree
Posted by James Strachan <ja...@gmail.com>.
On 05/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> Ok, i would agree if we can get them under a single groupId: all bundles
> would use the groupId: org.apache.servicemix.bundles. That way, it's easy
> to find bundles in the maven repo and allow moving them if we find the need
> at some point.
+1
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
Ok, i would agree if we can get them under a single groupId: all bundles
would use the groupId: org.apache.servicemix.bundles. That way, it's easy
to find bundles in the maven repo and allow moving them if we find the need
at some point.
On Dec 5, 2007 7:07 PM, James Strachan <ja...@gmail.com> wrote:
> On 05/12/2007, Bruce Snyder <br...@gmail.com> wrote:
> > On Dec 5, 2007 3:20 AM, James Strachan <ja...@gmail.com> wrote:
> > > On 05/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > > > That makes perfect sense. However i'm a bit worried about the
> bundles,
> > > > because lots of different components will require different bundles.
> As
> > > > soon as we want to integrate a camel component, we will need to make
> bundles
> > > > for its dependencies. I don't really see why we should release the
> runtime
> > > > to add such a bundle (which btw would not be included). So while I
> agree on
> > > > a more coarse grained separation, I would split the bundles from the
> > > > remaining of the code (it does not really involve any code, just a
> pom) so
> > > > that we can easily release bundles separatly, as once a bundle is
> released,
> > > > it will rarely require further releases. Wdyt ?
> > >
> > > Yeah I guess. Another option could be to split the bundles, those
> > > required by the runtime go in the runtime release (so mostly things
> > > like JAXB and spring dependent stuff). Then have the remaining bundles
> > > required by the components in the components release?
> > >
> > > So if, say, a new camel release comes out, you'd only need to release
> > > the components module for the new camel bundle and the camel
> > > component? (Rather than release the bundles first, then once that
> > > release is up on the public site, release the components - causing a
> > > delay of a week or two per component release).
> > >
> > > (Bad example I guess as all the jars in camel are bundles already, but
> > > I totally take your point :)
> > >
> > > Given the simplicity of the bundle stuff; am tempted to just hide 'em
> > > where they make the most sense to go (i.e .with their core dependency
> > > - runtime, jbi/nmr or components)? At least to start with - we can
> > > tinker later on if we find bundles that don't fit nicely?
> >
> > This looks to be getting pretty complex.
>
> Having 3 releases - how much simpler could you get?
>
>
> > Any way to simplify it and
> > make it more straightforward? Can't a bundle list it's dependencies
> > and versions to make all these inter-dependencies from the runtime and
> > the core bundles disappear?
>
> The bundles we're talking about are just maven projects with a
> pom.xml. The pom lists its dependencies.
>
>
> > E.g., if it comes time to release a new
> > version of the Camel bundle, can't that bundle explicitly list its
> > dependencies so there is no clash with anything in the runtime?
>
> It does.
>
> We're really just talking about the little maven projects which make
> an OSGi bundle wrapping a regular jar. e.g.
>
> http://svn.apache.org/repos/asf/servicemix/branches/servicemix-4.0/bundles/
>
> And I repeat - Camel is bad example as its already bundles. So think
> things like the jaxb-api jars.
>
> I'm just suggesting, the bundles required by the runtime should move
> there; any bundles required by components go there, any bundles
> required by JBI/NMR go there. i.e. keep the bundles with the most
> suitable release (runtime, jbi/nmr or components).
>
> Then things are actually nice and simple; we have 3 releases (runtime,
> jbi/nmr and components) and we just release the things that really
> need to be released; and if a bundle needs to be re-released (e.g. a
> new jaxb-api jar) we can often just do 1 release - rather than, say, a
> bundle release first then a runtime release second.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
Is there any need for a single root pom without any real version number, so
that all our projects inherit from it ?
It would contain the committers list, mailing lists, etc...
I guess we can easily duplicate it in the subtrees, but duplication is
usually a bad idea.
Anyway, I'll start reorganizing the svn tree monday unless someone has some
objections.
On Dec 5, 2007 7:07 PM, James Strachan <ja...@gmail.com> wrote:
> On 05/12/2007, Bruce Snyder <br...@gmail.com> wrote:
> > On Dec 5, 2007 3:20 AM, James Strachan <ja...@gmail.com> wrote:
> > > On 05/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > > > That makes perfect sense. However i'm a bit worried about the
> bundles,
> > > > because lots of different components will require different bundles.
> As
> > > > soon as we want to integrate a camel component, we will need to make
> bundles
> > > > for its dependencies. I don't really see why we should release the
> runtime
> > > > to add such a bundle (which btw would not be included). So while I
> agree on
> > > > a more coarse grained separation, I would split the bundles from the
> > > > remaining of the code (it does not really involve any code, just a
> pom) so
> > > > that we can easily release bundles separatly, as once a bundle is
> released,
> > > > it will rarely require further releases. Wdyt ?
> > >
> > > Yeah I guess. Another option could be to split the bundles, those
> > > required by the runtime go in the runtime release (so mostly things
> > > like JAXB and spring dependent stuff). Then have the remaining bundles
> > > required by the components in the components release?
> > >
> > > So if, say, a new camel release comes out, you'd only need to release
> > > the components module for the new camel bundle and the camel
> > > component? (Rather than release the bundles first, then once that
> > > release is up on the public site, release the components - causing a
> > > delay of a week or two per component release).
> > >
> > > (Bad example I guess as all the jars in camel are bundles already, but
> > > I totally take your point :)
> > >
> > > Given the simplicity of the bundle stuff; am tempted to just hide 'em
> > > where they make the most sense to go (i.e .with their core dependency
> > > - runtime, jbi/nmr or components)? At least to start with - we can
> > > tinker later on if we find bundles that don't fit nicely?
> >
> > This looks to be getting pretty complex.
>
> Having 3 releases - how much simpler could you get?
>
>
> > Any way to simplify it and
> > make it more straightforward? Can't a bundle list it's dependencies
> > and versions to make all these inter-dependencies from the runtime and
> > the core bundles disappear?
>
> The bundles we're talking about are just maven projects with a
> pom.xml. The pom lists its dependencies.
>
>
> > E.g., if it comes time to release a new
> > version of the Camel bundle, can't that bundle explicitly list its
> > dependencies so there is no clash with anything in the runtime?
>
> It does.
>
> We're really just talking about the little maven projects which make
> an OSGi bundle wrapping a regular jar. e.g.
>
> http://svn.apache.org/repos/asf/servicemix/branches/servicemix-4.0/bundles/
>
> And I repeat - Camel is bad example as its already bundles. So think
> things like the jaxb-api jars.
>
> I'm just suggesting, the bundles required by the runtime should move
> there; any bundles required by components go there, any bundles
> required by JBI/NMR go there. i.e. keep the bundles with the most
> suitable release (runtime, jbi/nmr or components).
>
> Then things are actually nice and simple; we have 3 releases (runtime,
> jbi/nmr and components) and we just release the things that really
> need to be released; and if a bundle needs to be re-released (e.g. a
> new jaxb-api jar) we can often just do 1 release - rather than, say, a
> bundle release first then a runtime release second.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by James Strachan <ja...@gmail.com>.
On 05/12/2007, Bruce Snyder <br...@gmail.com> wrote:
> On Dec 5, 2007 3:20 AM, James Strachan <ja...@gmail.com> wrote:
> > On 05/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > > That makes perfect sense. However i'm a bit worried about the bundles,
> > > because lots of different components will require different bundles. As
> > > soon as we want to integrate a camel component, we will need to make bundles
> > > for its dependencies. I don't really see why we should release the runtime
> > > to add such a bundle (which btw would not be included). So while I agree on
> > > a more coarse grained separation, I would split the bundles from the
> > > remaining of the code (it does not really involve any code, just a pom) so
> > > that we can easily release bundles separatly, as once a bundle is released,
> > > it will rarely require further releases. Wdyt ?
> >
> > Yeah I guess. Another option could be to split the bundles, those
> > required by the runtime go in the runtime release (so mostly things
> > like JAXB and spring dependent stuff). Then have the remaining bundles
> > required by the components in the components release?
> >
> > So if, say, a new camel release comes out, you'd only need to release
> > the components module for the new camel bundle and the camel
> > component? (Rather than release the bundles first, then once that
> > release is up on the public site, release the components - causing a
> > delay of a week or two per component release).
> >
> > (Bad example I guess as all the jars in camel are bundles already, but
> > I totally take your point :)
> >
> > Given the simplicity of the bundle stuff; am tempted to just hide 'em
> > where they make the most sense to go (i.e .with their core dependency
> > - runtime, jbi/nmr or components)? At least to start with - we can
> > tinker later on if we find bundles that don't fit nicely?
>
> This looks to be getting pretty complex.
Having 3 releases - how much simpler could you get?
> Any way to simplify it and
> make it more straightforward? Can't a bundle list it's dependencies
> and versions to make all these inter-dependencies from the runtime and
> the core bundles disappear?
The bundles we're talking about are just maven projects with a
pom.xml. The pom lists its dependencies.
> E.g., if it comes time to release a new
> version of the Camel bundle, can't that bundle explicitly list its
> dependencies so there is no clash with anything in the runtime?
It does.
We're really just talking about the little maven projects which make
an OSGi bundle wrapping a regular jar. e.g.
http://svn.apache.org/repos/asf/servicemix/branches/servicemix-4.0/bundles/
And I repeat - Camel is bad example as its already bundles. So think
things like the jaxb-api jars.
I'm just suggesting, the bundles required by the runtime should move
there; any bundles required by components go there, any bundles
required by JBI/NMR go there. i.e. keep the bundles with the most
suitable release (runtime, jbi/nmr or components).
Then things are actually nice and simple; we have 3 releases (runtime,
jbi/nmr and components) and we just release the things that really
need to be released; and if a bundle needs to be re-released (e.g. a
new jaxb-api jar) we can often just do 1 release - rather than, say, a
bundle release first then a runtime release second.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Reorganizing the svn tree
Posted by Bruce Snyder <br...@gmail.com>.
On Dec 5, 2007 3:20 AM, James Strachan <ja...@gmail.com> wrote:
> On 05/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > That makes perfect sense. However i'm a bit worried about the bundles,
> > because lots of different components will require different bundles. As
> > soon as we want to integrate a camel component, we will need to make bundles
> > for its dependencies. I don't really see why we should release the runtime
> > to add such a bundle (which btw would not be included). So while I agree on
> > a more coarse grained separation, I would split the bundles from the
> > remaining of the code (it does not really involve any code, just a pom) so
> > that we can easily release bundles separatly, as once a bundle is released,
> > it will rarely require further releases. Wdyt ?
>
> Yeah I guess. Another option could be to split the bundles, those
> required by the runtime go in the runtime release (so mostly things
> like JAXB and spring dependent stuff). Then have the remaining bundles
> required by the components in the components release?
>
> So if, say, a new camel release comes out, you'd only need to release
> the components module for the new camel bundle and the camel
> component? (Rather than release the bundles first, then once that
> release is up on the public site, release the components - causing a
> delay of a week or two per component release).
>
> (Bad example I guess as all the jars in camel are bundles already, but
> I totally take your point :)
>
> Given the simplicity of the bundle stuff; am tempted to just hide 'em
> where they make the most sense to go (i.e .with their core dependency
> - runtime, jbi/nmr or components)? At least to start with - we can
> tinker later on if we find bundles that don't fit nicely?
This looks to be getting pretty complex. Any way to simplify it and
make it more straightforward? Can't a bundle list it's dependencies
and versions to make all these inter-dependencies from the runtime and
the core bundles disappear? E.g., if it comes time to release a new
version of the Camel bundle, can't that bundle explicitly list its
dependencies so there is no clash with anything in the runtime?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
http://bruceblog.org/
Re: Reorganizing the svn tree
Posted by James Strachan <ja...@gmail.com>.
On 05/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> That makes perfect sense. However i'm a bit worried about the bundles,
> because lots of different components will require different bundles. As
> soon as we want to integrate a camel component, we will need to make bundles
> for its dependencies. I don't really see why we should release the runtime
> to add such a bundle (which btw would not be included). So while I agree on
> a more coarse grained separation, I would split the bundles from the
> remaining of the code (it does not really involve any code, just a pom) so
> that we can easily release bundles separatly, as once a bundle is released,
> it will rarely require further releases. Wdyt ?
Yeah I guess. Another option could be to split the bundles, those
required by the runtime go in the runtime release (so mostly things
like JAXB and spring dependent stuff). Then have the remaining bundles
required by the components in the components release?
So if, say, a new camel release comes out, you'd only need to release
the components module for the new camel bundle and the camel
component? (Rather than release the bundles first, then once that
release is up on the public site, release the components - causing a
delay of a week or two per component release).
(Bad example I guess as all the jars in camel are bundles already, but
I totally take your point :)
Given the simplicity of the bundle stuff; am tempted to just hide 'em
where they make the most sense to go (i.e .with their core dependency
- runtime, jbi/nmr or components)? At least to start with - we can
tinker later on if we find bundles that don't fit nicely?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
That makes perfect sense. However i'm a bit worried about the bundles,
because lots of different components will require different bundles. As
soon as we want to integrate a camel component, we will need to make bundles
for its dependencies. I don't really see why we should release the runtime
to add such a bundle (which btw would not be included). So while I agree on
a more coarse grained separation, I would split the bundles from the
remaining of the code (it does not really involve any code, just a pom) so
that we can easily release bundles separatly, as once a bundle is released,
it will rarely require further releases. Wdyt ?
On Dec 5, 2007 10:11 AM, James Strachan <ja...@gmail.com> wrote:
> On 04/12/2007, Bruce Snyder <br...@gmail.com> wrote:
> > On Dec 4, 2007 3:19 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > > I've finished writing the wiki page wrt to the smx4 subtree at
> > > http://cwiki.apache.org/confluence/display/SMX4/SVN+repo
> > >
> > > Feedback welcome.
> >
> > Regarding the two choices for the SMX 4 SVN repo, I'm starting to ask
> > myself the same question I always do when something starts to become a
> > little more complex than it feels like it should be: Is there an
> > easier way? IOW, what's the easiest route to take here? IMO, it's
> > probably more straightforward to give each component it's own
> > branches/tags/trunk dir. We don't want to cram everything into a
> > single dir tree and hide the complexities of building in the POMs.
>
> Releases are a major bit of work to complete (and a PITA :); so I'm a
> little nervous about having too many separate releases, trunks and
> different branches.
>
> So I'm wondering about trying to minimise releases into these parts...
>
> (i) parent, core bundles (for jaxb and stuff) and runtime
> (ii) nmr & jbi support
> (iii) components, tools and the full SMX distro
>
> Then (ii) depends on (i) and (iii) depends on (i) and (ii) (though a
> component may only depend on (i) I guess).
>
> In the early days I see (i) and (ii) releasing frequently, but (i)
> should become stable & not need many releases soon, as will (ii) some
> time after that and then eventually we'll mostly put our efforts into
> releasing (iii).
>
> Eventually the main reason for releasing (i) and (ii) will mostly be
> minor patches and changes to core dependencies like spring versions
> etc.
>
> Hopefully this split will help make releasing easier (less to build &
> test). We could always split things up or aggregate them together
> further down the line if we think it makes sense - but given the large
> amount of effort & documentation required for each release I'd rather
> us have slightly less released parts than too many.
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by James Strachan <ja...@gmail.com>.
On 04/12/2007, Bruce Snyder <br...@gmail.com> wrote:
> On Dec 4, 2007 3:19 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > I've finished writing the wiki page wrt to the smx4 subtree at
> > http://cwiki.apache.org/confluence/display/SMX4/SVN+repo
> >
> > Feedback welcome.
>
> Regarding the two choices for the SMX 4 SVN repo, I'm starting to ask
> myself the same question I always do when something starts to become a
> little more complex than it feels like it should be: Is there an
> easier way? IOW, what's the easiest route to take here? IMO, it's
> probably more straightforward to give each component it's own
> branches/tags/trunk dir. We don't want to cram everything into a
> single dir tree and hide the complexities of building in the POMs.
Releases are a major bit of work to complete (and a PITA :); so I'm a
little nervous about having too many separate releases, trunks and
different branches.
So I'm wondering about trying to minimise releases into these parts...
(i) parent, core bundles (for jaxb and stuff) and runtime
(ii) nmr & jbi support
(iii) components, tools and the full SMX distro
Then (ii) depends on (i) and (iii) depends on (i) and (ii) (though a
component may only depend on (i) I guess).
In the early days I see (i) and (ii) releasing frequently, but (i)
should become stable & not need many releases soon, as will (ii) some
time after that and then eventually we'll mostly put our efforts into
releasing (iii).
Eventually the main reason for releasing (i) and (ii) will mostly be
minor patches and changes to core dependencies like spring versions
etc.
Hopefully this split will help make releasing easier (less to build &
test). We could always split things up or aggregate them together
further down the line if we think it makes sense - but given the large
amount of effort & documentation required for each release I'd rather
us have slightly less released parts than too many.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Reorganizing the svn tree
Posted by Bruce Snyder <br...@gmail.com>.
On Dec 4, 2007 3:19 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I've finished writing the wiki page wrt to the smx4 subtree at
> http://cwiki.apache.org/confluence/display/SMX4/SVN+repo
>
> Feedback welcome.
Regarding the two choices for the SMX 4 SVN repo, I'm starting to ask
myself the same question I always do when something starts to become a
little more complex than it feels like it should be: Is there an
easier way? IOW, what's the easiest route to take here? IMO, it's
probably more straightforward to give each component it's own
branches/tags/trunk dir. We don't want to cram everything into a
single dir tree and hide the complexities of building in the POMs.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
http://bruceblog.org/
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
I've finished writing the wiki page wrt to the smx4 subtree at
http://cwiki.apache.org/confluence/display/SMX4/SVN+repo
Feedback welcome.
On Dec 4, 2007 4:21 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Dec 4, 2007 2:29 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> > Well, plugins use a prefix. In our case the prefix servicemix/
> > is mapped to a url in the plugin configuration.
> > servicemix/ => http://svn.apache.org/repos/asf/servicemix/
> >
> > So, when we move, we can just change to the following:
> > servicemix/ => http://svn.apache.org/repos/asf/servicemix/smx3/
> > and create a new one:
> > smx4/ => http://svn.apache.org/repos/asf/servicemix/smx4/
> >
> > It shoudl work without any problems.
>
> Nice find! This is what we needed.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
>
> http://bruceblog.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Bruce Snyder <br...@gmail.com>.
On Dec 4, 2007 2:29 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Well, plugins use a prefix. In our case the prefix servicemix/
> is mapped to a url in the plugin configuration.
> servicemix/ => http://svn.apache.org/repos/asf/servicemix/
>
> So, when we move, we can just change to the following:
> servicemix/ => http://svn.apache.org/repos/asf/servicemix/smx3/
> and create a new one:
> smx4/ => http://svn.apache.org/repos/asf/servicemix/smx4/
>
> It shoudl work without any problems.
Nice find! This is what we needed.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
http://bruceblog.org/
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
Yeah, good idea.
On Dec 4, 2007 11:50 AM, James Strachan <ja...@gmail.com> wrote:
> On 04/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > Well, plugins use a prefix. In our case the prefix servicemix/
> > is mapped to a url in the plugin configuration.
> > servicemix/ => http://svn.apache.org/repos/asf/servicemix/
> >
> > So, when we move, we can just change to the following:
> > servicemix/ => http://svn.apache.org/repos/asf/servicemix/smx3/
> > and create a new one:
> > smx4/ => http://svn.apache.org/repos/asf/servicemix/smx4/
> >
> > It shoudl work without any problems.
>
> Awesome! :)
>
> I guess when we start documenting ServiceMix 4 we should maybe be
> aware of possible splits in the codebase - so we should maybe use
> different prefixes like smx-runtime, smx-jbi, smx-registry etc. Then
> as we move stuff around we can fix up the svn links etc
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by James Strachan <ja...@gmail.com>.
On 04/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> Well, plugins use a prefix. In our case the prefix servicemix/
> is mapped to a url in the plugin configuration.
> servicemix/ => http://svn.apache.org/repos/asf/servicemix/
>
> So, when we move, we can just change to the following:
> servicemix/ => http://svn.apache.org/repos/asf/servicemix/smx3/
> and create a new one:
> smx4/ => http://svn.apache.org/repos/asf/servicemix/smx4/
>
> It shoudl work without any problems.
Awesome! :)
I guess when we start documenting ServiceMix 4 we should maybe be
aware of possible splits in the codebase - so we should maybe use
different prefixes like smx-runtime, smx-jbi, smx-registry etc. Then
as we move stuff around we can fix up the svn links etc
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, plugins use a prefix. In our case the prefix servicemix/
is mapped to a url in the plugin configuration.
servicemix/ => http://svn.apache.org/repos/asf/servicemix/
So, when we move, we can just change to the following:
servicemix/ => http://svn.apache.org/repos/asf/servicemix/smx3/
and create a new one:
smx4/ => http://svn.apache.org/repos/asf/servicemix/smx4/
It shoudl work without any problems.
On Dec 4, 2007 10:21 AM, James Strachan <ja...@gmail.com> wrote:
> On 04/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> > I've just fixed the snippets by reconfiguring the snippet plugin, so it
> will
> > be easy to do that again if/when we move the smx3 trunk.
>
> Awesome!
>
> I was gonna suggest we come up with some kinda mechanism to allow us
> to do redirects and stuff as we move stuff around - but it looks like
> you've figured out a solution anyway :)
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> Open Source Integration
> http://open.iona.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by James Strachan <ja...@gmail.com>.
On 04/12/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> I've just fixed the snippets by reconfiguring the snippet plugin, so it will
> be easy to do that again if/when we move the smx3 trunk.
Awesome!
I was gonna suggest we come up with some kinda mechanism to allow us
to do redirects and stuff as we move stuff around - but it looks like
you've figured out a solution anyway :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
I've just fixed the snippets by reconfiguring the snippet plugin, so it will
be easy to do that again if/when we move the smx3 trunk.
On Dec 4, 2007 8:52 AM, Guillaume Nodet <gn...@gmail.com> wrote:
>
>
> On Dec 4, 2007 12:11 AM, Bruce Snyder <br...@gmail.com> wrote:
>
> > On Dec 3, 2007 3:49 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > > I've created http://cwiki.apache.org/confluence/display/SMX4/SVN+repo.
> > > I'm proposing to apply the first described step so that smx4 has its
> > own
> > > trunk.
> > > How we organize the smx4 tree has still be to fleshed out.
> >
> > I agree that SMX 4 should have it's own trunk, but i'm worried about
> > moving SMX 3 because it will break all SVN URLs like the one here:
> >
> >
> > http://servicemix.apache.org/servicemix-321.html#ServiceMix3.2.1-SVNTagCheckout
>
>
> Thinking about it a bit more, i'm more worried about the code snippets in
> the wiki rather than these URLs.
> Changing the code snippets would require a full review of the web site.
> Actually, I think they are already broken by the move of the repo out of the
> incubator area. As they all use a prefix, maybe we can change its value
> easily and create another one for smx4, so that we don't have to touch all
> the snippets.
>
>
> > <http://servicemix.apache.org/servicemix-321.html#ServiceMix3.2.1-SVNTagCheckout>
> >
> > Any suggestions on how we might leave such URLs intact so that
> > requests to the old URL will just forward to the new URL? Otherwise,
> > we should go back through the website and update all SVN URLs. The
> > only solution I know of is mod_rewrite and AFAIK we can't do that at
> > the ASF. Maybe it's just worth it to update all URLs in the wiki.
>
>
> The problem is that we can't rewrite svn urls afaik. We can do that for
> the web site and do redirects etc... but not for SVN imho.
>
>
> >
> >
> > Bruce
> > --
> > perl -e 'print
> > unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> > );'
> >
> > Apache ActiveMQ - http://activemq.org/
> > Apache ServiceMix - http://servicemix.org/
> > Apache Geronimo - http://geronimo.apache.org/
> >
> > http://bruceblog.org/
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
On Dec 4, 2007 12:11 AM, Bruce Snyder <br...@gmail.com> wrote:
> On Dec 3, 2007 3:49 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> > I've created http://cwiki.apache.org/confluence/display/SMX4/SVN+repo.
> > I'm proposing to apply the first described step so that smx4 has its own
> > trunk.
> > How we organize the smx4 tree has still be to fleshed out.
>
> I agree that SMX 4 should have it's own trunk, but i'm worried about
> moving SMX 3 because it will break all SVN URLs like the one here:
>
>
> http://servicemix.apache.org/servicemix-321.html#ServiceMix3.2.1-SVNTagCheckout
Thinking about it a bit more, i'm more worried about the code snippets in
the wiki rather than these URLs.
Changing the code snippets would require a full review of the web site.
Actually, I think they are already broken by the move of the repo out of the
incubator area. As they all use a prefix, maybe we can change its value
easily and create another one for smx4, so that we don't have to touch all
the snippets.
>
> <http://servicemix.apache.org/servicemix-321.html#ServiceMix3.2.1-SVNTagCheckout>
>
> Any suggestions on how we might leave such URLs intact so that
> requests to the old URL will just forward to the new URL? Otherwise,
> we should go back through the website and update all SVN URLs. The
> only solution I know of is mod_rewrite and AFAIK we can't do that at
> the ASF. Maybe it's just worth it to update all URLs in the wiki.
The problem is that we can't rewrite svn urls afaik. We can do that for the
web site and do redirects etc... but not for SVN imho.
>
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
>
> http://bruceblog.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Bruce Snyder <br...@gmail.com>.
On Dec 3, 2007 3:49 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I've created http://cwiki.apache.org/confluence/display/SMX4/SVN+repo.
> I'm proposing to apply the first described step so that smx4 has its own
> trunk.
> How we organize the smx4 tree has still be to fleshed out.
I agree that SMX 4 should have it's own trunk, but i'm worried about
moving SMX 3 because it will break all SVN URLs like the one here:
http://servicemix.apache.org/servicemix-321.html#ServiceMix3.2.1-SVNTagCheckout
Any suggestions on how we might leave such URLs intact so that
requests to the old URL will just forward to the new URL? Otherwise,
we should go back through the website and update all SVN URLs. The
only solution I know of is mod_rewrite and AFAIK we can't do that at
the ASF. Maybe it's just worth it to update all URLs in the wiki.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
http://bruceblog.org/
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
I've created http://cwiki.apache.org/confluence/display/SMX4/SVN+repo.
I'm proposing to apply the first described step so that smx4 has its own
trunk.
How we organize the smx4 tree has still be to fleshed out.
On Dec 1, 2007 4:15 AM, Bruce Snyder <br...@gmail.com> wrote:
> On Nov 30, 2007 12:41 PM, Guillaume Nodet <gn...@gmail.com> wrote:
>
> > Sounds good. I don't much troubles for ServiceMix 3.x users (as a simple
> svn
> > switch should be enough),
>
> Yeah, that's true. I forgot that we're not reorganizing the SMX 3 SVN
> tree right now. My main concern was how a reorganization would affect
> the SMX release process and distribution.
>
> > and I doubt there are lots of ServiceMix 4 users
> > around here... But we can formalize things a bit more.
>
> I think it's worth describing the SVN tree in a wiki page so that
> users know what lives where.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Bruce Snyder <br...@gmail.com>.
On Nov 30, 2007 12:41 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> Sounds good. I don't much troubles for ServiceMix 3.x users (as a simple svn
> switch should be enough),
Yeah, that's true. I forgot that we're not reorganizing the SMX 3 SVN
tree right now. My main concern was how a reorganization would affect
the SMX release process and distribution.
> and I doubt there are lots of ServiceMix 4 users
> around here... But we can formalize things a bit more.
I think it's worth describing the SVN tree in a wiki page so that
users know what lives where.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
On Nov 30, 2007 7:54 PM, Bruce Snyder <br...@gmail.com> wrote:
> On Nov 30, 2007 3:29 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> > It seems there's no major objections, so I will start moving the svn
> tree
> > for servicemix 3 and servicemix 4 on monday, though I won't touch the
> smx4
> > tree now (just move it). We can talk about the exact smx4 tree at a
> later
> > time.
> > If there are any objections please speak now!
>
> I think it would be wise to draw up a plan on the wiki for this before
> doing the changes. Mainly because I think it's *highly* important to
> understand how this will affect the release process and therefore the
> ServiceMix end users. Only then can we adequately convey the changes
> to the ServiceMix user base - but this should all happen before the
> changes take place. We need to tell them exactly what is going to
> happen, why it's going to happen and how it will affect them before,
> during and after all this work occurs.
>
Sounds good. I don't much troubles for ServiceMix 3.x users (as a simple svn
switch should be enough), and I doubt there are lots of ServiceMix 4 users
around here... But we can formalize things a bit more.
>
> It shouldn't be too difficult to do this and I'm glad to help.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Bruce Snyder <br...@gmail.com>.
On Nov 30, 2007 3:29 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> It seems there's no major objections, so I will start moving the svn tree
> for servicemix 3 and servicemix 4 on monday, though I won't touch the smx4
> tree now (just move it). We can talk about the exact smx4 tree at a later
> time.
> If there are any objections please speak now!
I think it would be wise to draw up a plan on the wiki for this before
doing the changes. Mainly because I think it's *highly* important to
understand how this will affect the release process and therefore the
ServiceMix end users. Only then can we adequately convey the changes
to the ServiceMix user base - but this should all happen before the
changes take place. We need to tell them exactly what is going to
happen, why it's going to happen and how it will affect them before,
during and after all this work occurs.
It shouldn't be too difficult to do this and I'm glad to help.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
It seems there's no major objections, so I will start moving the svn tree
for servicemix 3 and servicemix 4 on monday, though I won't touch the smx4
tree now (just move it). We can talk about the exact smx4 tree at a later
time.
If there are any objections please speak now!
On Nov 28, 2007 9:43 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I'm think about reorganizing the svn tree to be more modular.
> Something like:
>
> https://svn.apache.org/repos/asf/servicemix
> * m2-repo
> * sandbox
> * scripts
> * site
> * smx3
> ** branches
> ** tags
> ** trunk
> * smx4
> ** ...
>
> This will be usefull so that we can have two trunks: one for smx3 and
> another for smx4.
> Basically, it's just about moving trunk/tags/branches into a subdir for
> servicemix 3 related work
> and create a new area for servicemix 4 work.
>
> I'm thinking we want to make servicemix 4 more modular and release the
> runtime asap, then releasing bits when they are ready (I'm thinking about
> the JBI layer first, etc...). The next step is to build a usable assembly /
> binary distribution which will contain all the modules at a given time.
>
> In that direction, we could have a "bundles" subtree in smx4 which would
> contain OSGified jars that other modules would need. One of the advantages
> is that we can release things more often, depends on less snapshots and have
> a build time much faster when you are working on a given module (when
> working on the JBI layer, there's no real need to build openejb or cxf
> bundles, etc..)
> So the smx4 subtree would look like
>
> smx4
> * pom
> ** branches
> ** tags
> ** trunk
> * bundles
> ** branches
> ** tags
> ** trunk
> * runtime
> ** branches
> ** tags
> ** trunk
> * jbi
> ** branches
> ** tags
> ** trunk
> * ...
>
> Even for bundles, we should release them early and independantly as
> working with snapshots is always a pain imho.
> In addition, splitting things would avoid lenghty builds, having failing /
> unstable test impacting the whole build. Of course we would still have a
> module with the whole binary distribution.
>
> I'm thinking the main downside is that patches involving more than one
> component would be more difficult to apply and would have to be splitted,
> but i think it's worth it.
>
> Thoughts, ideas ?
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Nov 28, 2007, at 3:43 PM, Guillaume Nodet wrote:
> I'm think about reorganizing the svn tree to be more modular.
> Something like:
>
> https://svn.apache.org/repos/asf/servicemix
> * m2-repo
> * sandbox
> * scripts
> * site
> * smx3
> ** branches
> ** tags
> ** trunk
> * smx4
> ** ...
Geronimo is going this way and it is working out for us and makes life
a bit simpler. +1
Re: Reorganizing the svn tree
Posted by James Strachan <ja...@gmail.com>.
+1 on the reorg.
I was wondering if it might make things a bit easier to put the
features/bundles/runtimes/parent pom specifying versions of things
like spring, osgi, camel and stuff - in a single 'runtime' release,
then release it whenever we need to. Apart from the runtime parts,
most of the rest of it (bundles / features / parent pom) is mostly
just pom/version stuff so we can release frequently.
e.g. we have spring+osgi in the core and wanna release it whenever
those things change; so having the bundles & runtime together might
reduce the amount of releasing we have to do a bit.
On 29/11/2007, Guillaume Nodet <gn...@gmail.com> wrote:
> On Nov 29, 2007 4:58 AM, Bruce Snyder <br...@gmail.com> wrote:
[snip]
> > Also, on a slightly different note, the SMX 4 runtime is going to be
> > based on OSGi, how will this affect the ability to embed SMX into
> > another Java application? I don't imagine that folks will always want
> > an OSGi container running inside of their Java app, so how will we
> > work around this to still allow it to be embedded?
>
>
> There are two ways of doing that: the first one is to simply embed the OSGi
> runtime in the application (a web app or not). It's quite easy to do and I
> do not see any problems. I see that as the easiest way because the changes
> would be minimal, as you would just get rid of things like the file poller
> which automatically installs bundles etc...
> The other way is to just use the jars and remove all OSGi stuff. The NMR
> api has no dependency on OSGi and OSGi is mostly used through spring for
> wiring everything, for classloaders and for deployment. If you want to
> embed ServiceMix in your app, just use spring to wire all you need together.
I've been struggling a bit lately to get stuff to work inside OSGi; am
sure I'm not alone and that others will hit this too - it can take a
while to get all the OSGi metadata aligned just right so that things
actually deploy.
So I'm wondering if the ServiceMix Runtime could also support the
'flat class loader model' approach too. (i.e. a single lib directory
with a bunch of regular jars in it and one ClassLoader boots 'em all
up on startup).
This wouldn't deal well with hot redeployment or anything; we'd just
start the whole JVM up, if things change, we kill it and restart the
JVM - but it would offer a nice simple model for users who don't need
hierarchal class loaders and hot-redeployment and so forth.
(Am not sure if we could make a lib directory of jars appear like a
single OSGi bundle or something).
It'd be good to make sure we can use ServiceMix runtime with OSGi or
with a simple lib dir of jars.
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://open.iona.com
Re: Reorganizing the svn tree
Posted by Guillaume Nodet <gn...@gmail.com>.
On Nov 29, 2007 4:58 AM, Bruce Snyder <br...@gmail.com> wrote:
> On 11/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
> > I'm think about reorganizing the svn tree to be more modular.
> > Something like:
> >
> > https://svn.apache.org/repos/asf/servicemix
> > * m2-repo
> > * sandbox
> > * scripts
> > * site
> > * smx3
> > ** branches
> > ** tags
> > ** trunk
> > * smx4
> > ** ...
> >
> > This will be usefull so that we can have two trunks: one for smx3 and
> > another for smx4.
> > Basically, it's just about moving trunk/tags/branches into a subdir for
> > servicemix 3 related work
> > and create a new area for servicemix 4 work.
> >
> > I'm thinking we want to make servicemix 4 more modular and release the
> > runtime asap, then releasing bits when they are ready (I'm thinking
> about
> > the JBI layer first, etc...). The next step is to build a usable
> assembly /
> > binary distribution which will contain all the modules at a given time.
> >
> > In that direction, we could have a "bundles" subtree in smx4 which would
> > contain OSGified jars that other modules would need. One of the
> advantages
> > is that we can release things more often, depends on less snapshots and
> have
> > a build time much faster when you are working on a given module (when
> > working on the JBI layer, there's no real need to build openejb or cxf
> > bundles, etc..)
> > So the smx4 subtree would look like
> >
> > smx4
> > * pom
> > ** branches
> > ** tags
> > ** trunk
> > * bundles
> > ** branches
> > ** tags
> > ** trunk
> > * runtime
> > ** branches
> > ** tags
> > ** trunk
> > * jbi
> > ** branches
> > ** tags
> > ** trunk
> > * ...
>
> +1
>
> At a high level this looks much more manageable. In SMX 4, I
> understand that the bundles, jbi and runtime dirs will each have their
> own branches, tags and trunk dirs. But what are the branches, tags and
> trunk dirs beneath the root pom? Will the full uber distribution live
> there? I think it shoudl have it's own dir containing its own
> branches, tags and trunk dirs.
I'm not sure if we really need the pom subtree. My idea is that we are in
need of
a root pom that all modules will inherit. It will contain basic
informations such as the mailing lists, licenses, etc... Not much really,
but we still need it.
>
>
> > Even for bundles, we should release them early and independantly as
> working
> > with snapshots is always a pain imho.
> > In addition, splitting things would avoid lenghty builds, having failing
> /
> > unstable test impacting the whole build. Of course we would still have
> a
> > module with the whole binary distribution.
> >
> > I'm thinking the main downside is that patches involving more than one
> > component would be more difficult to apply and would have to be
> splitted,
> > but i think it's worth it.
>
> At a high level, I still like this idea. But I still have some
> concerns about allowing users to fall victim to dependency hell. So
> how exactly are components going to be downloaded to run on the core
> runtime? Will there be an automatic facility for this?
I think we have to release a full distribution from time to time so that
users can get started easily.
That said, we need to find a way of downloading and installing 'features'
easily. This will be done through the shell console, using either OBR or
pax-runner, or any other easy to use mechanism.
This means that one would type (for example)
obr/install apache-ode:1.2
and it would install everything needed.
Then we need to provide offline tools to create distribution ready to use
for a given environmnent, where all the needed modules would be packaged in
a single zip.
>
> Also, on a slightly different note, the SMX 4 runtime is going to be
> based on OSGi, how will this affect the ability to embed SMX into
> another Java application? I don't imagine that folks will always want
> an OSGi container running inside of their Java app, so how will we
> work around this to still allow it to be embedded?
There are two ways of doing that: the first one is to simply embed the OSGi
runtime in the application (a web app or not). It's quite easy to do and I
do not see any problems. I see that as the easiest way because the changes
would be minimal, as you would just get rid of things like the file poller
which automatically installs bundles etc...
The other way is to just use the jars and remove all OSGi stuff. The NMR
api has no dependency on OSGi and OSGi is mostly used through spring for
wiring everything, for classloaders and for deployment. If you want to
embed ServiceMix in your app, just use spring to wire all you need together.
>
> Bruce
> --
> perl -e 'print
> unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
> );'
>
> Apache ActiveMQ - http://activemq.org/
> Apache ServiceMix - http://servicemix.org/
> Apache Geronimo - http://geronimo.apache.org/
> Castor - http://castor.org/
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Reorganizing the svn tree
Posted by Bruce Snyder <br...@gmail.com>.
On 11/28/07, Guillaume Nodet <gn...@gmail.com> wrote:
> I'm think about reorganizing the svn tree to be more modular.
> Something like:
>
> https://svn.apache.org/repos/asf/servicemix
> * m2-repo
> * sandbox
> * scripts
> * site
> * smx3
> ** branches
> ** tags
> ** trunk
> * smx4
> ** ...
>
> This will be usefull so that we can have two trunks: one for smx3 and
> another for smx4.
> Basically, it's just about moving trunk/tags/branches into a subdir for
> servicemix 3 related work
> and create a new area for servicemix 4 work.
>
> I'm thinking we want to make servicemix 4 more modular and release the
> runtime asap, then releasing bits when they are ready (I'm thinking about
> the JBI layer first, etc...). The next step is to build a usable assembly /
> binary distribution which will contain all the modules at a given time.
>
> In that direction, we could have a "bundles" subtree in smx4 which would
> contain OSGified jars that other modules would need. One of the advantages
> is that we can release things more often, depends on less snapshots and have
> a build time much faster when you are working on a given module (when
> working on the JBI layer, there's no real need to build openejb or cxf
> bundles, etc..)
> So the smx4 subtree would look like
>
> smx4
> * pom
> ** branches
> ** tags
> ** trunk
> * bundles
> ** branches
> ** tags
> ** trunk
> * runtime
> ** branches
> ** tags
> ** trunk
> * jbi
> ** branches
> ** tags
> ** trunk
> * ...
+1
At a high level this looks much more manageable. In SMX 4, I
understand that the bundles, jbi and runtime dirs will each have their
own branches, tags and trunk dirs. But what are the branches, tags and
trunk dirs beneath the root pom? Will the full uber distribution live
there? I think it shoudl have it's own dir containing its own
branches, tags and trunk dirs.
> Even for bundles, we should release them early and independantly as working
> with snapshots is always a pain imho.
> In addition, splitting things would avoid lenghty builds, having failing /
> unstable test impacting the whole build. Of course we would still have a
> module with the whole binary distribution.
>
> I'm thinking the main downside is that patches involving more than one
> component would be more difficult to apply and would have to be splitted,
> but i think it's worth it.
At a high level, I still like this idea. But I still have some
concerns about allowing users to fall victim to dependency hell. So
how exactly are components going to be downloaded to run on the core
runtime? Will there be an automatic facility for this?
Also, on a slightly different note, the SMX 4 runtime is going to be
based on OSGi, how will this affect the ability to embed SMX into
another Java application? I don't imagine that folks will always want
an OSGi container running inside of their Java app, so how will we
work around this to still allow it to be embedded?
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: Reorganizing the svn tree
Posted by Rob Davies <ra...@gmail.com>.
+1
On Nov 28, 2007, at 8:43 PM, Guillaume Nodet wrote:
> I'm think about reorganizing the svn tree to be more modular.
> Something like:
>
> https://svn.apache.org/repos/asf/servicemix
> * m2-repo
> * sandbox
> * scripts
> * site
> * smx3
> ** branches
> ** tags
> ** trunk
> * smx4
> ** ...
>
> This will be usefull so that we can have two trunks: one for smx3 and
> another for smx4.
> Basically, it's just about moving trunk/tags/branches into a subdir
> for
> servicemix 3 related work
> and create a new area for servicemix 4 work.
>
> I'm thinking we want to make servicemix 4 more modular and release the
> runtime asap, then releasing bits when they are ready (I'm thinking
> about
> the JBI layer first, etc...). The next step is to build a usable
> assembly /
> binary distribution which will contain all the modules at a given
> time.
>
> In that direction, we could have a "bundles" subtree in smx4 which
> would
> contain OSGified jars that other modules would need. One of the
> advantages
> is that we can release things more often, depends on less snapshots
> and have
> a build time much faster when you are working on a given module (when
> working on the JBI layer, there's no real need to build openejb or cxf
> bundles, etc..)
> So the smx4 subtree would look like
>
> smx4
> * pom
> ** branches
> ** tags
> ** trunk
> * bundles
> ** branches
> ** tags
> ** trunk
> * runtime
> ** branches
> ** tags
> ** trunk
> * jbi
> ** branches
> ** tags
> ** trunk
> * ...
>
> Even for bundles, we should release them early and independantly as
> working
> with snapshots is always a pain imho.
> In addition, splitting things would avoid lenghty builds, having
> failing /
> unstable test impacting the whole build. Of course we would still
> have a
> module with the whole binary distribution.
>
> I'm thinking the main downside is that patches involving more than one
> component would be more difficult to apply and would have to be
> splitted,
> but i think it's worth it.
>
> Thoughts, ideas ?
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/