servicemix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <gert.vanthie...@gmail.com>
Subject Re: [DISCUSS] ServiceMix 5.0.0
Date Fri, 18 Feb 2011 11:54:57 GMT
L.S.,

I've summarized the basic ideas for these two versions in
https://cwiki.apache.org/confluence/display/SM/Roadmap -- we probably
want to elaborate the NMR and tooling ideas for 5.0.0 a bit more
before we go ahead and change SVN layouts/names of projects/..., but
at least this gives us something to go by.

I think it would be wise to schedule the 4.4.0 release somewhere close
after the Camel 2.7.0 release - we usually get people asking on the
mailing list about upgrading to the next version of Camel as soon as
it's available and this would also force us to do a new release
sooner.  We really want to get rid of these long release cycles and
release things more often.  However, we also want to do something
about the release process itself imho ...

For the next release, I'd like to try an all-in-one release instead of
doing the submodule releases one after the other.  The latter approach
has caused the current 4.3.0 release chain to run for almost 3 months
now, with the initial utils release being done in November so it got
outdated and everything needed to be started over again a month ago.
Doing it all in one go might be a better way - I don't mind
volunteering for the next release round to give that a go myself (just
in case it ends up to be a bad idea while I'm doing it ;)).  If
something is wrong with the release during the vote using this
approach, we can always re-cut the faulty bits and just reuse the
existing tags for the release:perform of the other bits) so I don't
think it will cause a lot of extra work even if the vote gets canceled
a few times).

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/



