[jira] [Commented] (IVY-1586) Retrieves test-library instead of binary-library
[ https://issues.apache.org/jira/browse/IVY-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952266#comment-16952266 ] Sebastian Nagel commented on IVY-1586: -- Yes, I've removed the ~/.ivy2/ folder before running "ant". I've tried it twice and now again to be sure. Interestingly, I was able to build Nutch with the new ivy lib and an empty cache. > Retrieves test-library instead of binary-library > > > Key: IVY-1586 > URL: https://issues.apache.org/jira/browse/IVY-1586 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.5.0-rc1 > Environment: Eclipse Photon 4.8.0 64bit > Ant 1.10.3.v20180417-1627 > Apache IvyDE 2.2.0.final-201311091524-RELEASE > Apache Ivy 2.5.0.cr1_20180412005306 >Reporter: Arni Schulze >Assignee: Jaikiran Pai >Priority: Blocker > Fix For: master > > Attachments: Ant_1st_output.txt, Ant_2nd_output.txt, build.xml, > ivy-1586-test.zip, ivy.xml > > > If I delete the local Ivy cache and run my Ant script to retrieve > "ch.quos.logback logback-classic 1.2.3" I get the correct library and its > dependencies (see Ant_1st_output). > But if I run the Ant script again (now having a local Ivy cache) it retrieves > the test-library and the test-library of the dependencies instead of the > correct ones (see Ant_2nd_output). > I added minimalistic ivy.xml and Ant script. Because of the different > behavior of the first and every other run, I think this is a bug in Ivy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IVY-1586) Retrieves test-library instead of binary-library
[ https://issues.apache.org/jira/browse/IVY-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16952026#comment-16952026 ] Jaikiran Pai commented on IVY-1586: --- I remember trying your very own attached project to get this working. Before I verify it again, just one quick question - you tried this against a clean/fresh Ivy cache right? > Retrieves test-library instead of binary-library > > > Key: IVY-1586 > URL: https://issues.apache.org/jira/browse/IVY-1586 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.5.0-rc1 > Environment: Eclipse Photon 4.8.0 64bit > Ant 1.10.3.v20180417-1627 > Apache IvyDE 2.2.0.final-201311091524-RELEASE > Apache Ivy 2.5.0.cr1_20180412005306 >Reporter: Arni Schulze >Assignee: Jaikiran Pai >Priority: Blocker > Fix For: master > > Attachments: Ant_1st_output.txt, Ant_2nd_output.txt, build.xml, > ivy-1586-test.zip, ivy.xml > > > If I delete the local Ivy cache and run my Ant script to retrieve > "ch.quos.logback logback-classic 1.2.3" I get the correct library and its > dependencies (see Ant_1st_output). > But if I run the Ant script again (now having a local Ivy cache) it retrieves > the test-library and the test-library of the dependencies instead of the > correct ones (see Ant_2nd_output). > I added minimalistic ivy.xml and Ant script. Because of the different > behavior of the first and every other run, I think this is a bug in Ivy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[Bug 62617] Honor SOURCE_DATE_EPOCH to allow reproducible builds
https://bz.apache.org/bugzilla/show_bug.cgi?id=62617 --- Comment #2 from Jonas Witschel --- Hi Jaikiran, I would be very interested in reproducible build support in Apache Ant as well. >(In reply to Jaikiran Pai from comment #1) > I think, the proposed patch might not preserve the current behaviour. Since, > right now, even if the SOURCE_DATE_EPOCH is set in the system where the > build is run, the tstamp task will not use it and instead will use the > current time. With this patch, the behaviour will change in such build > files. I don't see the point in preserving backwards compatibility in this case: if SOURCE_DATE_EPOCH is set, the user explicitly expects time stamps to be set to this fixed date instead of the current time as per the specification Julien linked above. Using the current time instead is undesirable behaviour if the environment variable is set, so I would consider the current behaviour a bug that requires backwards-incompatible changes in order to be fixed. Maybe it's a better idea to have an explicitly set attribute (a new > attribute) on the task which will start honouring this environment variable? > That way the default semantics of the attribute can continue to ignore this > environment variable unless explicitly set to honour it. Some attribute like > "useSourceDateEpoch". That would defeat the goal of having reproducible support by default: every projects needs to be aware of this attribute and explicitly set it, which will not happen e.g. for legacy projects. All artifacts created by Apache Ant should be reproducible out of the box if SOURCE_DATE_EPOCH is set. > I believe you will need a epoch != null check here. In its current form, > this will lead to a NPE on systems where the environment variable isn't set. > Furthermore, I don't think the compareTo call is required. The "spec" that > you pointed to, in the linked content, explicitly states that the value of > such an environment variable MUST be an integer, so I think you can just try > to use it as an Integer value. If you still want to check if the environment > variable value is empty, then I think epoch.isEmpty() is a better API to use. ACK on the review of the patch. -- You are receiving this mail because: You are the assignee for the bug.
[jira] [Commented] (IVY-1586) Retrieves test-library instead of binary-library
[
https://issues.apache.org/jira/browse/IVY-1586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16951929#comment-16951929
]
Sebastian Nagel commented on IVY-1586:
--
Hi [~jaikiran], when running ant/ivy with the attached ivy-1586-test.zip file I
still get an error:
{noformat}
> rm -rf ~/.ivy2/
> mkdir lib
> ant -d -v -lib .
...
[ivy:resolve] :: Apache Ivy 2.5.0-rc2-local-20191011045141 - 20191011045141 ::
https://ant.apache.org/ivy/ ::
...
BUILD FAILED
.../ivy-1586-3/build.xml:10: impossible to ivy retrieve:
java.lang.RuntimeException: problem during retrieve of
MyOrganisation#IvyResolveBug: java.lang.RuntimeException: Multiple artifacts of
the module org.seleniumhq.selenium#selenium-java;3.141.59 are retrieved to the
same file! Update the retrieve pattern to fix this error.
...
{noformat}
> Retrieves test-library instead of binary-library
>
>
> Key: IVY-1586
> URL: https://issues.apache.org/jira/browse/IVY-1586
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.5.0-rc1
> Environment: Eclipse Photon 4.8.0 64bit
> Ant 1.10.3.v20180417-1627
> Apache IvyDE 2.2.0.final-201311091524-RELEASE
> Apache Ivy 2.5.0.cr1_20180412005306
>Reporter: Arni Schulze
>Assignee: Jaikiran Pai
>Priority: Blocker
> Fix For: master
>
> Attachments: Ant_1st_output.txt, Ant_2nd_output.txt, build.xml,
> ivy-1586-test.zip, ivy.xml
>
>
> If I delete the local Ivy cache and run my Ant script to retrieve
> "ch.quos.logback logback-classic 1.2.3" I get the correct library and its
> dependencies (see Ant_1st_output).
> But if I run the Ant script again (now having a local Ivy cache) it retrieves
> the test-library and the test-library of the dependencies instead of the
> correct ones (see Ant_2nd_output).
> I added minimalistic ivy.xml and Ant script. Because of the different
> behavior of the first and every other run, I think this is a bug in Ivy.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[Bug 63850] LegacyXmlResultFormatter of JUnitLauncher Task does not log Exceptions in @BeforeAll
https://bz.apache.org/bugzilla/show_bug.cgi?id=63850 --- Comment #3 from mse...@guh-software.de --- Created attachment 36833 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36833=edit JUnit5 XML (incorrect) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 63850] LegacyXmlResultFormatter of JUnitLauncher Task does not log Exceptions in @BeforeAll
https://bz.apache.org/bugzilla/show_bug.cgi?id=63850 --- Comment #2 from mse...@guh-software.de --- Created attachment 36832 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36832=edit JUnit4 XML (correct) -- You are receiving this mail because: You are the assignee for the bug.
[Bug 63850] LegacyXmlResultFormatter of JUnitLauncher Task does not log Exceptions in @BeforeAll
https://bz.apache.org/bugzilla/show_bug.cgi?id=63850 --- Comment #1 from mse...@guh-software.de --- Created attachment 36831 --> https://bz.apache.org/bugzilla/attachment.cgi?id=36831=edit ExampleTest.java -- You are receiving this mail because: You are the assignee for the bug.
[Bug 63850] New: LegacyXmlResultFormatter of JUnitLauncher Task does not log Exceptions in @BeforeAll
https://bz.apache.org/bugzilla/show_bug.cgi?id=63850 Bug ID: 63850 Summary: LegacyXmlResultFormatter of JUnitLauncher Task does not log Exceptions in @BeforeAll Product: Ant Version: 1.10.7 Hardware: PC Status: NEW Severity: normal Priority: P2 Component: Optional Tasks Assignee: notifications@ant.apache.org Reporter: mse...@guh-software.de Target Milestone: --- LegacyXmlResultFormatter of JUnitLauncher Task does not log Exceptions in @BeforeAll. Please see my attached Example Test Case and the JUnit5 and JUnit4 XMLs. Maybe @AfterAll has the same bug, i did not test that. -- You are receiving this mail because: You are the assignee for the bug.
