ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc De Boeck <mdeb...@gmail.com>
Subject Re: How to publish additional metadata with an artifact that is needed at retrieve time
Date Wed, 29 Jan 2014 07:49:53 GMT
Maybe, you can add a buildfile to the package that your publishing ? When
you retrieve that package, you can unzip it and execute the included
buildfile to do what needs to be done with that package. That buildfile can
also read the property file.

Or you might also publish your packages in a package format that is known
by a package manager (e.g. rpm, debian-packages when you are on linux).

Regards,
Marc



2014-01-28 KARR, DAVID <dk068x@att.com>

> I'm trying to envision how I can use Ivy for ATG Dynamo module
> dependencies.
>
> For background, retrieving a dependent ATG module requires getting the
> lib, config, and manifest pieces and copying them into a directory in your
> local ATG tree with a directory name dependent on the artifact you're
> retrieving.  The directory name to use is available in a properties file
> that is available when the module is built.
>
> I'm ok with the separate "lib, config, and manifest" pieces, because all
> of those are packaged in a single "build" directory when building the
> module.
>
> However, when retrieving this artifact, I'm unsure how to deal with
> knowing what directory in the ATG tree to unzip (not to mention knowing to
> unzip, not just to copy) the artifact to.  This information is available
> when building the module, so it can be available when publishing.
>
> I suppose I could publish an additional file in the zip file which is the
> properties file used in the build of the module.  My task which retrieves
> the artifact could first retrieve the zip, unpack it into a temp directory,
> read the properties file that I unpacked, and then copy in everything but
> the properties file into the target directory.
>
> I know that most of you won't be familiar with ATG Dynamo, but does any of
> this make sense?
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message