On Nov 18, 2007 9:31 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > I'm starting a new thread for this as suggested by Sebastien. > > Simon > > Simon Laws wrote: > > > On Nov 15, 2007 6:54 PM, Simon Nash <[EMAIL PROTECTED] > wrote: > > > > (cut) > >> > >>I don't think we should put sample dependencies in the bin distro lib > >>folder. If we need to include them in the bin distro (and I'm not 100% > >>convinced about that), then I think they should go in some other > >>directory. > >> > >>An alternative approach would be to have a samples distro that contains > >>the samples plus dependencies that are only used by the samples and not > >>by the main runtime. I think this is better as it allows us to add more > >>samples without pushing up the size of the main binary distro. > > > > > > Personally I like to see samples with whatever I download and I'd rather > > > have a bigger binary distro than a separate download. If there is a real > > need to reduce the distribution size can we do it in a different way, > for > > example, have groups of extensions (and their samples) distributed > > separately? > > > Samples are very important for beginning users. For users who have > moved beyond that stage and are doing real development using Tuscany, > samples are not very important. If people in this category do want > samples, they are likely to just want to refer to samples source code > to cut and paste snippets as necessary. Having pre-built sample binaries > isn't important for these users, and having the main lib directory > polluted/bloated by samples dependencies is a positive nuisance because > there's no easy way for them to find and remove the redundant files. > > Having these files in Tuscany's lib directory isn't just wasting a few > bits on the disk. It can be a problem if their version levels conflict > with other versions of the same code that the user has installed. > For "genuine" Tuscany dependencies, such conflicts are a real issue > that must be handled carefully in order to get Tuscany to co-exist with > their other software. For sample dependencies, there is no actual > conflict unless the user needs to run the specific sample that pulled > in the dependency, but it might take them some time to figure out why > putting the Tuscany lib directory on the classpath is causing other > code in their application to break. > > I'd suggest structuring the binary distribution as follows: > > 1. Tuscany runtime in "modules" and its dependencies in "lib". > At the moment we have separate copies of the Tuscany runtime in > "modules" and "lib" and I'm not quite sure why. > 2. Tuscany samples source, READMEs and build files in "samples". > 3. Tuscany samples binaries in "modules/samples", with their > dependencies in "lib/samples". > > By doing this we solve the conflict problems and it becomes a distro > size issue to decide whether 3 should be in the main binary distro > or available separately. Since 3 will be clearly separated from 1 > and 2, it will be easy to see how much extra size it is contributing. > > The other dimension of splitting the distro by functional contents > is orthogonal to the above and is also worth exploring. I'd suggest > the following distro packages: > > 1. Base runtime with functional capabilities that almost everyone > will want to use, and associated samples. > 2. A number of extension bundles (either depending only on the base, > or possibly depending on other bundles), and associated samples. > > If people think this approach makes sense then we could talk about > what the base distro and extension bundles should contain. > > Simon > > I think we should try to get to where the samples are just simple sca contribution jars - just the .composite files and whatever resources, Java classes or BPEL or Javascript files etc that the sample uses. All the dependency jars Tuscany uses to support running that - Ode, Axis2, Rhino and BSF etc and all the various Tuscany module jars - are a Tuscany implementation detail and the samples should be free from any reference to those. If we can do this then the sample build scripts become simple and the samples are tiny so there's no size problem at all with including them in a distribution.
...ant
