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 <citizenk...@gmail.com> 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 > citizenk...@gmail.com > http://www.google.com/profiles/citizenkahn > Awareness - Intention - Action > -- Archie L. Cobbs
