Grzegorz Kossakowski wrote:
Examples you provided do not apply to the situation I want to discuss.
In 2.1 times we were shipping all dependencies ourselves so there is
no problem of dependency resolution.
I was talking about the situation when we want to release some early
alpha that has _snapshot_ dependencies that (obviously) are _not_
available at central server. If we want to make such a release it has
to be "internal" because we cannot ship it or upload at central. I
wanted to know what are our rules. Do we:
- want to have such a internal releases
OR
- we really think that world is perfect and we'll always depend on
released artifacts even in early stages of development
OR
- we do not make any early (alpha) releases at all (what about release
early, release often, then?)
I would really want to know your view on this issue.
I have always been unhappy that Cocoon releases contained non-released
jars for a few reasons:
1. Often the jars were labeled something like xyz-20070525-dev.jar.
It is impossible to download the source for this and know for sure
that it matches what the jar was built from and whoever actually
built the jar didn't put the source where someone could find it.
BTW - this is much easier with subversion repositories as the
builds can be tagged with the revision number.
2. Who is going to support this? Try asking a question about a
problem. You should expect that when they ask for the version and
you tell them you will either get nothing but silence or
laughter. We make no guarantees about our repository and neither
does anyone else.
Unfortunately, some of the projects Cocoon has components built around
only perform releases infrequently. Often we have encountered bugs that
really need to be fixed. And finally, Cocoon uses so many other jars
that a release would never be accomplished if we required formal
versions of them all.
However, with 2.2 I hope we can make sure that all the core Cocoon
components only leverage jars from projects that are pretty stable and
well maintained. I would suggest that if we are finding that some
projects are not responsive then it might be time to look for
alternatives to them or perhaps even drop the Cocoon block in question.
Of course, I haven't actually looked to see which blocks would be
impacted so even that may be impractical.
Ralph
