You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-user@ant.apache.org by Maarten Coene <ma...@yahoo.com> on 2009/03/01 23:20:04 UTC

Re: Possible bug in Ivy 2.0.0? I get undeterministic behavior.

I think it's caused because Ivy automatically adds source and javadocs artifacts to the maven modules if they are available. When you do the ivy:retrieve, you will also retrieve these sources/javadocs, but your retrieve-pattern maps the sources/javadocs artifacts to the same file as the artifact with the class-files.

You can solve it by either:
- add the [type] token to your retrieve pattern, or
- add type="jar" when calling ivy:retrieve

Maarten




----- Original Message ----
From: Kent Larsson <ke...@gmail.com>
To: ivy-user@ant.apache.org
Sent: Saturday, February 28, 2009 10:40:15 PM
Subject: Possible bug in Ivy 2.0.0? I get undeterministic behavior.

Hi,

I'm using Ivy and was very happy about my experience with it, until
now. I hope that the problems I am experiencing are due to some error
on my behalf.

Here is my scenario:

1. I'm downloading Ivy 2.0.0 dynamically from
http://repo1.maven.org/maven2/org/apache/ivy/ivy/ just like in the
"Automatic" example from
http://ant.apache.org/ivy/history/latest-release/install.html except
that I get 2.0.0 instead of 2.0.0-beta1.
2. I do not use any ivysettings.xml as I was happy with the default values.

When I retrieve my dependencies and synchronize them with my Ivy lib
dir I get unreliable behavior. The JAR-files I get are of different
sizes from time to time, and my project seldom compiles. It doesn't
happen to all my dependencies, just a few of them.

I attach a tarball ( using bzip2-compression ) with a BASH script I
created which reproduce the problem:
- Change working directory into ivy-problem and run script.sh
- It will retrieve the dependencies 15 times (easy to change) and record
    * The ant output for each iteration in stats/ant-output<N>.txt
    * The file names and sizes in the lib folder for each iteration in
stats/find-output<N>.txt
    * The lib directory of each iteration in lib<N>
- It will check which find-ouput<N>.txt files that match each other
and which differs, that output will reside in stats/diffs-and-matches

Please investigate further, this is a really serious issue and if it
is a bug (I hope not) it's one that affects the users in the worst
possible way.

The ivy.xml and build.xml are from parts of a project I'm working on,
if there is anything I can do to get reliable behavior from Ivy right
away I'm very interested in knowing about it.

Best regards,
Kent



      

Re: Possible bug in Ivy 2.0.0? I get undeterministic behavior.

Posted by Kent Larsson <ke...@gmail.com>.
I did change it to * as I wanted IvyDE to pick up on source and
javadocs, which it still didn't. :-( So I might just as well change it
back to default.

On Mon, Mar 2, 2009 at 11:17 AM, Tom Widmer <to...@googlemail.com> wrote:
> Maarten Coene wrote:
>>
>> I think it's caused because Ivy automatically adds source and javadocs
>> artifacts to the maven modules if they are available. When you do the
>> ivy:retrieve, you will also retrieve these sources/javadocs, but your
>> retrieve-pattern maps the sources/javadocs artifacts to the same file as the
>> artifact with the class-files.
>>
>> You can solve it by either:
>> - add the [type] token to your retrieve pattern, or
>> - add type="jar" when calling ivy:retrieve
>>
>> Maarten
>
> Or set up your configuration mappings to avoid the javadocs and sources:
> conf="runtime->*"
> is generally a bad idea - I tend to use 'default' rather than '*' if I just
> want the compile and runtime jars.
>
> Tom

Re: Possible bug in Ivy 2.0.0? I get undeterministic behavior.

Posted by Tom Widmer <to...@googlemail.com>.
Maarten Coene wrote:
> I think it's caused because Ivy automatically adds source and javadocs artifacts to the maven modules if they are available. When you do the ivy:retrieve, you will also retrieve these sources/javadocs, but your retrieve-pattern maps the sources/javadocs artifacts to the same file as the artifact with the class-files.
> 
> You can solve it by either:
> - add the [type] token to your retrieve pattern, or
> - add type="jar" when calling ivy:retrieve
> 
> Maarten

Or set up your configuration mappings to avoid the javadocs and sources:
conf="runtime->*"
is generally a bad idea - I tend to use 'default' rather than '*' if I 
just want the compile and runtime jars.

Tom


Re: Possible bug in Ivy 2.0.0? I get undeterministic behavior.

Posted by Kent Larsson <ke...@gmail.com>.
I agree. Otherwise the user is depending on luck on each build. :-)

