On Thu, Mar 3, 2011 at 4:04 PM, Simon Laws <[email protected]> wrote:

> On Thu, Mar 3, 2011 at 3:43 PM, ant elder <[email protected]> wrote:
>> On Thu, Mar 3, 2011 at 12:23 PM, Simon Nash <[email protected]> wrote:
>>
>>>>>>>>>> I meant to add, if working offline using local artifacts is
>>>>>>>>>> useful/important then i wonder if that should also be possible with
>>>>>>>>>> the Maven builds in the binary distribution. It might be nice if
>>>>>>>>>> both
>>>>>>>>>> the Ant and Maven builds could both work offline using the
>>>>>>>>>> distribution artifacts, which would probably mean having the jars in
>>>>>>>>>> the hierarchical directory structure that maven uses and having the
>>>>>>>>>> Tuscany standalone runtimes work with that. At least that would then
>>>>>>>>>> have the jars in a fairly common and understandable structure.
>>>>>>>>>>
>>>>>>>>>>  ...ant
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> From this I presume you mean having these jars under the Tuscany
>>>>>>>>> installation directory rather than in the user's local maven repo.
>>>>>>>>>
>>>>>>>>> This seems like a good idea as it's first step to creating a more
>>>>>>>>> embeddable Tuscany runtime installation.
>>>>>>>>>
>>>>>>>>>  Simon
>>>>>>>>>
>>>>>>>> Does anyone know how to do that? It sounds like something someone else
>>>>>>>> must have wanted to do before, i guess with the assmbly plugin you
>>>>>>>> must be able to find the local repo and include that in a
>>>>>>>> distribution?
>>>>>>>>
>>>>>>>>  ...ant
>>>>>>>>
>>>>>>>>
>>>>>>> I think the main problem comes when the user wants to use maven to load
>>>>>>> jars from some place on the file system other than the local maven
>>>>>>> repo.
>>>>>>> I spent a bit of time a few months ago looking for a way to do that,
>>>>>>> but I didn't find one.
>>>>>>>
>>>>>>>  Simon
>>>>>>>
>>>>>>>
>>>>>> I've now spent a bit of time trying to do this too without much
>>>>>> success with any automated way. You'd think you should be able to use
>>>>>> the assembly plugin and copy files from somewhere like
>>>>>> ${maven.repo.local} but it doesn't seem to work. Does anyone have any
>>>>>> other ideas ?
>>>>>>
>>>>>>  ...ant
>>>>>>
>>>>> What was the process you were hoping to follow Ant? It sounds like:
>>>>>
>>>>> 1/ build the Tuscany source to popular .m2/respository
>>>>> 2/ create a distribution which packages .m2/resposityr maintaining the
>>>>> same structure
>>>>> 3/ install the distribution with the packages respository intact
>>>>> 4/ run mvn but point it at the repository installed from the distribution
>>>>>
>>>>> is that close?
>>>>>
>>>>
>>>> Yep.
>>>>
>>>> There is also a way using the <repository> element in the assembly
>>>> descriptor
>>>> http://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_repository,
>>>> but that doesn't seem to include any plugins.
>>>>
>>>>   ...ant
>>>>
>>>>
>>> A repository that was used to build Tuscany would contain many other things
>>> needed to build Tuscany that aren't part of Tuscany itself.  I presume these
>>> would be removed before we make the distribution.
>>>
>>
>> I think that comes back to the question of why we'd want do this and
>> what the distribution is for?
>>
>> If the intention is that the distribution is self contained so the
>> user can use it without downloading anything else then what does it
>> mean for Maven users? Eg they could use things like clean  install
>> package eclipse:eclipse dependencies:list-dependencies ant:ant and
>> many more, so to work ofline we'd need to include all those plugins.
>> That starts to look a bit unwieldy and defeats the point of that part
>> of Maven,
>>
>> I'm now thinking Maven users are fine with downloading things as
>> required, so really the distribution for them doesn't need any
>> binaries at all, including the Tuscany jars, as they can all be
>> downloaded. If the  Ant build for the samples use the build script
>> created from mvn ant:ant which also downloads the jars dynamically
>> then that distro could work ok for both Maven and Ant users.
>>
>>   ...ant
>>
>
> Doesn't that just mean that we need to separate the binary samples
> distribution from the binary runtime distribution that users use to
> run them.
>

We did talk about having a sample distribution earlier in the thread.
I guess whether or not we do ever release a separate sample
distribution for now we can keep and develop all the samples in a
sample folder in trunk and perhaps add a build to create a sample
distribution under the trunk distribution folder to see what it might
look like.

   ...ant

Reply via email to