You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Hiram Chirino <hi...@hiramchirino.com> on 2008/06/16 20:35:18 UTC
Please Help Check the Structure of the new split out components.
Hi Everyone,
if you get a chance please review the 2 components ported over to the
new per component release structure.
Just checkout:
https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
I'm happy with it. And I'm eager to do the same for the rest of the
components in the smx3 trunk branch. Please let me know if I should
hold of in doing the rest of the components.
Should we do a release of the 2 that have been ported to test the
release process?
Regards,
Hiram
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Please Help Check the Structure of the new split out components.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
ok..
I created
https://svn.apache.org/repos/asf/servicemix/archetypes
to hold it.. basically it's a copy of the smx3 trunk archetypes..
I'll start to tweak the poms in a bit.
On Tue, Jun 17, 2008 at 4:19 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Good points. That's right that the archetypes don't change much and
> keeping them in their own project together would allow keeping the
> archetypes tests along.
>
> On Tue, Jun 17, 2008 at 9:23 AM, Gert Vanthienen
> <ge...@skynet.be> wrote:
>> L.S.,
>>
>>
>> Just two questions/remarks:
>> - We still need to add the previous.releases somewhere to get the
>> spring.schemas files to contain the necessary entries for earlier releases
>> as well. I would propose to add it to the components root pom.xml, but we
>> would have to keep the same property in the root pom.xml for the ServiceMix
>> 3 container as well (for the core and audit xsd files). - Does it make sense
>> to add the archetypes to this components hierarchy? Wouldn't it be better
>> to add them to a separate tooling/archetypes project and release all
>> archetypes in a single release but separately from their components? They
>> probably won't need to change as much as their components and we also have a
>> few archetypes that do not match any component (servicemix-project-root,
>> servicemix-binding-component, ...)
>>
>>
>> Regards,
>>
>> Gert
>>
>> Hiram Chirino wrote:
>>>
>>> Hi Everyone,
>>>
>>> if you get a chance please review the 2 components ported over to the
>>> new per component release structure.
>>>
>>> Just checkout:
>>>
>>> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>>>
>>> I'm happy with it. And I'm eager to do the same for the rest of the
>>> components in the smx3 trunk branch. Please let me know if I should
>>> hold of in doing the rest of the components.
>>>
>>> Should we do a release of the 2 that have been ported to test the
>>> release process?
>>>
>>> Regards,
>>> Hiram
>>>
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Please Help Check the Structure of the new split out components.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
I would say keep them together so that when you release a component
you release the new archetype which produces a pom.xml with a
dependency to the new component version.
Regards,
Hiram
On Tue, Jun 17, 2008 at 4:19 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> Good points. That's right that the archetypes don't change much and
> keeping them in their own project together would allow keeping the
> archetypes tests along.
>
> On Tue, Jun 17, 2008 at 9:23 AM, Gert Vanthienen
> <ge...@skynet.be> wrote:
>> L.S.,
>>
>>
>> Just two questions/remarks:
>> - We still need to add the previous.releases somewhere to get the
>> spring.schemas files to contain the necessary entries for earlier releases
>> as well. I would propose to add it to the components root pom.xml, but we
>> would have to keep the same property in the root pom.xml for the ServiceMix
>> 3 container as well (for the core and audit xsd files). - Does it make sense
>> to add the archetypes to this components hierarchy? Wouldn't it be better
>> to add them to a separate tooling/archetypes project and release all
>> archetypes in a single release but separately from their components? They
>> probably won't need to change as much as their components and we also have a
>> few archetypes that do not match any component (servicemix-project-root,
>> servicemix-binding-component, ...)
>>
>>
>> Regards,
>>
>> Gert
>>
>> Hiram Chirino wrote:
>>>
>>> Hi Everyone,
>>>
>>> if you get a chance please review the 2 components ported over to the
>>> new per component release structure.
>>>
>>> Just checkout:
>>>
>>> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>>>
>>> I'm happy with it. And I'm eager to do the same for the rest of the
>>> components in the smx3 trunk branch. Please let me know if I should
>>> hold of in doing the rest of the components.
>>>
>>> Should we do a release of the 2 that have been ported to test the
>>> release process?
>>>
>>> Regards,
>>> Hiram
>>>
>>>
>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Please Help Check the Structure of the new split out components.
Posted by Guillaume Nodet <gn...@gmail.com>.
Good points. That's right that the archetypes don't change much and
keeping them in their own project together would allow keeping the
archetypes tests along.
On Tue, Jun 17, 2008 at 9:23 AM, Gert Vanthienen
<ge...@skynet.be> wrote:
> L.S.,
>
>
> Just two questions/remarks:
> - We still need to add the previous.releases somewhere to get the
> spring.schemas files to contain the necessary entries for earlier releases
> as well. I would propose to add it to the components root pom.xml, but we
> would have to keep the same property in the root pom.xml for the ServiceMix
> 3 container as well (for the core and audit xsd files). - Does it make sense
> to add the archetypes to this components hierarchy? Wouldn't it be better
> to add them to a separate tooling/archetypes project and release all
> archetypes in a single release but separately from their components? They
> probably won't need to change as much as their components and we also have a
> few archetypes that do not match any component (servicemix-project-root,
> servicemix-binding-component, ...)
>
>
> Regards,
>
> Gert
>
> Hiram Chirino wrote:
>>
>> Hi Everyone,
>>
>> if you get a chance please review the 2 components ported over to the
>> new per component release structure.
>>
>> Just checkout:
>>
>> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>>
>> I'm happy with it. And I'm eager to do the same for the rest of the
>> components in the smx3 trunk branch. Please let me know if I should
>> hold of in doing the rest of the components.
>>
>> Should we do a release of the 2 that have been ported to test the
>> release process?
>>
>> Regards,
>> Hiram
>>
>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Please Help Check the Structure of the new split out components.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Awesome thx.
On Tue, Jun 17, 2008 at 9:09 AM, Gert Vanthienen
<ge...@skynet.be> wrote:
> Hiram,
>
> Good question! Up to now, there was no difference. This property is used
> to generate the additional entries in spring.schemas. E.g. for the 3.2.1
> release of container/components
> http://servicemix.apache.org/schema/servicemix-http-3.2.1.xsd=servicemix-http.xsd
>
> I guess we will need this property in every single component pom.xml after a
> while, with the previous releases of that single component. I had already
> added it to the component's root pom.xml, but I'll move it to both
> components' pom.xml files. For the container, we will also need this
> property to keep track of container releases -- but there we can keep it a
> single property for the entire container project.
>
> Gert
>
> Hiram Chirino wrote:
>>
>> so, should the previous.releases be set to the previous releases of
>> the components or the previous releases of the container?
>>
>> On Tue, Jun 17, 2008 at 3:23 AM, Gert Vanthienen
>> <ge...@skynet.be> wrote:
>>
>>>
>>> L.S.,
>>>
>>>
>>> Just two questions/remarks:
>>> - We still need to add the previous.releases somewhere to get the
>>> spring.schemas files to contain the necessary entries for earlier
>>> releases
>>> as well. I would propose to add it to the components root pom.xml, but
>>> we
>>> would have to keep the same property in the root pom.xml for the
>>> ServiceMix
>>> 3 container as well (for the core and audit xsd files). - Does it make
>>> sense
>>> to add the archetypes to this components hierarchy? Wouldn't it be
>>> better
>>> to add them to a separate tooling/archetypes project and release all
>>> archetypes in a single release but separately from their components?
>>> They
>>> probably won't need to change as much as their components and we also
>>> have a
>>> few archetypes that do not match any component (servicemix-project-root,
>>> servicemix-binding-component, ...)
>>>
>>>
>>> Regards,
>>>
>>> Gert
>>>
>>> Hiram Chirino wrote:
>>>
>>>>
>>>> Hi Everyone,
>>>>
>>>> if you get a chance please review the 2 components ported over to the
>>>> new per component release structure.
>>>>
>>>> Just checkout:
>>>>
>>>>
>>>> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>>>>
>>>> I'm happy with it. And I'm eager to do the same for the rest of the
>>>> components in the smx3 trunk branch. Please let me know if I should
>>>> hold of in doing the rest of the components.
>>>>
>>>> Should we do a release of the 2 that have been ported to test the
>>>> release process?
>>>>
>>>> Regards,
>>>> Hiram
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Please Help Check the Structure of the new split out components.
Posted by Gert Vanthienen <ge...@skynet.be>.
Hiram,
Good question! Up to now, there was no difference. This property is
used to generate the additional entries in spring.schemas. E.g. for the
3.2.1 release of container/components
http://servicemix.apache.org/schema/servicemix-http-3.2.1.xsd=servicemix-http.xsd
I guess we will need this property in every single component pom.xml
after a while, with the previous releases of that single component. I
had already added it to the component's root pom.xml, but I'll move it
to both components' pom.xml files. For the container, we will also need
this property to keep track of container releases -- but there we can
keep it a single property for the entire container project.
Gert
Hiram Chirino wrote:
> so, should the previous.releases be set to the previous releases of
> the components or the previous releases of the container?
>
> On Tue, Jun 17, 2008 at 3:23 AM, Gert Vanthienen
> <ge...@skynet.be> wrote:
>
>> L.S.,
>>
>>
>> Just two questions/remarks:
>> - We still need to add the previous.releases somewhere to get the
>> spring.schemas files to contain the necessary entries for earlier releases
>> as well. I would propose to add it to the components root pom.xml, but we
>> would have to keep the same property in the root pom.xml for the ServiceMix
>> 3 container as well (for the core and audit xsd files). - Does it make sense
>> to add the archetypes to this components hierarchy? Wouldn't it be better
>> to add them to a separate tooling/archetypes project and release all
>> archetypes in a single release but separately from their components? They
>> probably won't need to change as much as their components and we also have a
>> few archetypes that do not match any component (servicemix-project-root,
>> servicemix-binding-component, ...)
>>
>>
>> Regards,
>>
>> Gert
>>
>> Hiram Chirino wrote:
>>
>>> Hi Everyone,
>>>
>>> if you get a chance please review the 2 components ported over to the
>>> new per component release structure.
>>>
>>> Just checkout:
>>>
>>> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>>>
>>> I'm happy with it. And I'm eager to do the same for the rest of the
>>> components in the smx3 trunk branch. Please let me know if I should
>>> hold of in doing the rest of the components.
>>>
>>> Should we do a release of the 2 that have been ported to test the
>>> release process?
>>>
>>> Regards,
>>> Hiram
>>>
>>>
>>>
>>
>
>
>
>
Re: Please Help Check the Structure of the new split out components.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
so, should the previous.releases be set to the previous releases of
the components or the previous releases of the container?
On Tue, Jun 17, 2008 at 3:23 AM, Gert Vanthienen
<ge...@skynet.be> wrote:
> L.S.,
>
>
> Just two questions/remarks:
> - We still need to add the previous.releases somewhere to get the
> spring.schemas files to contain the necessary entries for earlier releases
> as well. I would propose to add it to the components root pom.xml, but we
> would have to keep the same property in the root pom.xml for the ServiceMix
> 3 container as well (for the core and audit xsd files). - Does it make sense
> to add the archetypes to this components hierarchy? Wouldn't it be better
> to add them to a separate tooling/archetypes project and release all
> archetypes in a single release but separately from their components? They
> probably won't need to change as much as their components and we also have a
> few archetypes that do not match any component (servicemix-project-root,
> servicemix-binding-component, ...)
>
>
> Regards,
>
> Gert
>
> Hiram Chirino wrote:
>>
>> Hi Everyone,
>>
>> if you get a chance please review the 2 components ported over to the
>> new per component release structure.
>>
>> Just checkout:
>>
>> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>>
>> I'm happy with it. And I'm eager to do the same for the rest of the
>> components in the smx3 trunk branch. Please let me know if I should
>> hold of in doing the rest of the components.
>>
>> Should we do a release of the 2 that have been ported to test the
>> release process?
>>
>> Regards,
>> Hiram
>>
>>
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Please Help Check the Structure of the new split out components.
Posted by Gert Vanthienen <ge...@skynet.be>.
L.S.,
Just two questions/remarks:
- We still need to add the previous.releases somewhere to get the
spring.schemas files to contain the necessary entries for earlier
releases as well. I would propose to add it to the components root
pom.xml, but we would have to keep the same property in the root
pom.xml for the ServiceMix 3 container as well (for the core and audit
xsd files).
- Does it make sense to add the archetypes to this components
hierarchy? Wouldn't it be better to add them to a separate
tooling/archetypes project and release all archetypes in a single
release but separately from their components? They probably won't need
to change as much as their components and we also have a few archetypes
that do not match any component (servicemix-project-root,
servicemix-binding-component, ...)
Regards,
Gert
Hiram Chirino wrote:
> Hi Everyone,
>
> if you get a chance please review the 2 components ported over to the
> new per component release structure.
>
> Just checkout:
> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>
> I'm happy with it. And I'm eager to do the same for the rest of the
> components in the smx3 trunk branch. Please let me know if I should
> hold of in doing the rest of the components.
>
> Should we do a release of the 2 that have been ported to test the
> release process?
>
> Regards,
> Hiram
>
>
Re: Please Help Check the Structure of the new split out components.
Posted by Gert Vanthienen <ge...@skynet.be>.
L.S.,
I definitely wouldn't restart versioning from 1.0 again either.
Personally, I still think our users shouldn't be bothered by the fact
that we changed something to the way our projects are organized for SMX
3.3 and above, but I get the point about avoiding interference between
3.3-SNAPSHOT and 4.0-SNAPSHOT while the move is in progress. Once the
move is done and everything is building correctly again, we can just as
well wipe out the SNAPSHOT repos and redeploy 3.3-SNAPSHOTs from our new
structure, no?
For users that upgrade from SMX3 to SMX4 in a few months, it might be
good to know that the JBI components there are still the same ol' JBI
components they've always been using. However, if people think this
change is worth bumping the version numbers to 3.5-SNAPSHOT or
4.0-SNAPSHOT, I'm perfectly fine with that as well -- the most important
thing is that we now have a means of releasing new components more
often. Nice work, Hiram and everyone else involved!
Regards,
Gert
Hiram Chirino wrote:
> Since the artifacts have already had previous releases, we cannot
> restart at 1.0 unless we rename the components and I think that would
> be even more confusing.
>
> On Fri, Jun 20, 2008 at 8:48 AM, Bruce Snyder <br...@gmail.com> wrote:
>
>> On Thu, Jun 19, 2008 at 9:25 AM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>>
>>> The way I see it is that these split out new version scheme is what's
>>> going to get used by the smx 4 container.. And based on your theory,
>>> it would confuse users if smx 4 were using smx 3 components :) AFAIK
>>> the biggest motivator to splitting out the components was so that they
>>> could get more easily used by the smx 4 distro.
>>>
>>> Plus right now the 3.3-SNAPSHOT versions are being used by the
>>> components in the smx 3 trunk branch and I did not want to step on
>>> those deployments just yet, so it's safer to use a different version
>>> number, so why not go up to 4.0-SNAPSHOT.
>>>
>> I had assumed that the components would have have their own versioning
>> beginning with 1.0 just like the ServiceMix-POM. Why would we confuse
>> SMX 3.x users by versioning the components as 4.0? The way I see it,
>> it makes the most sense to version the components completely
>> independent of either container and just begin each one at 1.0. Then
>> each component can be incremented as is necessary according to bug
>> fixes and features.
>>
>> 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 Camel - http://activemq.org/camel/
>> Apache ServiceMix - http://servicemix.org/
>>
>> Blog: http://bruceblog.org/
>>
>>
>
>
>
>
Re: Please Help Check the Structure of the new split out components.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
Since the artifacts have already had previous releases, we cannot
restart at 1.0 unless we rename the components and I think that would
be even more confusing.
On Fri, Jun 20, 2008 at 8:48 AM, Bruce Snyder <br...@gmail.com> wrote:
> On Thu, Jun 19, 2008 at 9:25 AM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> The way I see it is that these split out new version scheme is what's
>> going to get used by the smx 4 container.. And based on your theory,
>> it would confuse users if smx 4 were using smx 3 components :) AFAIK
>> the biggest motivator to splitting out the components was so that they
>> could get more easily used by the smx 4 distro.
>>
>> Plus right now the 3.3-SNAPSHOT versions are being used by the
>> components in the smx 3 trunk branch and I did not want to step on
>> those deployments just yet, so it's safer to use a different version
>> number, so why not go up to 4.0-SNAPSHOT.
>
> I had assumed that the components would have have their own versioning
> beginning with 1.0 just like the ServiceMix-POM. Why would we confuse
> SMX 3.x users by versioning the components as 4.0? The way I see it,
> it makes the most sense to version the components completely
> independent of either container and just begin each one at 1.0. Then
> each component can be incremented as is necessary according to bug
> fixes and features.
>
> 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 Camel - http://activemq.org/camel/
> Apache ServiceMix - http://servicemix.org/
>
> Blog: http://bruceblog.org/
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Please Help Check the Structure of the new split out components.
Posted by Bruce Snyder <br...@gmail.com>.
On Thu, Jun 19, 2008 at 9:25 AM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> The way I see it is that these split out new version scheme is what's
> going to get used by the smx 4 container.. And based on your theory,
> it would confuse users if smx 4 were using smx 3 components :) AFAIK
> the biggest motivator to splitting out the components was so that they
> could get more easily used by the smx 4 distro.
>
> Plus right now the 3.3-SNAPSHOT versions are being used by the
> components in the smx 3 trunk branch and I did not want to step on
> those deployments just yet, so it's safer to use a different version
> number, so why not go up to 4.0-SNAPSHOT.
I had assumed that the components would have have their own versioning
beginning with 1.0 just like the ServiceMix-POM. Why would we confuse
SMX 3.x users by versioning the components as 4.0? The way I see it,
it makes the most sense to version the components completely
independent of either container and just begin each one at 1.0. Then
each component can be incremented as is necessary according to bug
fixes and features.
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 Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/
Blog: http://bruceblog.org/
Re: Please Help Check the Structure of the new split out components.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
The way I see it is that these split out new version scheme is what's
going to get used by the smx 4 container.. And based on your theory,
it would confuse users if smx 4 were using smx 3 components :) AFAIK
the biggest motivator to splitting out the components was so that they
could get more easily used by the smx 4 distro.
Plus right now the 3.3-SNAPSHOT versions are being used by the
components in the smx 3 trunk branch and I did not want to step on
those deployments just yet, so it's safer to use a different version
number, so why not go up to 4.0-SNAPSHOT.
On Thu, Jun 19, 2008 at 3:40 AM, Gert Vanthienen
<ge...@skynet.be> wrote:
> Hiram,
>
> Just one last remark: Is there any reason why the version number on the
> components has changed to 4.0-SNAPSHOT? As long as ServiceMix 4 isn't
> available, I think this will only confuse users -- seeing components with
> version 4.0 will probably make them wonder what version of ServiceMix they
> are using with that. I would suggest to keep the version at 3.3-SNAPSHOT
> for now, as this will be the first version to contain the 'new' components.
> Wdyt?
>
> Gert
>
> Hiram Chirino wrote:
>>
>> Hi Everyone,
>>
>> if you get a chance please review the 2 components ported over to the
>> new per component release structure.
>>
>> Just checkout:
>>
>> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>>
>> I'm happy with it. And I'm eager to do the same for the rest of the
>> components in the smx3 trunk branch. Please let me know if I should
>> hold of in doing the rest of the components.
>>
>> Should we do a release of the 2 that have been ported to test the
>> release process?
>>
>> Regards,
>> Hiram
>>
>>
>
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Please Help Check the Structure of the new split out components.
Posted by Gert Vanthienen <ge...@skynet.be>.
Hiram,
Just one last remark: Is there any reason why the version number on the
components has changed to 4.0-SNAPSHOT? As long as ServiceMix 4 isn't
available, I think this will only confuse users -- seeing components
with version 4.0 will probably make them wonder what version of
ServiceMix they are using with that. I would suggest to keep the
version at 3.3-SNAPSHOT for now, as this will be the first version to
contain the 'new' components. Wdyt?
Gert
Hiram Chirino wrote:
> Hi Everyone,
>
> if you get a chance please review the 2 components ported over to the
> new per component release structure.
>
> Just checkout:
> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>
> I'm happy with it. And I'm eager to do the same for the rest of the
> components in the smx3 trunk branch. Please let me know if I should
> hold of in doing the rest of the components.
>
> Should we do a release of the 2 that have been ported to test the
> release process?
>
> Regards,
> Hiram
>
>
Re: Please Help Check the Structure of the new split out components.
Posted by Hiram Chirino <hi...@hiramchirino.com>.
ah thx. It's now there.
On Mon, Jun 16, 2008 at 3:12 PM, Guillaume Nodet <gn...@gmail.com> wrote:
> I guess you may have forgotten to check in some files.
> I can't find the servicemix-bean-pom for example.
>
> On Mon, Jun 16, 2008 at 8:35 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
>> Hi Everyone,
>>
>> if you get a chance please review the 2 components ported over to the
>> new per component release structure.
>>
>> Just checkout:
>> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>>
>> I'm happy with it. And I'm eager to do the same for the rest of the
>> components in the smx3 trunk branch. Please let me know if I should
>> hold of in doing the rest of the components.
>>
>> Should we do a release of the 2 that have been ported to test the
>> release process?
>>
>> Regards,
>> Hiram
>>
>> --
>> Regards,
>> Hiram
>>
>> Blog: http://hiramchirino.com
>>
>> Open Source SOA
>> http://open.iona.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Regards,
Hiram
Blog: http://hiramchirino.com
Open Source SOA
http://open.iona.com
Re: Please Help Check the Structure of the new split out components.
Posted by Guillaume Nodet <gn...@gmail.com>.
I guess you may have forgotten to check in some files.
I can't find the servicemix-bean-pom for example.
On Mon, Jun 16, 2008 at 8:35 PM, Hiram Chirino <hi...@hiramchirino.com> wrote:
> Hi Everyone,
>
> if you get a chance please review the 2 components ported over to the
> new per component release structure.
>
> Just checkout:
> https://svn.apache.org/repos/asf/servicemix/components/components-pom/trunk/
>
> I'm happy with it. And I'm eager to do the same for the rest of the
> components in the smx3 trunk branch. Please let me know if I should
> hold of in doing the rest of the components.
>
> Should we do a release of the 2 that have been ported to test the
> release process?
>
> Regards,
> Hiram
>
> --
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/