ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: artifacts of evicted module
Date Tue, 26 Jun 2007 09:24:07 GMT
On 6/26/07, Johannes Stamminger <Johannes.Stamminger@astrium.eads.net>
wrote:
>
>
> Hi!
>
> On Tuesday 26 June 2007, Johannes Stamminger wrote:
> > Hi!
> >
> > On Monday 25 June 2007, Maarten Coene wrote:
> > > It's possible that the problem is already fixed by a change I've
> > > committed recently...
> > >
> > > Maarten
> >
> > Did you provide it related to an issue? Else I would raise another one
> that
> > you might close then again ... just for documentation ... ?
> >
> > Today I will give the actual repository version a try.
>
>
> I made some tests with more versions now:
>
> 1. actual trunk branch snapshot:
>
> a) Your documentation seems out of date. When using ivy-1.4.1 (see remark
> on
> download page) for building actual snapshot the "ant jar" leads to:
>
> <log>
> jstammi@clam:~/Work/ivy/src/ivy$ ant
> Buildfile: build.xml
>
> init:
>
> prepare:
>
> compile-core:
>
> compile-ant:
>
> init-ivy:
>
> resolve:
> [ivy:retrieve] :: Ivy 1.4.1 - 20061109165313 ::
> http://incubator.apache.org/ivy/ ::
> [ivy:retrieve] impossible to define new type: class not found:
> org.apache.ivy.plugins.resolver.VsftpResolver in [] nor Ivy classloader
> [ivy:retrieve] impossible to define new type: class not found:
> org.apache.ivy.plugins.resolver.SshResolver in [] nor Ivy classloader
> [ivy:retrieve] impossible to define new type: class not found:
> org.apache.ivy.plugins.resolver.VfsResolver in [] nor Ivy classloader
> [ivy:retrieve] impossible to define new type: class not found:
> org.apache.ivy.plugins.resolver.SFTPResolver in [] nor Ivy classloader
> ...
> </log>
>
> Do you track this by issues, too?


The impossible to define new types are normal for Ivy build. Indeed we do
not need an ivy version anymore to build ivy itself: a first compilation is
done of the core (which doesn't depend on any dependency), then the core is
used to resolve dependencies for optional parts which have dependencies.
That's why the first resolve doesn't know optional resolvers. It might be
better to remove these warnings in this case, or at least to document it
properly. You can open an issue for that.

b) the evictions are included again in the graph and reports, this seems
> fixed


Nice

c) the dependencies hirarchy is still not shown. All dependents are shown as
> directly connected to the top level moduleC. I will report this in a
> moment.


Thanks.

2. actual 1.4.x branch snapshot
>
> a) build with ivy-1.4.1 succeeded
> b) eviction is broken there for my configuration as with the 1.4.1 release


1.4.x branch only include minor backport of one or two issues. I don't even
know if we will release it one day, since we can't make an apache release
out of it (package names, legal issues, ...)

3.
>
> http://incubator.apache.org/ivy/downloads/latest/ivy-1.5.0-incubating-dev-20070308022022-bin.zip
>
> Same bahviour as 2.0.0-alpha1, evictions as expected but no longer being
> reported and dependencies hirarchy is not shown.



Thanks for all these tests!

Best regards,

Xavier

