cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robin Green" <>
Subject Project Divisions
Date Wed, 17 Jan 2001 17:04:47 GMT
It seems to me that there is a difficult and important problem with code 
reuse across projects, like for example Stefano's XML compiler code - 
whichever way you do it, you have drawbacks. If we could crack this problem 
it would be a major boost for code reuse.


(1) Separate copies in different projects, all going their own merry way - 
well this is just like forking a project many times, it creates a 
maintenance nightmare.

(2) "Master copy" in one project. All patches go to the master project. But 
then you're trying to keep N cvs repositories in synch (and sometimes you 
can't keep them exactly in synch because incompatibilities are temporarily 
introduced), which is a waste of space and effort. Also political rivalries 
- who gets the "master copy", and why? What if that project stagnates and 
falls behind on accepting patches? (It doesn't even have to stagnate - the 
Linux kernel project is not exactly stagnant, but sometimes drops patches on 
the floor like an underpowered router!)

(3) General project full of "xml utilities", "framework utilities", etc. But
(i) this is in danger of becoming a disorganised mess with no clear scope 
unless it has some good organisers working on it. (NOTE: I have no 
experience with this, this is just my opinion.)
(ii) If you have a "production" project like Cocoon 1.x, you either have to 
wait for releases to fix bugs, include unstable jars in a supposedly stable 
release, or patch jars (e.g. sax-bugfix.jar in Cocoon 1.8.1) or something. 
All hacky.
(iii) Too many dependencies increases the problem of (ii).

(4) Create a new project just for xyz feature.
(i) But there are many little xml utility functions used in many projects, 
and it's ridiculous to create a new project for every tiny little feature.
(ii) See (3).

It's very depressing. ;-) As my PhD thesis will be broadly on behavioural 
and structural change management [ostensibly in OO databases, but this 
applies to all OO projects really], I'd be VERY interested to hear 
suggestions on this. I'll credit any truly original and non-trivial ideas!

Get Your Private, Free E-mail from MSN Hotmail at

View raw message