This disccusion relates to issues TUSCANY-3460 and TUSCANY-3462.

I have just reopened TUSCANY-3460 because I'm not entirely happy with one
aspect of the solution.

The new jar util/openejb-runtime.jar contains hard-wired path values for
the location of the OpenEJB runtime, based on the value of the OPENEJB_HOME
variable when this jar was built.  This is fine for running it on the system
on which it was built, but not on other systems.

The util/openejb-runtime.jar file is included in the distribution.  This is
necessary because other distribution launcher and service jars need the OpenEJB
runtime, and these jars are run from the distribution using the "java -jar"
command which requires all the classpath dependencies to be declared in the
transitive closure of manifest Class-Path attributes.  The means of supplying
the required OpenEJB dependencies is the util/openejb-runtime.jar which is
referenced from the other distribution jars that need these dependencies.

This approach works when building and running the binary distribution locally.
However it doesn't work if we are planning to release a downloadable binary
distribution for the travel sample. This is because a downloadable package
must not contain hard-wired path values.

The same problem affects the resolution of TUSCANY-3462, which would need to
add hard-wired path names to the distribution jars to bring in the Tuscany SCA
runtime dependency.

In summary, it isn't possible to achieve all of the following goals:
 1. Packaging the travel sample without embedding the OpenEJB and Tuscany SCA
    runtimes.
 2. Providing a downloadable binary distribution for the travel sample.
 3. Running the travel sample distribution jars using the "java -jar" command.

We could achieve goals 1 and 2 (but not 3) by providing an ant script or scripts
to run these jars, as we do for the samples in the Tuscany SCA distribution.
I think this is a reasonable approach.

Alternatively, we could achieve goals 1 and 3 (but not 2) by providing a
downloadable source distribution only.  This would be built by every user,
resulting in binaries that are hard-wired to the locations of the OpenEJB
and Tuscany SCA runtimes on the build machine.  I don't like this as much
because it isn't a realistic packaging option for a real application.

I'm happy to prototype the first approach (provide ant scripts) if there
is consensus that this is the best solution.

Thoughts, comments, other suggestions?

  Simon

Reply via email to