Re: [DISCUSS] Travel sample binary distribution

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

Simon Nash wrote:
> Simon Laws wrote:
>>> The "binaries" directory would contain a complete set of binaries
>>> and their runtime dependencies (configuration files etc.) so that users
>>> can easily see exactly what files are needed at runtime.
>>>
>>> I agree that running out of the source directories is easier in a
>>> development/test environment but this doesn't explain how people can
>>> package an application like this for redistribution in a production
>>> environment.  This is not straightforward and I have spent many weeks
>>> figuring it out.  It would seem a shame not to provide users with the
>>> benefit of this knowledge.
>>>
>>>  Simon
>>>
>>>
>>
>> Ok, that's a good position. I guess we just need to tweak the README
>> to explain what's going on.
>>
>> Simon
>>
>>
> One more thought on this.  Maybe we could leave the "binaries" directory
> in the source release but not build it automatically as part of the
> top-level build.  In the README we could explain that this build module
> is available for those who want to see the runtime binary artifacts.
> This makes things simpler for those who just want to look at the
> sample source code and compile and run it.
> 
>   Simon
> 
I have created TUSCANY-3528 to track this.

   Simon

Re: [DISCUSS] Travel sample binary distribution

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

Simon Laws wrote:
> On Wed, Apr 14, 2010 at 7:51 PM, Simon Nash <na...@apache.org> wrote:
>> Simon Laws wrote:
>>>> I think the best solution is to include "binaries" in the main mvn build.
>>>> This guarantees that the build output in "binaries" will always work when
>>>> using either the default profile or mvn -Pselfcontained.  The space and
>>>> time overhead of doing this isn't very much (about 10% for space when
>>>> using the default profile, and less than that for time).
>>>>
>>>> This doesn't affect the ant build because this doesn't produce a binary
>>>> package or use the "binaries" directory.
>>>>
>>>>  Simon
>>> Hi Simon
>>>
>>> When you say "include "binaries" in the main mvn build." do you mean
>>> the main mvn build of the distribution? I.e. you're shipping the
>>> source and binaries in one distribution?
>>>
>>> Simon
>>>
>> Sorry that I wasn't clear.  The distribution would be source only.
>> When someone downloads this distribution and builds it using maven, they
>> would get binaries within the source directories (under /target for each
>> source directory), and they would also get a complete set of binaries
>> (with no source) in the travelsample/binaries/target directory.
>>
>> If someone builds the downloaded distribution using ant, they would just
>> get binaries within the source directories (under /target for each
>> source directory).  The ant build wouldn't produce any output in the
>> travelsample/binaries/target directory.
>>
>> For both the maven and ant builds, the build wouldn't include the
>> "distribution" directory.  Anyone who needs to build the distribution
>> would need to run a maven build from the "distribution" directory,
>> just as they do with Tuscany SCA Java.
>>
>>  Simon
>>
>>
> 
> Ok so just replaying this, and sticking with maven for a moment, the
> build does the following:
> 
> - creates binaries under */target as you might expect
> - creates binaries under  binaries/target
> 
> The distribution is not built by default.
> 
Yes to all the above.

>>>From earlier on in the thread the objective was to "explain how people
> can package an application like this for redistribution in a
> production environment". Will the content of binaries/target be used
> or it is there for just for show? I.e. if I wanted to deploy the
> application what would I have to do? presumably take the contents of
> binaries/target + the dependencies and fire up the appropriate
> launcher.
> 
The dependencies (except for Tuscany SCA Java 1.6) are already included in
binaries/target so the only thing needed is to cd to binaries/target/launchers
and type "ant run-xyz" where xyz is the launcher name.  For example, to run
the "interaction" launcher, you would enter "ant run-interaction".  The ant
script is needed because it adds <TUSCANY_HOME>/lib/tuscany-sca-manifest.jar
to the classpath.  The README explains this.

The other option is to build using mvn -Pselfcontained which produces a
binaries/target directory with no external dependencies.  In this case you
could cd to binaries/target/launchers and enter "java -jar scatours-launcher-xyz.jar"
where xyz is the launcher name.  For example, to run the "interaction" launcher,
you would enter "java -jar scatours-launcher-interaction.jar".  This is also
explained in the README.

   Simon

Re: [DISCUSS] Travel sample binary distribution

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

On Wed, Apr 14, 2010 at 7:51 PM, Simon Nash <na...@apache.org> wrote:
> Simon Laws wrote:
>>>
>>> I think the best solution is to include "binaries" in the main mvn build.
>>> This guarantees that the build output in "binaries" will always work when
>>> using either the default profile or mvn -Pselfcontained.  The space and
>>> time overhead of doing this isn't very much (about 10% for space when
>>> using the default profile, and less than that for time).
>>>
>>> This doesn't affect the ant build because this doesn't produce a binary
>>> package or use the "binaries" directory.
>>>
>>>  Simon
>>
>> Hi Simon
>>
>> When you say "include "binaries" in the main mvn build." do you mean
>> the main mvn build of the distribution? I.e. you're shipping the
>> source and binaries in one distribution?
>>
>> Simon
>>
> Sorry that I wasn't clear.  The distribution would be source only.
> When someone downloads this distribution and builds it using maven, they
> would get binaries within the source directories (under /target for each
> source directory), and they would also get a complete set of binaries
> (with no source) in the travelsample/binaries/target directory.
>
> If someone builds the downloaded distribution using ant, they would just
> get binaries within the source directories (under /target for each
> source directory).  The ant build wouldn't produce any output in the
> travelsample/binaries/target directory.
>
> For both the maven and ant builds, the build wouldn't include the
> "distribution" directory.  Anyone who needs to build the distribution
> would need to run a maven build from the "distribution" directory,
> just as they do with Tuscany SCA Java.
>
>  Simon
>
>

