Mailing-List: contact dev-help@tuscany.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@tuscany.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <4BC5D193.1050807@apache.org>
Date: Wed, 14 Apr 2010 15:30:43 +0100
From: Simon Nash <nash@apache.org>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: dev@tuscany.apache.org
Subject: Re: [DISCUSS] Travel sample binary distribution
References: <4BA53935.2060003@apache.org>
 <4BA56FBA.7010100@apache.org>	 <4BB08B5C.2060708@apache.org>
	 <c0c051b51003291318r336d6a2ds9d4d0621fe002cf9@mail.gmail.com>
	 <4BB11925.6040003@apache.org>
 <v2wc0c051b51003300110mbb180c8ft184127b29ef89687@mail.gmail.com>
 <4BB1E51E.9000801@apache.org> <4BBCD84D.2040501@apache.org>
In-Reply-To: <4BBCD84D.2040501@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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
> 
> 
>