All that sounds sense to me, especially the thought of turning our samples
to simple contribution jars. That will align better with what application
developers would actually do.
- Venkat
On Nov 22, 2007 8:21 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
