On 8/1/06 7:54 AM, in article [EMAIL PROTECTED], "Reinhard Poetz" <[EMAIL PROTECTED]> 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
