Simon, I did take a look at splitting the Tuscany distribution into bundles with the hope of defining something which makes sense for OSGi as well as non-OSGi. I dont really think that makes much sense anymore. Grouping modules into OSGi bundles using existing maven plugins was far too time consuming (in terms of the amount of time it took to do a build), and quite messy.
So I would like to go for a simpler option for OSGi where the the zip/jar files generated for the Tuscany distribution have a manifest file containing OSGi bundle manifest entries, so that they can be directly installed into OSGi (with an easy repackaging option to get rid of samples from the bundle if the bundle size was too big). I would also like to add OSGi manifest entries into all jars distributed by Tuscany including 3rd party jars, so that we can use the OSGi bundle repository API to install Tuscany into an OSGi runtime, instead of relying on Tuscany distribution structure. I have an Eclipse plugin which shows the dependency graphs based on the import/export statements generated by the maven-bundle-plugin. I could compare these with the dependencies you generated (it might help to add appropriate scopes to the dependencies). Thank you... Regards, Rajini On 11/23/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > 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 > > >
