Travel sample distribution packaging

[Simon Nash <na...@apache.org>]

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

Re: Travel sample distribution packaging

[Simon Nash <na...@apache.org>]

Simon Nash wrote:
> Simon Laws wrote:
>> OK, Simon, sounds like good news. I should have a little time this
>> week to try this out sometime so let me know when you're set and I'll
>> check it out and give it a spin here.
>>
>> Simon
>>
> I have committed a fix for TUSCANY-3460.  This packages the OpenEJB
> 3.1.2 dependencies as part of the travel sample and avoids the need for
> environment variables or separate downloads.
> 
> This change doesn't address TUSCANY-3462, and I suggest you wait for my
> fix for this before trying it out.  I should be able to commit this
> change tomorrow.  The fix for TUSCANY-3462 will use maven profiles to
> enable the travel sample to be built either as a delta to the Tuscany SCA
> 1.6 binary distro (the default) or in a fully self-contained mode (as the
> build is doing currently).
> 
>   Simon
> 
I have just committed a fix for TUSCANY-3462.  This changes the default
for the travel sample build so that the Tuscany runtime dependencies aren't
included in the travel sample binary distro.  It's also possible to run the
travel sample build using "mvn -Pselfcontained" to create a self-contained
travel sample binary distro including the Tuscany runtime dependencies.
This may be useful in some testing scenarios.

For both of these flavours of the travel sample binary distro, the
ant scripts in the launchers, clients, and services directories can be
used to run the jars in these directories.  In the default build,
these ant scripts add the necessary Tuscany dependencies to the runtime
classpath, using the environment variable TUSCANY_HOME to discover the
location of the Tuscany SCA binary distro.  In the self-contained build,
these ant scripts just run the jars without adding anything to the
runtime classpath.

Any feedback on these changes would be very welcome.

   Simon

Re: Travel sample distribution packaging

[Simon Nash <na...@apache.org>]

Simon Laws wrote:
> OK, Simon, sounds like good news. I should have a little time this
> week to try this out sometime so let me know when you're set and I'll
> check it out and give it a spin here.
> 
> Simon
> 
I have committed a fix for TUSCANY-3460.  This packages the OpenEJB
3.1.2 dependencies as part of the travel sample and avoids the need for
environment variables or separate downloads.

This change doesn't address TUSCANY-3462, and I suggest you wait for my
fix for this before trying it out.  I should be able to commit this
change tomorrow.  The fix for TUSCANY-3462 will use maven profiles to
enable the travel sample to be built either as a delta to the Tuscany SCA
1.6 binary distro (the default) or in a fully self-contained mode (as the
build is doing currently).

   Simon

Re: Travel sample distribution packaging

[Simon Laws <si...@googlemail.com>]

OK, Simon, sounds like good news. I should have a little time this
week to try this out sometime so let me know when you're set and I'll
check it out and give it a spin here.

Simon

Re: Travel sample distribution packaging

[Simon Nash <na...@apache.org>]

Simon Nash wrote:
> Simon Laws wrote:
>> I would agree that goals 1 and 2 are more important than goal 3. I
>> would though consider shipping some jars with our binary distro if we
>> needed extra jars over and above the Tuscany distro to make some of
>> the sames work. Especially if that removes the need to set environment
>> variables and download anything but Tuscany and the sample.
>>
>> I haven't looked at the details of what you are proposing here so I
>> will do that before commenting further.
>>
>> Simon
>>
> I can investigate this suggested approach.  The aditional jars that we
> would need to ship with the travel sample (as a delta to Tuscany SCA 1.6)
> would be all or part of the contents of the OpenEJB "lib" directory.
> Some subsetting might be possible based on the needs of the travel sample,
> and I can investigate how large the subset would be.
> 
> This approach might create problems with version conflicts between
> older versions of the JEE/Geronimo-related jars in the Tuscany SCA 1.6
> binary distro and newer versions of those jars used by OpenEJB 3.x.
> I can investigate whther or not these conflicts create any issues for
> running the travel sample.
> 
I have identified the following subset of OpenEJB 3.1.2 runtime jars
which is sufficient to run the travel sample and doesn't cause version
conflicts with the Tuscany SCA runtime when running the travel sample.
  commons-cli-1.1.jar
  commons-dbcp-all-1.3-r699049.jar
  ejb31-api-experimental-3.1.2.jar
  geronimo-transaction-2.1.jar
  javaee-api-5.0-2.jar
  openejb-api-3.1.2.jar
  openejb-client-3.1.2.jar
  openejb-core-3.1.2.jar
  openejb-ejbd-3.1.2.jar
  openejb-javaagent-3.1.2.jar
  openejb-jee-3.1.2.jar
  openejb-loader-3.1.2.jar
  openejb-server-3.1.2.jar
  xbean-asm-shaded-3.6.jar
  xbean-finder-shaded-3.6.jar
  xbean-reflect-3.6.jar
