Thanks Archie. The problem I see is that the zip has a deep structure which ivy will want to flatten. So I think I'll push the unpack task off to the build script. It also let the user be in charge of where to store the contents too (for better or worse).
Peter On Wed, Oct 5, 2011 at 11:09 AM, Archie Cobbs <[email protected]> wrote: > I don't think there's any way to define "wildcard" artifacts. > > So either define a single large artifact that the user is required to > unpack, or else have the packager resolver unpack it. > > In the latter case, you must update the ivy.xml file (and possibly the > packager.xml file too) when a new version is added that contains different > artifacts. We do this all the time in Ivy RoundUp and it's not a big deal > unless the people publishing the thing are releasing and changing things > around like crazy. > > -Archie > > On Wed, Oct 5, 2011 at 9:50 AM, Peter Kahn <[email protected]> wrote: > > > Hi all, > > > > Is the right approach for ivy modules with variable or unknown content to > > list an single archive file as a publications artifact and have the build > > expand it after the ivy retrieve? > > > > I'm trying to use ivy to deliver a 3rd part tool (NSIS installer) and > > ideally I'd like the ivy+packager fetch the zip, deliver it do the > > workspace > > and expand it. I can have packager expand the zip and deliver all items > I > > listed in the ivy module's publish section but this is fragile there are > > 50+ files and they may change over time. > > > > Is there a way to fee the artifact an ant glob / fileset or should I be > > handing an archive file to the subscribe build and have it's build.xml > > unzip > > it? > > > > Thanks > > > > Peter > > > > > > -- > > Peter Kahn > > [email protected] > > http://www.google.com/profiles/citizenkahn > > Awareness - Intention - Action > > > > > > -- > Archie L. Cobbs > -- Peter Kahn [email protected] http://www.google.com/profiles/citizenkahn Awareness - Intention - Action
