Ross Gardler wrote:
David Crossley wrote:
Ross Gardler wrote:
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?
So far i like your plan.
It would need some Forrest people with serious Java skills
to do it. There is more than just the CLI to deal with.
Carsten recently gave us some tips on this dev list about
how to proceed.
I think we have that (and I wouldn't say "serious" java skills, just
some java skill).
There are some issues.
See the comments on [1] http://people.apache.org/builds.html
about the "Snapshot Repositories".
Particlarly: "...but should not be referenced in released
versions of your Apache project."
We already include a snapshot in our releases. As for referencing the
snapshot repo in the ivy configuration we need to do this in order to do
integration testing.
One thing is that Cocoon-2.2 will probably be properly
released soon. We can help to move that forward.
Yes, I noticed that on their list (trying to catch up with what has
happened to date).
Another thing is that the Forrest project has decided
in the past that it is okay to use snapshot versions.
Not sure if that is a wise or well-informed decision.
In the early days we were forced to use a snapshot as we were patching
trunk to achieve things in Cocoon that we needed. It's been a very long
time since we needed to do this. Perhaps it is time to revisit this issue.
On a related matter, i was liking our new approach to
managing our own dependencies. Having an Ivy descriptor
for each product enabled us to clearly describe each,
say where its home, what its license is, and link to
a jar in a maven repo. Nice.
This is a very good point, if we take it along with Thorstens
observation that an output of managing our own descriptors would be a
valuable contribution to the Ivy project I begin to think the extra work
would be worth it.
However, for this to be the case we should remove the maven repos from
our ivyconf.xml file an only use the ivy repos. This increases our work
in the short term even more.
The advantages would be:
- significant contribution to an ivy repo
- full control over our own descriptors and dependencies (i.e. control
over license information, second tier dependencies etc.)
- no need to update Cocoon until 0.9-dev cycle (i.e. time to address the
CLI issue)
I'm starting to think my very first plan was the right one.
OK, in the absence of further comment I've decided to return to the
original plan with a slight modification:
We will not be using the Maven repos at all. If we are going to put the
effort into switching to Ivy lets do it properly and use only Ivy repos.
This means we need to remove the maven repo's from the ivyconf.xml file
and reinstate the jars I deleted from our shared ivy repo.
Rather than kill the ivyconf.xml with respect to maven file I think I'll
make an ivyconf-maven.xml which includes the maven repos and an
ivyconf.xml file that does not. That way I can still cheat on my private
projects ;-)
Ross