On Tue, Mar 3, 2009 at 10:24 PM, Maarten Coene <ma...@yahoo.com> wrote:
> There is already an issue for it if I'm not mistaken...
> I think it would be better if Ivy throws an error when retrieving 2 different artifacts to the same file...
>
> Maarten
>
>
>
>
> ----- Original Message ----
> From: Kent Larsson <ke...@gmail.com>
> To: ivy-user@ant.apache.org
> Sent: Tuesday, March 3, 2009 10:07:53 PM
> Subject: Re: Possible bug in Ivy 2.0.0? I get undeterministic behavior.
>
> Thank you! It worked. :-)
>
> Can I give a feature request? Ivy could store which files it outputs
> and if it overwrites a file it could at least give a warning that it
> has done so. For these circumstances, when a pattern results in
> overwritten files, it's always an error and if the project builds it's
> pure luck? In that case a textual warning would be great, I would
> stretch it so far as the build failing as something is obviously very
> wrong.
>
> Best regards, Kent
>
>
> On Sun, Mar 1, 2009 at 11:20 PM, Maarten Coene <ma...@yahoo.com> wrote:
>> I think it's caused because Ivy automatically adds source and javadocs artifacts to the maven modules if they are available. When you do the ivy:retrieve, you will also retrieve these sources/javadocs, but your retrieve-pattern maps the sources/javadocs artifacts to the same file as the artifact with the class-files.
>>
>> You can solve it by either:
>> - add the [type] token to your retrieve pattern, or
>> - add type="jar" when calling ivy:retrieve
>>
>> Maarten
>>
>>
>>
>>
>> ----- Original Message ----
>> From: Kent Larsson <ke...@gmail.com>
>> To: ivy-user@ant.apache.org
>> Sent: Saturday, February 28, 2009 10:40:15 PM
>> Subject: Possible bug in Ivy 2.0.0? I get undeterministic behavior.
>>
>> Hi,
>>
>> I'm using Ivy and was very happy about my experience with it, until
>> now. I hope that the problems I am experiencing are due to some error
>> on my behalf.
>>
>> Here is my scenario:
>>
>> 1. I'm downloading Ivy 2.0.0 dynamically from
>> http://repo1.maven.org/maven2/org/apache/ivy/ivy/ just like in the
>> "Automatic" example from
>> http://ant.apache.org/ivy/history/latest-release/install.html except
>> that I get 2.0.0 instead of 2.0.0-beta1.
>> 2. I do not use any ivysettings.xml as I was happy with the default values.
>>
>> When I retrieve my dependencies and synchronize them with my Ivy lib
>> dir I get unreliable behavior. The JAR-files I get are of different
>> sizes from time to time, and my project seldom compiles. It doesn't
>> happen to all my dependencies, just a few of them.
>>
>> I attach a tarball ( using bzip2-compression ) with a BASH script I
>> created which reproduce the problem:
>> - Change working directory into ivy-problem and run script.sh
>> - It will retrieve the dependencies 15 times (easy to change) and record
>>    * The ant output for each iteration in stats/ant-output<N>.txt
>>    * The file names and sizes in the lib folder for each iteration in
>> stats/find-output<N>.txt
>>    * The lib directory of each iteration in lib<N>
>> - It will check which find-ouput<N>.txt files that match each other
>> and which differs, that output will reside in stats/diffs-and-matches
>>
>> Please investigate further, this is a really serious issue and if it
>> is a bug (I hope not) it's one that affects the users in the worst
>> possible way.
>>
>> The ivy.xml and build.xml are from parts of a project I'm working on,
>> if there is anything I can do to get reliable behavior from Ivy right
>> away I'm very interested in knowing about it.
>>
>> Best regards,
>> Kent
>>
>>
>>
>>
>>
>
>
>
>
>

Re: Possible bug in Ivy 2.0.0? I get undeterministic behavior.

Posted by Maarten Coene <ma...@yahoo.com>.
There is already an issue for it if I'm not mistaken...
I think it would be better if Ivy throws an error when retrieving 2 different artifacts to the same file...

Maarten




----- Original Message ----
From: Kent Larsson <ke...@gmail.com>
To: ivy-user@ant.apache.org
Sent: Tuesday, March 3, 2009 10:07:53 PM
Subject: Re: Possible bug in Ivy 2.0.0? I get undeterministic behavior.

Thank you! It worked. :-)

Can I give a feature request? Ivy could store which files it outputs
and if it overwrites a file it could at least give a warning that it
has done so. For these circumstances, when a pattern results in
overwritten files, it's always an error and if the project builds it's
pure luck? In that case a textual warning would be great, I would
stretch it so far as the build failing as something is obviously very
wrong.

Best regards, Kent


