Archie, thanks for the alternate approach. In case I still want to consider
the original approach--if anyone else knows about the particular place in
the code that I want to override, I'd love to hear.
Correction. I believe I meant ${ivy.module.name}.
Actually, this raises another question. How would I configure IvyDE to
recognize foo.src.zip as the source for foo.jar?
The "Sources suffixes" configuration has default values like:
-source,-sources,-src
I could change this value to the following:
.src
Still, the presumption seems to be that the extension is always .jar. It
doesn't appear to accommodate .zip.
On Tue, Oct 18, 2011 at 11:00 AM, Archie Cobbs <arc...@dellroad.org> wrote:
> Just a thought... maybe instead you could write a resolver that contains a
> nested, normal resolver, and applies a configured XLST stylesheet to all of
> the ivy.xml files it downloads. Then what you want to do would be an easy
> specific case.
>
> -Archie
>
> On Tue, Oct 18, 2011 at 12:27 PM, Mitch Gitman <mgit...@gmail.com> wrote:
>
> > It looks like I'm going to have to write a custom Ivy resolver. I want to
> > consume modules that contain both a *.jar file and a *.src.zip file but
> > where the ivy.xml doesn't specify any publications. Unfortunately, these
> > modules are already published to a shared location and I can't just go
> and
> > blow them away. I understand that Ivy's default behavior is to treat the
> > lack of a publications element as if it were the following:
> > <publications>
> > <artifact name="${module.name} />
> > </publications>
> >
> > I forget if the property is module.name or something else. For the
> > artifact
> > element, the default type and ext of "jar" kick in.
> >
> > So I want to get the resolver to interpret this absence of publications
> > instead as:
> > <publications>
> > <artifact name="${module.name} />
> > <artifact name="${module.name} type="zip" ext="src.zip" />
> > </publications>
> >
> > Would anyone happen to know the bit of resolver code that defaults the
> > absence of publications so that I might override it?
> >
>
>
>
> --
> Archie L. Cobbs
>
