Hi Adrian, +1 to all points. Regarding 4, the generation in every build has been dropped due to 1), so IMO it should be reenabled once a reliable mechanism for regeneration is available. Regarding support for Java5, I also believe its time to move on.
The 2.0 branch is now considered experimental and is more or less a dead end right now. However, once the OModel refactoring allows for more stable backward compatibility, we can start merging features back from the experimental branch. I have started investigating the OModel refactoring by using Jackson 2.0 annotations some while ago [1] but I'm still unclear how this can be reliably tested (in a proof sense). Its difficult to compare syntactical different models for semantic equivalence... advice here is also appreciated. Otherwise we could move on and go by trial and error. Thanks, Tammo [1] https://github.com/vanto/ode-omodel-jackson-experiments On Mon, Nov 12, 2012 at 10:44 PM, Hadrian Zbarcea <hzbar...@gmail.com>wrote: > ... and a test of my subscription to the list. > > I had a few very interesting discussions with Tammo at ApacheCon EU and I > believe there are a few nice pieces in ODE that could be used outside BPEL > in other projects, Apache Camel in particular. Therefore I created ODE-977 > [1] to research what would take to integrate Jacob with Camel. > > The birds-eye view proposal is to define a simpler camel specific > language, instead of using bpel. The goal is to support stateful routes, a > scenario currently not supported by camel. > > I will research later a second category of use cases where bpel would be > used, but use camel to extend the reach of the engine to non-wsdl based > endpoints. This was attempted in camel a couple of years back, but was > dropped at some point. > > Now I have a few questions and proposals: > > 1. Upgrade the apt support in jacob-ap to jsr 2.6.9. The old mirror api is > deprecated anyway. > > 2. (related to 1.) Support for java 5. Should it be continued or not? I > would suspect it's not really needed. Those who won't upgrade the jre > version, will probably not upgrade ode either. > > 3. Refactor examples and testtypes out of jacob. I assume it's legacy that > was carried over. Minor issue anyway... > > 4. Fix the builds to properly generate @ChannelType(s) > > 5. (the important one). What branch should be used for this kind of > refactoring, 1.4 or 2.0? > > I anticipate more refactoring will be necessary. How do we want to handle > backwards compatiblity/migration for existing processes? I am not sure > there are enough examples to test migration and I am not confident enough > yet that I won't break something. Advice highly appreciated. > > Thanks Tammo for the help with navigating the source. > Hadrian > > [1] > https://issues.apache.org/**jira/browse/ODE-977<https://issues.apache.org/jira/browse/ODE-977> > -- Tammo van Lessen - http://www.taval.de
