You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Bruce Snyder <br...@gmail.com> on 2007/12/01 04:15:26 UTC
Re: Reorganizing the svn tree
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 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/