groovy

Attached patch adds a deploy target to the ant build. This is intended to be run after a normal build has produced groovy-*.jar and groovy-all-*.jar.

Since each of these jars needs its own pom, I moved main.pom to groovy.pom and created a groovy-all.pom. The main differences besides the artifactId used is that the groovy-all.pom does not list any dependencies. I'm not sure this is 100% correct, nor am I sure that the listened dependencies for groovy.pom are 100% correct... you folks probably want to double check to make sure that the correct dependencies are being published.

I setup both of these new poms to use the <distributionManagement> section to define the repository and snapshot repository for your Codehaus project. I can't actually verify this since I don't have perms for that group, but I basically copied the settings from the mojo project and changed mojo to groovy, so I expect that it will work fine.

You will probably have to define a server configuration in ~/.m2/settings.xml to provide authentication details for the codehaus.org server, something like:

<?xml version="1.0"?>
<settings>
    <server>
        <server>
            <id>codehaus.org</id>
            <username>YOUR_USER_NAME</username>
            <password>YOUR_PASSWORD</password>
        </server>
    </servers>
</settings>

Maven2 (and the antlib tasks) will publish artifacts with SNAPSHOT in the version to the snapshot repo, otherwise it will deploy to the other. So, all you guys need to do is make sure the version in the groovy*.pom files is correct and then ant deploy will put them into the correct location.

I believe this should be good enough for now...

Right now the version is setup to use 1.0.1-SNAPSHOT, so you could potentially run ant createJars deploy now and it will publish what you have now into your snapshot repository... which I would really like, as then I can start to consume the work-in-progress that has annotation support and integrate that into a snapshot version of my groovy-maven-plugin. Though if you guys are planning on making a 1.1-beta-1 soonish, then I recommend you update the poms to use a version of 1.1-beta-1-SNAPSHOT.

You folks might also want to add this target too:

<target name="install-repo" depends="-initializeMaven" xmlns:artifact="urn:maven-artifact-ant">
        <artifact:install file="${targetDistDirectory}/groovy-${groovyVersion}.jar">
            <pom refid="groovy.pom"/>
        </artifact:install>
        
        <artifact:install file="${targetDistDirectory}/groovy-all-${groovyVersion}.jar">
            <pom refid="groovy-all.pom"/>
        </artifact:install>
    </target>

An initial version of the deploy target is in place. Leaving open for now as this is not tested with webdav.

TODO: extract groovy version from pom file instead of build.properties file.
Need to better understand what the 'Retrieving previous build number ...' message means when the maven ant task deploy command is invoked. I assume this is something to do with the maven metadata.

When mvn deploys new snapshots it looks at the currently deployed metadata to find the last build number, so it can deploy the new snapshot with a new <aftifactname><timestamp><buildnumber> for the latest snapshot.

As for testing... this should be easy enough to do... just run a deploy. Since you are using 1.0.1-SNAPSHOT (or was last I checked) this will end up in http://snapshots.repository.codehaus.org/ and you can always mount the groovy share manually and remove the files if you find that it does something you didn't intend.

I setup the distributionManagement section of your poms to use the right webdav bits for your project at the haus... I'd just give the deploy a try to validate it.

Can you also please add support to <artifact:install> in the default build, so that when one run runs the normal ant build that it will put the latest groovy-*.jar artifacts into the local artifacts cache? This will make it easier for m2 projects to use the Groovy ant build to integrate the latest changes w/less fuss. Installing the artifacts into the local repo should have no negative affect.

Also, you may want to consider using ant filtering on the groovy-*.pom files to get the ${groovyVersion} in sync with the ant build.

all tasks done