Ok so just replaying this, and sticking with maven for a moment, the
build does the following:

- creates binaries under */target as you might expect
- creates binaries under  binaries/target

The distribution is not built by default.

>From earlier on in the thread the objective was to "explain how people
can package an application like this for redistribution in a
production environment". Will the content of binaries/target be used
or it is there for just for show? I.e. if I wanted to deploy the
application what would I have to do? presumably take the contents of
binaries/target + the dependencies and fire up the appropriate
launcher.

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: [DISCUSS] Travel sample binary distribution

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

Simon Laws wrote:
>> I think the best solution is to include "binaries" in the main mvn build.
>> This guarantees that the build output in "binaries" will always work when
>> using either the default profile or mvn -Pselfcontained.  The space and
>> time overhead of doing this isn't very much (about 10% for space when
>> using the default profile, and less than that for time).
>>
>> This doesn't affect the ant build because this doesn't produce a binary
>> package or use the "binaries" directory.
>>
>>  Simon
> 
> Hi Simon
> 
> When you say "include "binaries" in the main mvn build." do you mean
> the main mvn build of the distribution? I.e. you're shipping the
> source and binaries in one distribution?
> 
> Simon
> 
Sorry that I wasn't clear.  The distribution would be source only.
When someone downloads this distribution and builds it using maven, they
would get binaries within the source directories (under /target for each
source directory), and they would also get a complete set of binaries
(with no source) in the travelsample/binaries/target directory.

If someone builds the downloaded distribution using ant, they would just
get binaries within the source directories (under /target for each
source directory).  The ant build wouldn't produce any output in the
travelsample/binaries/target directory.

For both the maven and ant builds, the build wouldn't include the
"distribution" directory.  Anyone who needs to build the distribution
would need to run a maven build from the "distribution" directory,
just as they do with Tuscany SCA Java.

   Simon

Re: [DISCUSS] Travel sample binary distribution

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

>
> I think the best solution is to include "binaries" in the main mvn build.
> This guarantees that the build output in "binaries" will always work when
> using either the default profile or mvn -Pselfcontained.  The space and
> time overhead of doing this isn't very much (about 10% for space when
> using the default profile, and less than that for time).
>
> This doesn't affect the ant build because this doesn't produce a binary
> package or use the "binaries" directory.
>
>  Simon

Hi Simon

When you say "include "binaries" in the main mvn build." do you mean
the main mvn build of the distribution? I.e. you're shipping the
source and binaries in one distribution?

Simon

-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com

Re: [DISCUSS] Travel sample binary distribution

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

Simon Nash wrote:
> Simon Nash wrote:
>> Simon Laws wrote:
>>>> The "binaries" directory would contain a complete set of binaries
>>>> and their runtime dependencies (configuration files etc.) so that users
>>>> can easily see exactly what files are needed at runtime.
>>>>
>>>> I agree that running out of the source directories is easier in a
>>>> development/test environment but this doesn't explain how people can
>>>> package an application like this for redistribution in a production
>>>> environment.  This is not straightforward and I have spent many weeks
>>>> figuring it out.  It would seem a shame not to provide users with the
>>>> benefit of this knowledge.
>>>>
>>>>  Simon
>>>>
>>>>
>>>
>>> Ok, that's a good position. I guess we just need to tweak the README
>>> to explain what's going on.
>>>
>>> Simon
>>>
>>>
>> One more thought on this.  Maybe we could leave the "binaries" directory
>> in the source release but not build it automatically as part of the
>> top-level build.  In the README we could explain that this build module
>> is available for those who want to see the runtime binary artifacts.
>> This makes things simpler for those who just want to look at the
>> sample source code and compile and run it.
>>
Unfortunately this doesn't work very well because the mvn -Pselfcontained
profile needs to be set consistently when running the main mvn build and when
building the "binaries" directory.  So if someone runs the main mvn build
with the default profile, and later builds the "binaries" directory using
mvn -Pselfcontained, the output in "binaries" won't work.  This is quite
a likely scenario and it would cause confusion and frustration for users.

I think the best solution is to include "binaries" in the main mvn build.
This guarantees that the build output in "binaries" will always work when
using either the default profile or mvn -Pselfcontained.  The space and
time overhead of doing this isn't very much (about 10% for space when
using the default profile, and less than that for time).

This doesn't affect the ant build because this doesn't produce a binary
package or use the "binaries" directory.

   Simon

>>   Simon
>>
> I have created TUSCANY-3528 to track this.
> 
>   Simon
> 
> 
>