cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans>
Subject Re: Status of releasing M1 artifacts
Date Tue, 01 Aug 2006 17:09:59 GMT

On 8/1/06 7:54 AM, in article, "Reinhard Poetz"
<> wrote:

>> I tried to rerelease cocoon-core because it was missing cocoon-licenses as
>> dependency
> why do we need such a dependency? I don't understand what it really buys us.

There has been talk about this a while ago, about finding an easy way to
redistribute our licenses with the blocks. I remember suggesting this
solution as a way of "making sure" that our licenses are included in maven
based cocoon deployments. Perhaps I'm mistaken my suggestion for a decision
though, so feel free to remove it again if it doesn't buy us anything in

>> mvn -N release:prepare release:perform -Darguments="-N"
> what a strange notation ... I tried it with "-N" only.

The first -N applies to the maven you're invoking, the second -N applies to
the embedder that invokes maven from within maven during the release

> Another question: Is it really a good idea if we add the release tags to one
> directory? Over the time we will get hundrets of them. Maybe we should build
> some hierarchy
> /cocoon/releases/core
> /cocoon/releases/blocks/cforms
> /cocoon/releases/blocks/ctemplate
> /cocoon/releases/blocks/...
> /cocoon/releases/tools/...
> /cocoon/releases/pom (for our pom artifacts)

+1 for a hierarchy of some sort. Is there another way of enforcing this
structure other than to add -DtagBase=http://svn.a.o.. to the commandline
when invoking the release plugin ?


View raw message