Hi If the DSL changes is very small then it's more or less just search/replace - splitter => split etc.
I think it's overkill to create a 2nd .jar with the old stuff. How should we maintain this? /Claus Ibsen Apache Camel Committer Blog: http://davsclaus.blogspot.com/ On Fri, Nov 21, 2008 at 7:08 PM, Hiram Chirino <[EMAIL PROTECTED]> wrote: > ah.. gotcha.. but then you could not incrementally migrate projects. > I.e. Ihave 500 old camel routes.. and I want to migrate 50 of them > for the next version of my app.. > > On Fri, Nov 21, 2008 at 1:01 PM, Hadrian Zbarcea <[EMAIL PROTECTED]> wrote: >> The idea is to move it to a different jar, not a different package, to >> maintain backwards compatibility. >> >> Comments and ideas always welcome! >> >> Hadrian >> >> On Nov 21, 2008, at 12:55 PM, raulvk wrote: >> >>> Hi, I was just following this thread and even though I am not a >>> committer I thought it would be OK if I put it my 2 cents... >>> Don't you think that moving the old noun-based DSL to a different >>> package than the current one would defeat the purpose of >>> backward-compatibility? If this was done, I believe that all current >>> code would still need to be changed to reference the newly package >>> that contains the old DSL, therefore disarming the >>> backward-compatibility of this solution... >>> >>> Am I right? >>> >>> 2008/11/21 Hadrian Zbarcea <[EMAIL PROTECTED]>: >>>> >>>> Interesting idea, but in that case, I'd rather put the old ones in a >>>> separate package. Or put both dsls in separate jars (and use one or the >>>> other). >>>> >>>> >>>> On Nov 21, 2008, at 12:23 PM, Hiram Chirino wrote: >>>> >>>>> I'm not sure how backward compatible we want to remain. It could be >>>>> possible to put the new java DSL route builders in a new package or >>>>> class so that it is possible to one day provide a backward >>>>> compatibility support. Not that we have to do that day 1 of the 2.0 >>>>> release.. >>>>> >>>>> What do you think? >>>>> >>>>> >>>>> On Fri, Nov 21, 2008 at 8:38 AM, Jon Anstey <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> Agreed. We shouldn't even be thinking of keeping two sets of DSL >>>>>> methods >>>>>> for >>>>>> the 2.0 release, would be too messy. I'd say go for it! >>>>>> >>>>>> BTW we've been keeping track of API breaks in the 2.0.0 release notes >>>>>> just >>>>>> so users are aware of this >>>>>> http://cwiki.apache.org/confluence/display/CAMEL/Camel+2.0.0+Release >>>>>> >>>>>> On Fri, Nov 21, 2008 at 4:26 AM, Willem Jiang >>>>>> <[EMAIL PROTECTED]>wrote: >>>>>> >>>>>>> Hi >>>>>>> >>>>>>> In the CAMEL-64[1], we are talking about using the verbs for EIP >>>>>>> actions. >>>>>>> Current Camel's DSL and Spring configruation file are using noun to >>>>>>> define the routing rules. >>>>>>> >>>>>>> Such as >>>>>>> from(seda:a).throttler(10).to(mock:result); >>>>>>> >>>>>>> <camelContext id="camel" >>>>>>> xmlns="http://activemq.apache.org/camel/schema/spring";> >>>>>>> <route> >>>>>>> <from uri="seda:a" /> >>>>>>> <throttler maximumRequestsPerPeriod="3" timePeriodMillis="30000"> >>>>>>> <to uri="mock:result" /> >>>>>>> </throttler> >>>>>>> </route> >>>>>>> </camelContext> >>>>>>> >>>>>>> it will be better if we make DSL like this >>>>>>> from(seda:a).throttle(10).to(mock:result); >>>>>>> >>>>>>> As we discussed in the JIRA, it is impossible to make the Spring >>>>>>> schema >>>>>>> support old nuns and new verbs at same time. >>>>>>> >>>>>>> Since we are working on Camel 2.0, it will be painless if we directly >>>>>>> move on to use the verbs instead of still supporting nuns in DSL and >>>>>>> Spring configuration. >>>>>>> >>>>>>> Any thoughts ? >>>>>>> >>>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-64 >>>>>>> >>>>>>> Willem >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> Jon >>>>>> >>>>>> http://janstey.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Hiram >>>>> >>>>> Blog: http://hiramchirino.com >>>>> >>>>> Open Source SOA >>>>> http://open.iona.com >>>> >>>> >> >> > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > > Open Source SOA > http://open.iona.com >
