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. If they want to use maven to run samples (personally I don't want to do that but I accept that it is possible) then they just use maven without also downloading the binary runtime as maven does it for them. More likely they want to use Maven to compile/package their own contributions and again maven does all of the downloading for them. If they want to run samples with other tools, such as ant, eclipse or within an OSGi environment then we have a choice. We could make the use of Maven (or the Maven infrastructure) mandatory or we could provide a separate binary runtime download. This is plausible for ant (although maybe surprising to the ant user) and Eclipse bu OSGi concerns me. This concern is because we re-purpose some of our third party dependencies to work in the OSGi environment. The Maven repos don't know anything about these doctored jars/bundles. Now I don't know whether this is still the case that we need these doctored jars but I do see a lot of generated bundles still in the binary distro. So while this seems like a packaging question it's also a strategy question in as much that it affects our ability to run OSGi. I'm less keen on the idea of packaging a Maven repo in a distro as this doesn't fit in with the Maven model very well. I have been/am spending time looking at how to configure base + extensions in OSGi as this is one of the loose ends we have with this approach. This may inform the distribution question also. I don't have anything useful to report yet though. Simon -- Apache Tuscany committer: tuscany.apache.org Co-author of a book about Tuscany and SCA: tuscanyinaction.com
