Here are the exact steps I need:
1) Grab all the subprojects and combine the contents of their jar
artifacts into a new jar artifact.
2) Take that "uber jar", transitive dependencies, sources and
documentation and create the TGZ & ZIP archives
It sounds like, for now, you are saying I will in fact need to stage the
archive contents (or duplicate the "copy spec" definition) to create the
two archives. Am I reading that correctly?
Also I was curious whether your approach below wrt defining 'distLibs'
would cause all the referenced subprojects to be built all the time?
On Mon, 2009-11-09 at 10:02 +1100, Adam Murdoch wrote:
>
> Steve Ebersole wrote:
> > I am trying to figure out the best way to create my distribution against
> > a multi-project build. Two specific things I am unsure about:
> >
> > 1) I need to write out multiple distribution formats (ok 2 : zip and
> > tgz) but the contents will remain the same in each format. So obviously
> > I would like to define the source for these distribution archives just
> > once. The only thing I could think of was to manually create a
> > CopySpec, configure it appropriately and then manually call the Zip and
> > Tar
>
> This is pretty much the plan, but it's not quite implemented in trunk
> yet. It might work something like this:
>
> 1. allow the CopySpec for a task to be included in the CopySpec for another:
>
> task distZip(type: Zip) {
> from 'some-dir'
> include '...'
> ....
> }
>
> task DistTgz(type: Tar) {
> // Use the spec from distZip task
> from distZip.rootSpec
> compression = Compression.GZIP
> }
>
>
> 2. possibly provide some factory method for a copy spec:
>
> def distContents = copySpec {
> from 'some-dir'
> ...
> }
>
> task distZip(type: Zip) {
> from distContents
> }
>
> task distTgz(type: Tar) {
> from distContents
> compression = Compression.GZIP
> }
>
> > (does this only create the tar? is there an option to have it
> > create the gz?)
> >
>
> You use the compression property of the Tar task.
>
> > 2) I need the CopySpec, however it gets defined, to include stuff from
> > the subprojects. Specifically the artifact produced by the subproject
> > and its dependencies.
> >
>
> For the Gradle build, we use project dependencies for this, as we also
> want the transitive runtime dependencies. For example:
>
> configurations {
> distLibs
> }
>
> dependencies {
> distLibs project(path: ':subproject1'), project(':subproject2')
> }
>
> task distZip(type: Zip) {
> into('lib') {
> from configurations.distLibs
> }
> }
>
> This has the advantage that it drags in all the runtime jars, and the
> task dependencies are all automatically wired up for you.
>
> There are other ways of achieving similar things, depending on what you
> need.
>
>
--
Steve Ebersole <[email protected]>
Hibernate.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