On Fri, Feb 18, 2011 at 10:12 AM, Jean-Baptiste Onofré <jb@nanthrax.net> wrote:
> Thanks Guillaume for your answer.
> It's exactly in the following way as the discussion we had in October during
> Fuse Community Day.
>
> I'm totally agree regarding the survey, it's a good idea to get feedback
> from the community and the end-users.
>
> For ServiceMix GL (ex-NMR), we can start to write down and discuss the
> features coverage (QoS, remoting/farming capability including instances
> sync, ServiceLocator, BPM extension and registry (WSDL for ODE, Activiti
> registry, etc), custom registries (ETL jobs definition, MDM data storage,
> etc), etc.
> It will show to the crowd that ServiceMix spaceship IS NOT JBI, it's largely
> more than that :)
> I'm sure that some users could think that these features could be part of
> others projects (like CXF, ActiveMQ or Camel), but I think that ServiceMix
> GL is more transverse and could be glue between these projects.
>
> I'm working on SMX 3.3.3 and 4.3.0 today, I will create the wiki page
> tomorrow (I would like to work on SMX documentation and web site too).
>
> Thanks
> Regards
> JB
>
> On 02/17/2011 04:22 PM, Guillaume Nodet wrote:
>>
>> I agree with your description of 4.4, I would maybe add drop support
>> for jdk 1.5 and maven 2.x too though.
>>
>> For ServiceMix 5, I think things are still a bit blurry.  We discussed
>> a while back about a survey for ServiceMix users.  I think before
>> making any firm plans / roadmap, we should start by asking our users
>> some feedback.  I think FuseSource would happily pay for it and
>> reusing the same host than the CXF and Camel communities did sounds
>> like a good idea to me.  This would give us a good idea or where we
>> should focus -- but I fear documentation will be the first and most
>> important point ;-)   I'll start another thread about that as I really
>> think now is a good time to do it (or at least just after 4.3 is out).
>>
>> That said, I think ServiceMix 5 should definitely be more modular, so
>> leveraging whatever comes from Karaf 3 for features / kar / and ease
>> of building custom distributions would definitely be welcomed.  We
>> need to be able to provide very easily tailored distributions for
>> simple integration, web services, bpel, without being this big thing
>> that some people think servicemix is.
>>
>> On the NMR point, we discussed that back a few months ago too, and I
>> think you're right.  We definitely need to enhance the NMR layer (or
>> whatever we will call it) to provide built-in support for clustering.
>> In addition this remoting capatiblity, the NMR is currently the best
>> way to integrate WSDL based tools such as ODE (as Kurt pointed), so
>> the registry part could play a big role here, especially in a
>> clustered environment.  Though we need to be very careful here as we
>> already tried twice (with flows in smx3 and the clustering engine in
>> smx4) and both have severe limitations that we need to overcome.
>>
>> On Wed, Feb 16, 2011 at 22:25, Jean-Baptiste Onofré<jb@nanthrax.net>
>>  wrote:
>>>
>>> Hi all,
>>>
>>> As you know, ServiceMix 4.3.0 release has been submitted to VOTE. If it's
>>> fine, the release will be available before the end of this week.
>>> In the mean time, I'm testing ServiceMix 3 (especially around Components)
>>> to
>>> be able to submit ServiceMix 3.3.3 release to vote tonight or tomorrow
>>> morning.
>>>
>>> It's time to deal with the ServiceMix roadmap :)
>>>
>>> I think it makes sense to prepare ServiceMix 4.4.0 with the following
>>> enhancements:
>>> - powered by Karaf 2.2.0
>>> - dependencies upgrade: Aries 0.3, Camel 2.7 (depending of the timing),
>>> CXF
>>> 2.3.3, etc
>>> - bug fixing in ServiceMix modules: components, utils, specs, NMR.
>>> - features improving (avoid to override tiers features such as the Camel
>>> one)
>>> - build improving (especially around the add-features-to-repo goal and
>>> dependency set).
>>> - documentation and website. It's known issue. Before releasing
>>> ServiceMix
>>> 4.4.0, the documentation should be improved. Some of us are already
>>> involved
>>> (especially Gert), but we need to be in commando mode for this important
>>> task.
>>> To summarize, ServiceMix 4.4.0 will be a maintenance release, mainly
>>> containing bug fixed and dependencies update.
>>
>>
>>> Anyway, I think that we need to prepare the next major ServiceMix
>>> release:
>>> ServiceMix 5.0.0.
>>> I would like to split the discussion in three parts:
>>> 1/ Architecture/Design update
>>> As discussed before, JBI support should set as deprecated but only
>>> available
>>> as optional feature.
>>> Regarding this, I deeply think that NMR is a really plus value module.
>>> Too much people are thinking that ServiceMix 4 NMR is only the JBI
>>> implementation support in ServiceMix. It's too restrictive.
>>> NMR could have a key role in ServiceMix. I've some ideas in mind:
>>> - better relationship between NMR and Camel
>>> - generic clustering/farming/clouding support
>>> - transaction/distributed transaction
>>> - service registry and service locator
>>> - etc
>>> I'm quite sure that lot of us have others ideas :)
>>> I propose to create a roadmap page in the ServiceMix wiki to discuss of
>>> that
>>> and draft the future architecture of the NMR and ServiceMix 5.
>>> 2/ Tooling
>>> We're all agree that our integrated modules are rock solid: karaf, nmr,
>>> camel, cxf, etc.
>>> Of course, we have to provide new features, improve some parts, etc.
>>> There's
>>> no discuss around that.
>>> However, I think that we need to provide some tooling. I don't talk about
>>> killer tool to do every thing, but at least, some tool to increase the
>>> adoption of ServiceMix for the production administrator.
>>> For instance, just a clean console for monitoring and simple management
>>> of
>>> ServiceMix will provide a good start for administrator.
>>> Maybe I'm wrong, but I think that ServiceMix is really great for a
>>> developer
>>> and an integration team. However, I'm quite sure that the administrator
>>> (the
>>> same guy who uses the WebSphere or Weblogic console) is expecting a
>>> simple
>>> console for monitoring a production running environment.
>>> 3/ Infra update
>>> The current svn repo organization is not very flexible.
>>> The smx4 repo module should be rename in smx.
>>> In this module the features module should be renamed as runtime.
>>>
>>> It means that we will have:
>>> - smx3 for ServiceMix 3 (maintenance reason)
>>> - smx (moved from smx4)
>>> -- bundles
>>> -- specs
>>> -- nmr
>>> -- obr
>>> -- runtime
>>>
>>> WDYT ?
>>>
>>> Thanks all
>>> Regards
>>> JB
>>>
>>
>>
>>
>

Mime
View raw message