cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jorg Heymans ...@domek.be>
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 44CEECAF.7060700@apache.org, "Reinhard Poetz"
<reinhard@apache.org> 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
legal-land.

>> 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
process. 

http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html

> 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 ?


Jorg



Mime
View raw message