| <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:[EMAIL PROTECTED]:/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.
[EMAIL PROTECTED] 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 forI would consider using groovy in the long run.
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.
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
