Simon Nash wrote:
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
I have committed a prototype of the alternative solution that uses ant scripts
in distribution directories under r908910. Having done this, it seems to me
that
this approach has the great advantage of simplicity and clarity. For example,
to run the "jumpstart" launcher from the distribution launchers directory,
the user would enter the command
ant run-jumpstart
instead of
java -jar scatours-launcher-jumpstart
and similarly for the other launchers, clients, and services. The code that is
run by the ant run-* commands can be seen by looking at the build.xml files in
the distribution launchers, clients, and services directories.
If this approach is acceptable then I will complete the fixes to TUSCANY-3460
and TUSCANY-3462 along these lines. This involves removing code in various
pom.xml files that currently adds "../lib/" dependencies for Tuscany runtime
jars, removing the "lib" directory from the distribution, removing the
util/openejb-runtime module, removing the need to set the OPENEJB_HOME and
OPENEJB_VERSION environment variables before running the maven build, and
removing a few distribution-only launchers that would no longer be needed.
It would still be necessary to set the OPENEJB_HOME environment variable
before running the EJB-related samples from the distribution.
Simon
