Morning,
I wrote:
> > I'm not qualified to put forward any suggestions
Sam replied:
> I respectfully disagree.
Thanks Sam, I'll now bore you with my own opinion, and see if you change
your mind.. ;-)
I believe that there are two conflicting forces at work within Jakarta
regarding cross sub-project dependancies,
The first is the desire of individual sub-projects to provide their general
users (the people who make the sub-projects' existence worthwhile) with a
single distributable file from which a full working install can be made.
James and Turbine(which has a version including tomcat) are examples of
this. This gets positive feedback from users who want a shallow learning
curve and a fast track to deploying the application.
The second is the worthy and intelligent notion (exemplified by GUMP) that
no cross project dependancies should be satisfied by an individual
sub-project.
This is based on the notion that to do so will inevitably lead people who
are installing more than one sub-project to have to maintain duplicates of
some API's that are depended upon (is there a word for that?) by more than
one sub-project, logging and ant for instance. Tomcat source distributions
are an (admittedly poor) example of this in that they don't distribute ant,
but the build depends upon it, there may be better examples.
I don't know how this helps to clarify the situation, but I expect a
"Jakarta registry" is probably required, and the ability for sub-projects to
define their classpaths as part of their installation procedure. In which
case a manifest reading ant task could ensure dependancies are satisfied
without sub-projects having to bundle them.
This raises a couple of issues though..
a) it implies that there be an ant based installer for each application
participating in the scheme
b) it also implies that dependacy information and version compatibilities
can be written and read in a useful way
c) it may also require a seperate "jakarta_lib" to store common("shared" not
"popular") jars, to remove them from individual project directory trees.
d) smooth operation may also need a coherent jar version naming scheme, and
download directory structure to be adopted by all participating
sub-projects, so that ant can find the ones it needs to download.
I think I'm going down the road of a kind of binary GUMP, where dependancies
are satisfied not by building from cvs, but by downloading binaries.
If I lose my job I know what to do..
d.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
