On Nov 22, 2007 2:51 PM, ant elder <[EMAIL PROTECTED]> wrote: > On Nov 22, 2007 1:57 PM, Simon Nash <[EMAIL PROTECTED]> wrote: > > > > > Jean-Sebastien Delfino wrote: > > > > > [snip] > > > Simon Nash wrote: > > > > > >> 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. > > > > > > > > > I didn't think we were polluting the lib directory with sample > > > dependencies, do you have a concrete example? > > > > > I thought this thread was discussing the case of a sample having a > > dependency that the runtime does not have. If there are no such cases > > at present, then the issue doesn't arise. However, there could be > > such cases in the future as we add more "application-style" samples, > > and it would be good to have an idea about how such dependencies would > > be handled. > > > > >> > > >> 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, > > > > > > > > > Like I said earlier in the initial thread about sample dependencies, I > > > don't think that samples should bring dependencies that are not > genuine > > > Tuscany dependencies. > > > > > OK, we are agreed about this. But what if an application-style sample > > does have a non-Tuscany dependency? This is certainly possible. Would > > the Tuscany distro include the dependency, or leave it up to the user > > to download it as a prereq to running the sample? > > > > > 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". > > > > > > > > > +1 > > > > > >> At the moment we have separate copies of the Tuscany runtime in > > >> "modules" and "lib" and I'm not quite sure why. > > > > > > > > > Which JARs are you talking about? > > > > > I'm talking about the tuscany-sca-all.jar in the lib directory, which > > is a combination of the contents of the jars in the modules directory. > > The tuscany-sca-manifest.jar refers to the the tuscany-sca-all.jar > > as well as referring to all the jars in the modules directory, which > > seems somewhat redundant. > > > > > > > >> 2. Tuscany samples source, READMEs and build files in "samples". > > > > > > > > > +1 > > > > > >> 3. Tuscany samples binaries in "modules/samples", > > > > > > > > > I prefer to have the binaries under samples as well, with their > source. > > > > > Having them there is more convenient but makes it harder to see how > > much space they are consuming. I did some investigation, and it > > turns out that these binaries are causing a huge expansion in the > > size of the "samples" directory. > > > > In the 1.0.1 binary distro, the source under the "samples" directory > > occupies around 2.3 MB. The total size of source plus binaries under > > this directory is 49.5 MB. This extra 47 MB for samples binaries is > > almost half the total size of the Tuscany binary distro. I think we > > need to either remove these binaries or separate them out into a > > samples download so that we can get the Tuscany binary distro down > > to a reasonable size. > > > > > with their > > > > > >> dependencies in "lib/samples". > > > > > > > > > Again samples should not bring additional dependencies in the first > > place. > > > > > I hope this is true. I don't know how to check that nothing in > > this category has been included in lib. > > > > >> > > >> 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. > > > > > > > > > IMO the samples should be small and not cause a size problem, and > > > therefore should stay in the distro. > > > > > +1 that this is how it should be, but it is definitely not the case > > today. The samples make up around 50MB of the 100MB total size of > > the binary distro. This needs to be fixed. > > > > > 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. > > > > > > > > > Makes sense to me, I'd suggest the following packages: > > > - base SCA runtime (assembly, policy fwk, impl-java) > > > - web services package (ws binding + related databindings) > > > - web 2.0 package (json, dwr, widget, atom, scripting) > > > - data integration (impl-data, openjpa) > > > - business process integration (bpel, xquery) > > > - jee integration (ejb, jms, rmi) > > > - spring + osgi integration (spring, osgi) > > > - all-in-one, for people who don't have time to solve puzzles. > > > > > This looks pretty good as a starting point. If we find that > > people are normally downloading the same combinations, we could > > look at merging these combinations. > > > > > Perhaps group web services and web 2.0 together, I'm not sure. > > > > > I think these shouldn't be combined. Web 2.0 applications don't > > always use Web services. > > > > > Also I'm not sure about where to put policies like security, > > > reliability, transactions. > > > > > Wouldn't these normally be applied to a binding? If so, they should > > go with that binding IMO. > > > > > Right now the distribution is nice and simple which makes it easy for > users > to figure out what they want and it makes the download page very clear. > Having multiple downloads reduces the download size but i think it needs > to > be weighed against the extra complexity doing that might bring, so I'd > like > to see more detail about how things would look before this happens. > > The main reason the binary distribution is large is because the webapp > samples are each including copies of the the Tuscany runtime dependencies. > We've talked several times about this and i thought there was (at least > some) agreement that the webapp samples shouldn't be like this but instead > > all the samples should be simple sca contribution jars. If we fix that > then > the size problem goes away (and it simplifies the sample build scripts).
I was under the impression that there is already work ongoing to try this out. > > > So an alternative to splitting up the binary distribution could be: > > - keep the current standalone runtime using all the jars in the > distribution > lib directory > - make all samples simple sca contribution jars > - have a separate Tuscany WAR that you can use to run any/all the samples > in > a webapp I'm with you up to this point. What Tomcat deep integration work is going on (I do know about the Geronimo stuff). > > - fix Tomcat deep integration and document how to do it (by copying the > binary lib directory jars to Tomcat lib etc) > (and slightly related - finish the Geronimo integration and get that > released somewhere and document how to use the sample contribution jars > with > it) > > All those would by default include all the Tuscany extensions and > dependencies, we document which jars are for what so advanced users can > remove what they don't need. I can do some more processing on ( http://people.apache.org/~slaws/dependencies.htm<http://people.apache.org/%7Eslaws/dependencies.htm>) to give some help here if required. > > > ...ant >
