I am using a fork of ode in my github repository and applied a few
patches and created two jiras. I am not sure if it's worth attaching
patches to the jira, as my intent of licensing the code to the ASF
should be pretty obvious. How should we handle the merges back to the
official repo?
I created two new projects: jacob-annotation and jacob-generator (a
replacement for jacob-ap). I was a bit thrown off by the fact that the
maven artifactId is prefixed with "ode-". The explanation is probably
somewhere in the Rakefile, but I didn't dig for it yet. I am using a
separate test project to fine tune the generator and will follow up with
another commit. Then I plan to change jacob to use the new annotation
(it's in a different package). If that works, I'll update all projects
and remove the old annotation.
I will look at the model next.
Cheers,
Hadrian
On 11/12/2012 06:23 PM, Tammo van Lessen wrote:
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>
