Uploading 3rd-party artifacts (jar & zip) to a Maven repository


(Andrea Cisternino) #1

Hi,

I am evaluating Gradle (1.2) as a replacement or successor of Ant in a large embedded Java project. A single version of the product comprises more than 70 Eclipse projects and the entire build system is based on Ant while the SCM tool is Subversion.

The actual number of projects managed by Subversion is actually quite higher because same projects have many variants that are assembled in specific configurations to create different products for different customers.

We currently do not use a Repository Manager but we make heavy use of CollabNet TeamForge to manage all our build artifacts and also to cooperate with other parties involved (i.e. the final customer and the hardware manufacturer)

By using Gradle and a Repository Manager like Artifactory or Nexus I would like to make the entire build and release process simpler, more maintainable and more granular by better identifying components with different life-cycles.

One of the many tasks I would like to implement in Gradle is deploying in the Repository Manager the many third party artifacts that are needed by the project and that are delivered to us by our partners.

A good description of what I would like to emulate is presented this Maven mini guide:

Guide to deploying 3rd party JARs to remote repository

Our use case is mostly the following:

  1. We receive a new release of an external java library by the hardware manufacturer. The release is comprised of one jar file, one javadoc zip archive and one source files zip archive. 2. All the artifacts and their accompanying documents are stored and controlled in TeamForge. 3. The new version of the library is made available to future versions of the products by a using a dedicated Gradle project

The steps I am currently performing in Gradle are the following:

  1. Copy the deliverables to a dedicated Gradle project. 2. Change the build.gradle file updating the version number. 3. Commit the entire project to Subversion. 4. Do a ‘gradle uploadArchives’ (or similar) that deploys the new artifacts in the Repository Manager with a new version number.

This gist shows my current build.gradle file that performs the above steps.

My questions for the Gradle community are:

Is this a sane way to do it?

If I run ‘gradle clean’ I get the following output:

$ gradle clean

Extracting api/extlib-src.zip to tmp/extlib-src_tmp

Extracting api/extlib-doc.zip to tmp/extlib-doc_tmp

:cleanTmp

:clean

BUILD SUCCESSFUL

Total time: 13.937 secs

How can I avoid the unpacking of the zip files only to delete the temporary directory immediately after?

Thanks! Andrea.


(Peter Niederwieser) #2

You need to turn ‘extractArchive’ into a task. Right now your are extracting the archive in the configuration phase rather than the execution phase. This means that the work will be performed for every invocation of Gradle, no matter which tasks get executed.


(Andrea Cisternino) #3

Hi Peter,

I followed your advice and it worked like a charm. Thanks a lot!

I have created a new gist with the modified build file:

https://gist.github.com/3810190

Andrea.