On Sun, Mar 1, 2009 at 11:20 PM, Maarten Coene <ma...@yahoo.com> wrote:
> I think it's caused because Ivy automatically adds source and javadocs artifacts to the maven modules if they are available. When you do the ivy:retrieve, you will also retrieve these sources/javadocs, but your retrieve-pattern maps the sources/javadocs artifacts to the same file as the artifact with the class-files.
>
> You can solve it by either:
> - add the [type] token to your retrieve pattern, or
> - add type="jar" when calling ivy:retrieve
>
> Maarten
>
>
>
>
> ----- Original Message ----
> From: Kent Larsson <ke...@gmail.com>
> To: ivy-user@ant.apache.org
> Sent: Saturday, February 28, 2009 10:40:15 PM
> Subject: Possible bug in Ivy 2.0.0? I get undeterministic behavior.
>
> Hi,
>
> I'm using Ivy and was very happy about my experience with it, until
> now. I hope that the problems I am experiencing are due to some error
> on my behalf.
>
> Here is my scenario:
>
> 1. I'm downloading Ivy 2.0.0 dynamically from
> http://repo1.maven.org/maven2/org/apache/ivy/ivy/ just like in the
> "Automatic" example from
> http://ant.apache.org/ivy/history/latest-release/install.html except
> that I get 2.0.0 instead of 2.0.0-beta1.
> 2. I do not use any ivysettings.xml as I was happy with the default values.
>
> When I retrieve my dependencies and synchronize them with my Ivy lib
> dir I get unreliable behavior. The JAR-files I get are of different
> sizes from time to time, and my project seldom compiles. It doesn't
> happen to all my dependencies, just a few of them.
>
> I attach a tarball ( using bzip2-compression ) with a BASH script I
> created which reproduce the problem:
> - Change working directory into ivy-problem and run script.sh
> - It will retrieve the dependencies 15 times (easy to change) and record
>    * The ant output for each iteration in stats/ant-output<N>.txt
>    * The file names and sizes in the lib folder for each iteration in
> stats/find-output<N>.txt
>    * The lib directory of each iteration in lib<N>
> - It will check which find-ouput<N>.txt files that match each other
> and which differs, that output will reside in stats/diffs-and-matches
>
> Please investigate further, this is a really serious issue and if it
> is a bug (I hope not) it's one that affects the users in the worst
> possible way.
>
> The ivy.xml and build.xml are from parts of a project I'm working on,
> if there is anything I can do to get reliable behavior from Ivy right
> away I'm very interested in knowing about it.
>
> Best regards,
> Kent
>
>
>
>
>



      

Re: Possible bug in Ivy 2.0.0? I get undeterministic behavior.

Posted by Kent Larsson <ke...@gmail.com>.
Thank you! It worked. :-)

Can I give a feature request? Ivy could store which files it outputs
and if it overwrites a file it could at least give a warning that it
has done so. For these circumstances, when a pattern results in
overwritten files, it's always an error and if the project builds it's
pure luck? In that case a textual warning would be great, I would
stretch it so far as the build failing as something is obviously very
wrong.

Best regards, Kent


On Sun, Mar 1, 2009 at 11:20 PM, Maarten Coene <ma...@yahoo.com> wrote:
> I think it's caused because Ivy automatically adds source and javadocs artifacts to the maven modules if they are available. When you do the ivy:retrieve, you will also retrieve these sources/javadocs, but your retrieve-pattern maps the sources/javadocs artifacts to the same file as the artifact with the class-files.
>
> You can solve it by either:
> - add the [type] token to your retrieve pattern, or
> - add type="jar" when calling ivy:retrieve
>
> Maarten
>
>
>
>
> ----- Original Message ----
> From: Kent Larsson <ke...@gmail.com>
> To: ivy-user@ant.apache.org
> Sent: Saturday, February 28, 2009 10:40:15 PM
> Subject: Possible bug in Ivy 2.0.0? I get undeterministic behavior.
>
> Hi,
>
> I'm using Ivy and was very happy about my experience with it, until
> now. I hope that the problems I am experiencing are due to some error
> on my behalf.
>
> Here is my scenario:
>
> 1. I'm downloading Ivy 2.0.0 dynamically from
> http://repo1.maven.org/maven2/org/apache/ivy/ivy/ just like in the
> "Automatic" example from
> http://ant.apache.org/ivy/history/latest-release/install.html except
> that I get 2.0.0 instead of 2.0.0-beta1.
> 2. I do not use any ivysettings.xml as I was happy with the default values.
>
> When I retrieve my dependencies and synchronize them with my Ivy lib
> dir I get unreliable behavior. The JAR-files I get are of different
> sizes from time to time, and my project seldom compiles. It doesn't
> happen to all my dependencies, just a few of them.
>
> I attach a tarball ( using bzip2-compression ) with a BASH script I
> created which reproduce the problem:
> - Change working directory into ivy-problem and run script.sh
> - It will retrieve the dependencies 15 times (easy to change) and record
>    * The ant output for each iteration in stats/ant-output<N>.txt
>    * The file names and sizes in the lib folder for each iteration in
> stats/find-output<N>.txt
>    * The lib directory of each iteration in lib<N>
> - It will check which find-ouput<N>.txt files that match each other
> and which differs, that output will reside in stats/diffs-and-matches
>
> Please investigate further, this is a really serious issue and if it
> is a bug (I hope not) it's one that affects the users in the worst
> possible way.
>
> The ivy.xml and build.xml are from parts of a project I'm working on,
> if there is anything I can do to get reliable behavior from Ivy right
> away I'm very interested in knowing about it.
>
> Best regards,
> Kent
>
>
>
>
>