Regards,
> Johannes Stamminger
>
>
> >
> >
> > Regards,
> > Johannes Stamminger
> >
> > > ----- Original Message ----
> > > From: Xavier Hanin <xavier.hanin@gmail.com>
> > > To: ivy-user@incubator.apache.org
> > > Sent: Monday, June 25, 2007 6:58:45 PM
> > > Subject: Re: artifacts of evicted module
> > >
> > > On 6/25/07, Johannes Stamminger <Johannes.Stamminger@astrium.eads.net>
> > >
> > > wrote:
> > > > Hi again a last time for today!
> > > >
> > > >
> > > > Hi just tested the 2.0.0-alpha1 behaviour (with the example provided
> as
> > > > attachment to IVY-537).
> > > >
> > > > Good: the build no longer fails with not using an all-conflict
> manager
> > > > as workaround and all evictions were done as expected.
> > > >
> > > > But: graph and html do no longer show any eviction information nor
> the
> > > > dependencies hirarchy.
> > > >
> > > > Is there something more to do than switching the ivy-jar in the
> apache
> > > > libs or
> > > > are those known issues or ... ?
> > >
> > > No, there's nothing more to do than switching the jar. It's a good
> news
> > > to know eviction is working as expected, I'm surprised about the
> reports.
> > > Since we have your example attached with IVY-537, we'll try to find
> out
> > > what's happening.
> > >
> > > Xavier
> > >
> > > Regards,
> > >
> > > > Johannes Stamminger
> > > >
> > > > On Monday 25 June 2007, Johannes Stamminger wrote:
> > > > > Hi!
> > > > >
> > > > > On Monday 25 June 2007, Xavier Hanin wrote:
> > > > > > On 6/25/07, Johannes Stamminger
> > > > > > <Johannes.Stamminger@astrium.eads.net>
> > > > > >
> > > > > > wrote:
> > > > > > > Hi again!
> > > > > > >
> > > > > > >
> > > > > > > Our workaround was so far to use the all-conflict manager
> > > > > > > instead.
> > > > > > >
> > > > > > >
> > > > > > > Today I found the time to extract a sample configuration
of
> our
> > > > > > > more complex
> > > > > > > setup. And it revealed, that the problem is not with modules
> > > >
> > > > providing
> > > >
> > > > > > > their
> > > > > > > dependencies themselves by way of delivered ivy files.
But
> with
> > > > > > > external libs
> > > > > > > whose artifacts are referenced from a module's ivy file,
there
> > > > > > > the problem appears. With moduleA referencing libX-1.0
with:
> > > > > > >
> > > > > > >         <dependency name="libX" rev="1.0" org="COTS"
> > > > > > > conf="compile, development, deployment">
> > > > > > >             <artifact name="libX" conf="compile"/>
> > > > > > >             <artifact name="LICENSE" type="license"
ext="txt"
> > > > > > > conf="deployment"/>
> > > > > > >             <artifact name="libX" type="source" ext="src.jar"
> > > > > > > conf="development"/>
> > > > > > >         </dependency>
> > > > > > >
> > > > > > >
> > > > > > > and another module referencing same libX but in version
2.0 by
> > > > > > > way
> > > >
> > > > of:
> > > > > > >         <dependency name="libX" rev="2.0" org="COTS"
> > > > > > > conf="compile, development, deployment">
> > > > > > >             <artifact name="libX" conf="compile"/>
> > > > > > >             <artifact name="libX" type="license"
> > > > > > > ext="jar.license" conf="deployment"/>
> > > > > > >             <artifact name="libX" type="source" ext="src.jar"
> > > > > > > conf="development"/>
> > > > > > >         </dependency>
> > > > > > >
> > > > > > >
> > > > > > > the eviction of libX-1.0 fails (note the different namings
for
> > > > > > > the license artifact).
> > > > > > >
> > > > > > > I have a complete running example available - but as I
read
> from
> > > > > > > previous mails, attachments are stripped. So I cannot provide
> it
> > > >
> > > > here
> > > >
> > > > > > > but will attach
> > > > > > > it tomorrow to a new issue ... unless you believe my way
of
> > > >
> > > > referencing
> > > >
> > > > > > > libX
> > > > > > > being not correct ... ?
> > > > > >
> > > > > > You can open the issue, your referencing is correct.
> > > > >
> > > > > Thanks for the confirmation! The bug is now filed in
> > > > > https://issues.apache.org/jira/browse/IVY-537
> > > > >
> > > > >
> > > > > Regards,
> > > > > Johannes Stamminger
> > > > > ...
> > > >
> > > > --
> > > > !!! NEU/NEW !!!     vvvvvvv
> > > > Johannes.Stamminger@Astrium.EADS.net   [2FE783D0
> > > > http://wwwkeys.PGP.net] ------ ----<--{(@ ------------------
> > > >             EADS ASTRIUM Koenigsberger Str. 17, 28857 Barrien
> > > > Ground System Eng. (TE55) +49 4242 169582 (Tel + FAX)
> > > > Huenefeldstr. 1-5, 28199 Bremen +49 174 7731593 (Mobile)
> > > > +49 421 539 4152 (Tel) / 4378 (FAX)
> > > >
> > > > This email (including any attachments) may contain confidential
> and/or
> > > > privileged information or information otherwise protected from
> > > > disclosure. If you are not the intended recipient, please notify the
> > > > sender immediately, do not copy this message or any attachments and
> do
> > > > not use it for any purpose or disclose its content to any person,
> but
> > > > delete this message and any attachments from your system. Astrium
> > > > disclaims any and all liability if this email transmission was virus
> > > > corrupted, altered or falsified.
> > > > ---------------------------------------------------------
> > > > Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller -
> > > > Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz,
> > > > Pablo Salame Fischer
> > > > Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht
> > > > Muenchen, HRB Nr. 107 647
>
>
>
> --
> !!! NEU/NEW !!!     vvvvvvv
> Johannes.Stamminger@Astrium.EADS.net   [2FE783D0 http://wwwkeys.PGP.net]
> ------ ----<--{(@ ------------------                        EADS ASTRIUM
> Koenigsberger Str. 17, 28857 Barrien           Ground System Eng. (TE55)
> +49 4242 169582 (Tel + FAX)              Huenefeldstr. 1-5, 28199 Bremen
> +49 174 7731593 (Mobile)             +49 421 539 4152 (Tel) / 4378 (FAX)
>
> This email (including any attachments) may contain confidential and/or
> privileged information or information otherwise protected from disclosure.
> If you are not the intended recipient, please notify the sender immediately,
> do not copy this message or any attachments and do not use it for any
> purpose or disclose its content to any person, but delete this message and
> any attachments from your system. Astrium disclaims any and all liability if
> this email transmission was virus corrupted, altered or falsified.
> ---------------------------------------------------------
> Astrium GmbH Vorsitzender des Aufsichtsrates: Thomas Mueller -
> Geschaeftsfuehrung: Evert Dudok (Vorsitzender), Dr. Reinhold Lutz, Pablo
> Salame Fischer
> Sitz der Gesellschaft: Muenchen - Registergericht: Amtsgericht Muenchen,
> HRB Nr. 107 647
>



-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

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