camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hadrian Zbarcea <hzbar...@gmail.com>
Subject Re: [DISCUSS] - Trunk as Camel 3.0
Date Mon, 26 Sep 2011 14:08:32 GMT
A couple of RC releases would work.

Hadrian


On 09/26/2011 09:37 AM, Claus Ibsen wrote:
> On Mon, Sep 26, 2011 at 2:45 PM, Christian Schneider
> <chris@die-schneider.net>  wrote:
>> Am 26.09.2011 14:02, schrieb Claus Ibsen:
>>>
>>> On Mon, Sep 26, 2011 at 1:17 PM, Christian Schneider
>>> <chris@die-schneider.net>    wrote:
>>>>
>>>> Yes there are probably some undocumented changes. The question is though
>>>> if
>>>> they would hit anyone. That is why I would like to do a release candidate
>>>> for 2.9. So
>>>> people can try to run their projects with the refactorings and we can
>>>> even
>>>> react before the first official 2.9 release.
>>>>
>>> With the current state of trunk as Camel 2.9.0, then I actually share
>>> a view to release early to give the community a chance to give it a
>>> spin.
>>> Also because Camel 2.9.0 is *not* going to be like any other regular
>>> minor releases we usually do.
>>>
>>> So doing 1-2 RC releases could be a good thing for the community.
>>
>> Sounds good.
>>>
>>>
>>>
>>>> About the SPI changes I propose
>>>> (https://issues.apache.org/jira/browse/CAMEL-4475). This would of course
>>>> be
>>>> a breaking change for anyone who actually uses these interfaces. The
>>>> questions is though how many people
>>>> would be hit. If you look closely at the interfaces then Policy is the
>>>> only
>>>> one that is really likely to be used. The Debugger is probably also used
>>>> especially for tests. These were the only two points where I had to do
>>>> changes outside of camel-core to get the tests working.
>>>>
>>> The SPI package is used for integrating interceptors
>>> (InterceptStrategy) as well as Policy, which is more common used.
>>>
>>> The Debugger API is a recent addition which allows you to debug from
>>> unit tests (as a kind of poor mans debugger), as
>>> well it allows 3rd party to build tooling for Camel in this area which
>>> people in the community ask for.
>>> How to get insight and debug their Camel apps. See for example that
>>> survey.
>>> You could even create an interactive debugger in Karaf Plugin, or have
>>> some integration from the Camel web console etc.
>>>
>>> I agree that this is a fairly new addition, and not so much used, so
>>> if it was *only* this area that was affected. Then we may
>>> be able to go ahead.
>>>
>>> But interceptors is used much more by people, and I am not keen on
>>> breaking those APIs.
>>>
>>> I guess there is no way to have support for both in the SPI, so we
>>> have the old API, as well as any new API?
>>>
>>>
>>
>> We can have both versions but it is quite tricky to do it well.
>>
>> For example spi.Policy. To keep compatiblity I can not rename or change the
>> existing interface. So I have to find a name and place for the new version.
>>
>> Possible solutions:
>> 1. spi.NewPolicy
>> 2. spi.policy.Policy
>>
>> I donĀ“t like the first solution whatever it is called. It would only make
>> sense if we found a better name for it which I doubt.
>>
>
> Yeah I cannot at first hand see any obvious good solution. Introducing
> a NewXXX seems like a big temporary solution, as the NewXXX eventually
> will replace the old API. So when this happens people have to migrate
> yet another time.
>
>
>
>> The second solution is better. If we find a good package name where a subset
>> of the interfaces can go it can make sense. Still I am not sure about it.
>>
>
> The spi is a good package name. If there is a better package name for
> the future, then that could be a solution.
> As the existing spi, and the new package can co-exists.
>
>
>> So if it is only a problem for very few people then I would opt for simply
>> doing an incompatible change. But this is a really difficult question.
>>
>
> Interceptors is used a fair bit. So its not just a few people.
>
>> Then there is the DSL like:
>> from("").policy(myPolicy)
>>
>> There we could support methods for the old and new interface so that should
>> be easy. I think we could use an Adaptor from the old interface to the new
>> interface to minimize code changes.
>>
>
> Okay what if the SPI / model stays as is for Camel 2.9.
> But having clearly notice in the release notes, javadoc etc. that
> there is changes planned.
>
>
> Then for Camel 2.10 we can possible look into some sort of adaptor solution.
> Maybe as a camel-adapter JAR you need to include on the classpath.
> Which has the old API, and delegates to invoke the new API.
>
> But again I don't know a good solution. Just throwing up a ball in the air.
>
>
>
>
>> So the biggest problem is the naming and placing. I am open for any
>> suggestions.
>>
>> Christian
>>
>> --
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>>
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>>
>>
>
>
>

Mime
View raw message