Raymond Feng wrote:
Hi, Mike.
The change is my local experiment but it was checked in accidently as
part of the other changes. It is related to the discussion on [1].
[1] http://www.mail-archive.com/[email protected]/msg08099.html
I'll try to set up a test case for the impl-bpel under OSGi. If the
change breaks your test case, I can revert it.
Thanks,
Raymond
Raymond,
OK, you previously wrote:
> Hi,
>
> I prefer to have the design discussion be carried on the tuscany-dev ML
instead of JIRA :-).
>
> We already have the maven-bundle-plugin that do all the tricks to enable OSGi for 3rd party jars
> > (run mvn -Peclipse under sca/distribution/all), including:
> 1) Generate MANIFEST.MF for plain jars in the distribution
> 2) Merge multiple jars into one bundle
> 3) Override MANIFEST.MF for 3rd part bundles with problematic MF
>
> Then these bundles can be set as the Eclipse PDE target platform which is used to resolve the > >
> bundle dependencies for Tuscany modules. I have fixed the Import-Package under [1] and verified >
> that it works in PDE and Equinox console.
>
> Do you have a test case that I can use to validate the impl.bpel under OSGi?
>
> [1] http://svn.apache.org/viewvc?rev=788804&view=rev
>
> Thanks,
> Raymond
I'm sorry, but I don't think that the maven-bundle-plugin is going to do the trick for the ODE
material with regard to OSGi. I struggled for almost 3 weeks to sort out the mess of dependencies
involved with ODE and while my solution may not be perfect, it does have the merit of working.
The problem is that implementation-bpel-ode depends on the ODE runtime which was never built with
OSGi in mind. Meanwhile ODE has dependencies on a smash of specifialized stuff from Geronimo,
OpenJPA, Hibernate (etc, etc). Some of these dependencies have the nasty API + separate Provider
implementations which cause OSGi a lot of trouble (go see some of the OSGi mailing lists to see the
debate about these that they are having), which use META-INF/services to find the stuff to load.
After a lot of messing around, I found that a combination of the ODE JARs PLUS
geronimo-connector-2.0.1.jar
geronimo-jta_1.1_spec-1.1.jar
geronimo-transaction-2.0.1.jar
openjpa-1.3.0-SNAPSHOT.jar
persistence-api-1.0.jar
all placed into a single bundle and using the Bundle-Classpath to make them all available to the ODE
code, would run OK.
Using tricks like making the above JARs into fragments of one of the ODE JARs is unlikely to work
because of the usage of classes from those JARs all over the ODE JARs - it was easier to put them
all in one place than try to untangle the spaghetti of dependencies.
I considered building a separate bundle with these JARs, but it made more sense to me to include
them into the implementation-bpel-runtime bundle, since the idea that any Tuscany end-user could
switch ODE versions on their own is fanciful. Changing between two 1.x ODE versions cost me about 1
week of sustained effort (moving to 2.x ODE looks even worse...).
I recommend that we stick with this approach for now - unless someone can come up with a PROVEN
alternative that really works.
As for testcases, ALL the OASIS testcases run under OSGi - and those are the ones I am using. You
can take one or more of the BPEL versions of those and adapt them to run with the Tuscany build.
I've been using ASM_4001_TestCase and ASM_5025_TestCase recently, with contributions General and
General_BPEL - basic tests, but which exercise Services, References, Properties, binding.sca and
binding.ws, all with pure BPEL implementations.
You can find the all the OASIS testcases on the OASIS SVN here:
http://tools.oasis-open.org/version-control/svn/sca-assembly/TestCases/
I can give some suggestions about how to lay out these tests within Tuscany, although Kelvin and
Simon have got most of the Java versions of the tests working under the otests.
Hope this helps explain where I've been coming from regarding the BPEL ODE code.
Yours, Mike.
