I've been having a rethink of our approach to the IVY migration.
Pretty much all of our java dependencies are Cocoon dependencies. So why
should we bother to manage them ourselves?
We should be able to just have a dependency on Cocoon and the blocks
that we require and that is it. Why can't we do that?
We can't just have a dependency on Cocoon because we use a version built
from SVN. This version is not SVN head, but is a past version of Cocoon.
If it were SVN head we could use the snapshot repository to pull down
the latest snapshot build of Cocoon and go from there.
So why don't we use SVN head?
Because SVN head has no crawler.
So, we have two choices for progression.
Continue with the path I have outlined for the IVY migration whereby we
use our own local repo to hold the specific version of Cocoon that we
know will work for us, or, we can use the move to ivy to force us to
upgrade to Cocoon head (something we should probably do for the 0.8
release anyway).
The latter route will require us to build a crawler, but Thorsten has
already started on that with the Droids lab.
I've tried setting it up with just a cocoon-core 2.2-snapshot
dependency, there are a couple of unresolved dependencies, but I am sure
these can be easily addressed.
The big advantage in going the latter route is that it will make future
upgrades to Cocoon a simple case of running an ant task. The downside is
that we will have to write a crawler (using the Droids lab code - which
is largely based on the crawler from Nutch if I understand correctly).
The big advantage of the former route is that we will be able to make
things work as they do now, in trunk, without any surprises from the
Cocoon upgrade. The downside is that we have to manage all our own
dependencies and will have to continue to build Cocoon independently.
So, should we continue with managing our own dependencies or should we
jump the short term hurdle and get the ivy branch working with Cocoon
2.2 snapshots?
Ross
