cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: Discussion about Maven
Date Wed, 06 Jun 2007 05:57:14 GMT

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.


View raw message