ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mitch Gitman <mgit...@gmail.com>
Subject Re: IvyDE & source variations (was: workaround to consume legacy Ivy modules)
Date Tue, 18 Oct 2011 22:01:03 GMT
Great. Thanks, Nicolas.

Another IvyDE question comes up. There are some Ivy modules which I do
control, and those ones I'm trying to make more conventional, publishing a
*-source.jar artifact. Publish works fine. And I even make IvyDE resolve to
a special IvyDE-specific cache. And under that cache, I see the jars and
sources directories getting populated correctly. But then when I go in
Eclipse to click on some depended-upon source that I control, I see the
dreaded "Source not found" error with this interesting tidbit:
"The JAR of this class file belongs to container 'ivy.xml[*]' which dose not
allow modifications to source attachments on its entries."

Anyone recall what that is a sign of?

2011/10/18 Nicolas Lalevée <nicolas.lalevee@hibnet.org>

>
> Le 18 oct. 2011 à 23:00, Mitch Gitman a écrit :
>
> > 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.
>
> IvyDE doesn't care about the extension. It only compares the artifact names
> and artifacts types declared in the ivy.xml to find out which is source of
> the other.
>
> Nicolas
>
> > On Tue, Oct 18, 2011 at 11:00 AM, Archie Cobbs <archie@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 <mgitman@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
> >>
>
>

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