This subset uses a total of 4MB disk space and I think it's acceptable to
bundle these jars with the travel sample binary distribution for now until
the OpenEJB runtime becomes part of the Tuscany 1.x binary distribution.

This bundling avoids the need for the user to set environment variables
for OPENEJB_HOME and OPENEJB_VERSION when building and running the travel
sample.  It's still necessary for the user to set the TUSCANY_HOME
environment variable before running the executables in the travel sample
binary distribution.

> In order to implement this packaging it will be necessary to restructure
> the travel sample distribution directory with two submodules under the
> distribution module.  One submodule would bring in the Tuscany SCA 1.6
> dependencies and the other submodule would bring in the OpenEJB 
> dependencies.
> This change shouldn't be a problem as this is similar to what we do in
> the Tuscany SCA 1.x distribution with the bundle and manifest submodules.
> 
I have been able to make this work.  It wasn't quite as easy as I expected
and my first attempt needs a bit of cleaning up before I commit the final
version as part of the fixes for TUSCANY-3460 and TUSCANY-3462.

   Simon

Re: Travel sample distribution packaging

[Simon Nash <na...@apache.org>]

Simon Laws wrote:
> I would agree that goals 1 and 2 are more important than goal 3. I
> would though consider shipping some jars with our binary distro if we
> needed extra jars over and above the Tuscany distro to make some of
> the sames work. Especially if that removes the need to set environment
> variables and download anything but Tuscany and the sample.
> 
> I haven't looked at the details of what you are proposing here so I
> will do that before commenting further.
> 
> Simon
> 
I can investigate this suggested approach.  The aditional jars that we
would need to ship with the travel sample (as a delta to Tuscany SCA 1.6)
would be all or part of the contents of the OpenEJB "lib" directory.
Some subsetting might be possible based on the needs of the travel sample,
and I can investigate how large the subset would be.

This approach might create problems with version conflicts between
older versions of the JEE/Geronimo-related jars in the Tuscany SCA 1.6
binary distro and newer versions of those jars used by OpenEJB 3.x.
I can investigate whther or not these conflicts create any issues for
running the travel sample.

In order to implement this packaging it will be necessary to restructure
the travel sample distribution directory with two submodules under the
distribution module.  One submodule would bring in the Tuscany SCA 1.6
dependencies and the other submodule would bring in the OpenEJB dependencies.
This change shouldn't be a problem as this is similar to what we do in
the Tuscany SCA 1.x distribution with the bundle and manifest submodules.

   Simon

Re: Travel sample distribution packaging

[Simon Laws <si...@googlemail.com>]

I would agree that goals 1 and 2 are more important than goal 3. I
would though consider shipping some jars with our binary distro if we
needed extra jars over and above the Tuscany distro to make some of
the sames work. Especially if that removes the need to set environment
variables and download anything but Tuscany and the sample.

I haven't looked at the details of what you are proposing here so I
will do that before commenting further.

Simon

Re: Travel sample distribution packaging

[Simon Nash <na...@apache.org>]

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