I realize this thread is pretty close to dead but I thought some perspective on the trunk could help.
On Wed, Sep 9, 2009 at 7:00 AM, Kurt T Stam <[email protected]> wrote: > Thanks Alex, > > 1. That is very helpful. Is there any expectation as to when the first > release 2.0 release will happen? > > When it's ready :) More seriously, you can make it happen. > > 2. I see there are 85 jira for 2.0, so that may take a bit? > > 2.0 has been for a while the "future" release so there's a lot of issues there that actually belong to the wishlist. Some triage is required to see what's really necessary (like porting fixes from 1.X) and what's just "nice to have". It'd be pretty helpful if someone could do a first pass on all of those and assign them to the wishlist. I can also provide a more context regarding the current state of trunk. It all started as Alex described it, the need to reflect the QoS at the message exchange level. This is necessary to support transactional or reliable transports correctly and it allowed some optimizations for the classic async, non reliable case (HTTP). The most important optimization being the number of transactions, 1.X is pretty pessimistic and commits a lot, often unnecessarily when you keep in mind that HTTP is unreliable in the first place. In trunk there's the notion of a process-level work queue, so work gets done for as long as possible without committing. So that work got started and we realized it would break the serialized OModel backward compatibility. Which was another problem that needed tackling anyway. At this point we introduced runtime versioning which is also in the trunk (you'll notice 2 versions under runtime and compiler). The idea is that the older process definitions and their instances get loaded in the older runtime and the newer ones use the v2 runtime so everyone can continue business as usual. There's also been some work on RESTful support and a related message exchange and ODEProcess implementation. If you implement a RESTful integration API, you can have a full request/response interaction served without any WSDL or SOAP BS. An example of a RESTful integration layer implementation can be found in simplex (http://github.com/intalio/simplexunder the http and messaging packages). So that's a lot of good infrastructure work. To the best of my knowledge, everything implemented is functional. It's probably not as fine-tuned as the 1.X branch though, there's been a lot of maturation behind each 1.3.x release. The BART stuff runs nicely, the reliable and transactional parts are untested (no IL uses it) but the classic HTTP code path works well and the work queue is effective. My guess would be that trunk commits about 30% less often than 1.X on typical processes. Runtime versioning works too, we have test cases for it reloading older saved runtimes. Finally, the RESTful support is also well tested in SimPEL. So the 2 main things necessary before a 2.0 I think would be 1. some bug triage to see which important fixes could have been forgotten from 1.x 2. migration at the database level for people who will want to upgrade from 1.x 3. someone volunteering to push the release forward The second point mostly matters for folks who have or are supporting people with a 1.x production. Hope this helps, Matthieu > Some stuff we worked on: > ODE-225 - HowTo: JBoss & ODE - might prob just a link to the RiftSaw > project (https://www.jboss.org/riftsaw) > ODE-41 - CXF Implementation of the IAPI - In RiftSaw we're using the > JBossWS (spi), which allows plugging in CXF and JBossWS Native. I'm guessing > this code will stay in RiftSaw since it will run easiest on JBoss. We've > tried using plain JAXWS but that turned out to be infeasible. So the spi is > the easiest way to support multiple WS stacks. > > Thx, > > --Kurt > > > Alex Boisvert wrote: > >> The trunk has a reworked engine-to-IL contract that supports BART >> (blocking, >> async, reliable, transacted) invokes. The engine part is mostly done; the >> IL parts are still a work in progress. >> >> The trunk also supports extension activities and includes support for >> Javascript E4X assignments. >> >> Some fixes/improvements that went into 1.X branch still have to be ported >> to >> trunk. We have Jira trackers for these if you want details. >> >> alex >> >> On Tue, Sep 8, 2009 at 10:02 AM, Alexis Midon <[email protected]> wrote: >> >> >> >>> Hi Kurt, >>> ODE trunk has two new big features compare to 1.3: >>> - support for multiple bpel runtimes: ODE 2.0 supports all its >>> previous >>> runtime verisons so that running process instances are not affected by >>> upgrades. >>> - atomic transactions: >>> http://ode.apache.org/atomic-scopes-extension-for-bpel.html >>> >>> On the roadmap as well: >>> - RESTful bpel part 2 >>> - Tuscany integration >>> >>> anything I'm omitting guys? >>> >>> Alexis >>> >>> >>> On Wed, Sep 2, 2009 at 7:26 AM, Kurt T Stam <[email protected]> wrote: >>> >>> >>> >>>> Hi guys, >>>> >>>> 1. What are currently the differences between the 1.3 branch and the 2.0 >>>> branch? >>>> >>>> 2. When is the expectation there is going to be a release from the 2.0 >>>> branch? Any RC being planned? >>>> >>>> Thx, >>>> >>>> --Kurt >>>> >>>> >>>> >>> >> >> > >
