Release plugin question

["Christopher W. Farnham" <ch...@wrycan.com>]

I've added an echo message to the release plugin like so:

|  <goal name="release:build-distribution-src" 
prereqs="release:init,scm:checkout-project">
        <ant:echo 
message="dir=${maven.scm.checkout.dir}/${maven.scm.cvs.module}"/>
    <archive:gzip name="${releaseNameSrc}" 
dir="${maven.scm.checkout.dir}/${maven.scm.cvs.module}"/>
    <archive:zip name="${releaseNameSrc}" 
dir="${maven.scm.checkout.dir}/${maven.scm.cvs.module}"/>
  </goal>|

And determined that the dir property ends up looking like this ' / '.  
So it tries to zip up my root directory (thankfullly it fails).

I have the SCM properties in my project set.  They look like this:

|  <repository>
    
<connection>scm:cvs:pserver:maven@localhost:/usr/local/cvs/wrycanCode:wrycan/core</connection>
  </repository>

|Any ideas on what I might be doing wrong would be appreciated. I'm 
using bootstrap builds about a week old for my maven and release plugin 
code base.

Christopher Farnham
Senior Consultant at Wrycan, Inc.

chris.farnham@wrycan.com
http://www.wrycan.com


Jason van Zyl wrote:

>On Fri, 2004-01-09 at 20:18, Incze Lajos wrote:
>  
>
>>>In the long run and in the new Maven code I won't be promoting Jelly for
>>>plugins at all, but will be promoting the use of beanshell. I'm sure XML
>>>programming will remain wildly popular and if that is the case I will be
>>>reimplementing Jelly taking it down to the bare metal with xpp3 and
>>>using OGNL for expressions. I am no longer a fan of Jelly. I know people
>>>seem to love XML programming but I think it's the single biggest mistake
>>>I've made with Maven and it has cost us all dearly. I won't be making
>>>any similiar mistakes in the future.
>>>      
>>>
>>I would consider using groovy in the long run. 
>>    
>>
>
>Possibly, in the very long run. I'm aware of Groovy.
>
>  
>
>>It is a real scripting
>>language has all the structures (designed in) that were important in
>>jelly scripting (ant builder, xml builder, can emit xml sax events, etc.)
>>has excellent structures which could be important in workflows (closures
>>are, in fact, 1st class object code snippets that could be called on
>>worflow stages), can be interpreted AND compiled to bytecode, the same
>>way easy bean integration as in the jelly scripting, etc. And last but
>>not least: the syntax is not XML, but real programming language with
>>pretty good collection interfaces (which seems to be one of the most
>>important factors in project builders). Seemingly, the current codebase
>>can be 'mechanically' transported from jelly to groovy.
>>    
>>
>
>It's all good on paper, but beanshell 2.0 in my mind is the option I'm
>leaning toward right now simply because it's gone though an iteration or
>two. But who knows in time. At this point in time I'm not jumping in
>head first into Groovy.
>
>  
>
>>incze
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>>For additional commands, e-mail: users-help@maven.apache.org
>>    
>>