[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?
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.
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?
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.
with their
dependencies in "lib/samples".
Again samples should not bring additional dependencies in the first place.
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.
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.
Perhaps group web services and web 2.0 together, I'm not sure.
Also I'm not sure about where to put policies like security,
reliability, transactions.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
