DO NOT REPLY [Bug 42044] Multiple/composite logs for ant builds
https://issues.apache.org/bugzilla/show_bug.cgi?id=42044 --- Comment #2 from Owen Boyle [EMAIL PROTECTED] 2008-04-25 05:30:19 PST --- Created an attachment (id=21851) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=21851) lsof output for various cases of logging lsof output indicating number of pipes used for each combination of: 3 apache versions (2.2.6, 2.2.8 unpatched, 2.2.8 patched) by 3 config cases (T+E logs in main config, T+E in 1 VH, t+E in 2 VHs). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 42044] Multiple/composite logs for ant builds
https://issues.apache.org/bugzilla/show_bug.cgi?id=42044 --- Comment #3 from Owen Boyle [EMAIL PROTECTED] 2008-04-25 05:32:22 PST --- Please ignore recent attachment - it went to the wrong bug... sorry. (why oh why does bugzilla go to a random bug after posting?) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[jira] Created: (IVY-809) Using ivy:settings with the id attribute not behaving as expected.
Using ivy:settings with the id attribute not behaving as expected. Key: IVY-809 URL: https://issues.apache.org/jira/browse/IVY-809 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 2.0.0-beta-2 Environment: Fedora 9 ANT 1.6.5 / Ant 1.7.0 Reporter: Matt Inger Attachments: build.xml Using the attached build file, I have encountered 2 issues: 1. When using ivy:settings with the id attribute, i get an immediate failure if I do not use the override flag: Buildfile: build.xml foo: BUILD FAILED /home/minger/build.xml:5: overriding a previous definition of ivy:settings with the id 'settings1' is not allowed when using override='notallowed'. Total time: 0 seconds 2. If i enable the override flag (as done in the bar target), it seems to be constructing the deafult ivy instance when i execute a resolve or post-resolve task with a settingsRef defined. It seems to still pick up on the reference it's given. However, it should not need to create the default ivy.settings instance if you give it a reference. In fact, it's very confusing and misleading to the user. Not to mention the [null] task name it's outputting in that case. it also seems that the default ivy instance is using deprecated elements and/or properties. Buildfile: build.xml bar: :: Ivy 2.0.0-beta2 - 20080225093827 :: http://ant.apache.org/ivy/ :: [ivy:settings] :: loading settings :: file = /home/minger/ivysettings.xml No ivy:settings found for the default reference 'ivy.instance'. A default instance will be used [null] DEPRECATED: 'ivy.conf.file' is deprecated, use 'ivy.settings.file' instead [null] :: loading settings :: file = /home/minger/ivysettings.xml [ivy:cachepath] :: resolving dependencies :: apache#commons-lang-caller;working [ivy:cachepath] confs: [default] [ivy:cachepath] found apache#commons-lang;2.3 in master-http [ivy:cachepath] :: resolution report :: resolve 118ms :: artifacts dl 5ms - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | default | 1 | 0 | 0 | 0 || 1 | 0 | - BUILD SUCCESSFUL Total time: 1 second -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
DO NOT REPLY [Bug 44873] New: Mapper behaviour is different when using Java 6
https://issues.apache.org/bugzilla/show_bug.cgi?id=44873
Summary: Mapper behaviour is different when using Java 6
Product: Ant
Version: 1.7.0
Platform: PC
OS/Version: Windows XP
Status: NEW
Severity: normal
Priority: P2
Component: Core
AssignedTo: notifications@ant.apache.org
ReportedBy: [EMAIL PROTECTED]
To be specific: using glob mappers and identity mappers within composite
mappers has different behaviour if using Java 6.
My build contains the following:
target name=-export if=project.exports
mkdir dir=${dir.exp}/
copy todir=${dir.exp}
fileset dir=${dir.jar} includesfile=${file.exports}
excludes=${pattern.dist.jars.exclude}/
compositemapper
globmapper from=*-standalone.jar to=*.jar/
globmapper from=*-common.jar to=*.jar/
identitymapper/ !-- let anything else through --
/compositemapper
/copy
/target
The intended behaviour of this is to rename any {project}-standalone or
{project}-common jar to {project}.jar, but let the jars go as they are
otherwise. This works as expected with Java 1.4.2 or Java 5 (1.5.0_12):
-export:
[mkdir] Skipping D:\projects\NR52\TIGUtils\export because it already
exists.
fileset: Setup scanner in dir D:\projects\NR52\TIGUtils\tmp\jar with
patternSet{ includes: [] excludes: [] }
[copy] TIGUtils-common.jar added as TIGUtils.jar doesn't exist.
[copy] No sources found.
[copy] Copying 1 file to D:\projects\NR52\TIGUtils\export
[copy] Copying D:\projects\NR52\TIGUtils\tmp\jar\TIGUtils-common.jar to
D:\projects\NR52\TIGUtils\export\TIGUtils.jar
However, when using Java 6 (update 2 or update 6) this does not work:
-export:
[mkdir] Skipping D:\projects\NR52\TIGUtils\export because it already
exists.
fileset: Setup scanner in dir D:\projects\NR52\TIGUtils\tmp\jar with
patternSet{ includes: [] excludes: [] }
[copy] TIGUtils-common.jar added as TIGUtils-common.jar is outdated.
[copy] No sources found.
[copy] Copying 1 file to D:\projects\NR52\TIGUtils\export
[copy] Copying D:\projects\NR52\TIGUtils\tmp\jar\TIGUtils-common.jar to
D:\projects\NR52\TIGUtils\export\TIGUtils-common.jar
When using just the two globmappers, the functionality is as expected, but any
jars that do not match the pattern will not be copied at all. The workaround is
to use two copy tasks, but I would rather keep it the way it is. I'm surprised
the behaviour is inconsistent between java versions.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
[EMAIL PROTECTED]: Project test-ant (in module ant) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project test-ant has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 7 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - test-ant : Java based build tool Full details are available at: http://vmgump.apache.org/gump/public/ant/test-ant/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Optional dependency jakarta-tomcat-4.0 prerequisite failed with reason build failed -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/ant/test-ant/gump_work/build_ant_test-ant.html Work Name: build_ant_test-ant (Type: Build) Work ended in a state of : Failed Elapsed: 15 mins 56 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true -Xbootclasspath/p:/srv/gump/public/workspace/xml-xerces2/build/xercesImpl.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar:/srv/gump/public/workspace/xml-xalan/build/serializer.jar:/srv/gump/public/workspace/xml-xalan/build/xalan-unbundled.jar org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtest.haltonfailure=false -Dant.home=/srv/gump/public/workspace/ant/dist run-tests [Working Directory: /srv/gump/public/workspace/ant] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/build/testcases:/srv/gump/public/workspace/ant/src/tests/junit:/srv/gump/public/workspace/ant/src/etc/testcases:/srv/gump/public/workspace/ant/src/etc/testcases/taskdefs/optional/out:/srv/gump/public/workspace/ant/build/lib/ant-stylebook.jar:/srv/gump/public/workspace/ant/build/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/build/lib/ant-swing.jar:/srv/gump/public/workspace/ant/build/lib/ant-junit.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/build/lib/ant-javamail.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bcel.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-regexp.jar:/srv/gump/public/workspace/ant/build/lib/ant-trax.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-net.jar:/srv/gump/public/workspace/ant/build/lib/ant-jsch.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-log4j.jar:/srv/gump/public/worksp ace/ant/build/lib/ant-antlr.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-logging.jar:/srv/gump/public/workspace/ant/build/lib/ant-jdepend.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bsf.jar:/srv/gump/public/workspace/ant/build/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/build/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-oro.jar:/srv/gump/public/workspace/ant/build/lib/ant.jar:/srv/gump/public/workspace/ant/build/lib/ant-jai.jar:/srv/gump/packages/antlr-2.7.6/antlr.jar:commons-logging-gump-23042008.jar:commons-logging-api-gump-23042008.jar:/srv/gump/public/workspace/apache-commons/net/dist/commons-net-25042008.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/public/workspace/jakarta-bcel/target/bcel-5.3-SNAPSHOT.jar:bsf-gump-23042008.jar:/srv/gump/public/workspace/logging-log4j-12/dist/lib/log4j-25042008.jar:/srv/gump/public/workspace/jakarta-oro/jakarta-oro-25042008.jar:/srv/gump/public/workspace/jakarta-rege xp/build/jakarta-regexp-25042008.jar:/srv/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jdepend-2.6/lib/jdepend.jar:/srv/gump/packages/jsch/jsch-0.1.28.jar:/srv/gump/public/workspace/xml-stylebook/bin/stylebook-1.0-b3_xalan-2.jar:/srv/gump/public/workspace/ant-antlibs/antunit/build/ant-antunit-25042008.jar:/srv/gump/public/workspace/junit/dist/junit-25042008.jar:/srv/gump/public/workspace/xml-commons/java/external/build/xml-apis-ext.jar:/srv/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-compiler.jar:/srv/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-runtime.jar:/srv/gump/public/workspace/xml-commons/java/build/which.jar:/srv/gump/public/workspace/rhino/build/rhino_25042008/js.jar:/srv/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-core- 2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/srv/gump/public/workspace/apache-commons/codec/dist/commons-codec-25042008.jar
DO NOT REPLY [Bug 44873] Mapper behaviour is different when using Java 6
https://issues.apache.org/bugzilla/show_bug.cgi?id=44873 --- Comment #1 from Peter Reilly [EMAIL PROTECTED] 2008-04-25 09:25:52 PST --- Thanks for the report. Can you give a name of a file that that works on java5 and does not work on java6 - it will help with debuging. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
DO NOT REPLY [Bug 44873] Mapper behaviour is different when using Java 6
https://issues.apache.org/bugzilla/show_bug.cgi?id=44873 --- Comment #2 from Edward Steel [EMAIL PROTECTED] 2008-04-25 09:28:44 PST --- Sure. The input dir contains a TIGUtils-common.jar, which is expected to map to TIGUtils.jar in the output dir. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[EMAIL PROTECTED]: Project test-ant-no-xerces (in module ant) failed
To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project test-ant-no-xerces has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - test-ant-no-xerces : Java based build tool Full details are available at: http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Optional dependency jakarta-tomcat-4.0 prerequisite failed with reason build failed -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/gump_work/build_ant_test-ant-no-xerces.html Work Name: build_ant_test-ant-no-xerces (Type: Build) Work ended in a state of : Failed Elapsed: 11 mins 44 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtest.haltonfailure=false -Dant.home=/srv/gump/public/workspace/ant/dist run-tests [Working Directory: /srv/gump/public/workspace/ant] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/build/testcases:/srv/gump/public/workspace/ant/src/tests/junit:/srv/gump/public/workspace/ant/src/etc/testcases:/srv/gump/public/workspace/ant/src/etc/testcases/taskdefs/optional/out:/srv/gump/public/workspace/ant/build/lib/ant-stylebook.jar:/srv/gump/public/workspace/ant/build/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/build/lib/ant-swing.jar:/srv/gump/public/workspace/ant/build/lib/ant-junit.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/build/lib/ant-javamail.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bcel.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-regexp.jar:/srv/gump/public/workspace/ant/build/lib/ant-trax.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-net.jar:/srv/gump/public/workspace/ant/build/lib/ant-jsch.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-log4j.jar:/srv/gump/public/worksp ace/ant/build/lib/ant-antlr.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-logging.jar:/srv/gump/public/workspace/ant/build/lib/ant-jdepend.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bsf.jar:/srv/gump/public/workspace/ant/build/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/build/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-oro.jar:/srv/gump/public/workspace/ant/build/lib/ant.jar:/srv/gump/public/workspace/ant/build/lib/ant-jai.jar:/srv/gump/packages/antlr-2.7.6/antlr.jar:commons-logging-gump-23042008.jar:commons-logging-api-gump-23042008.jar:/srv/gump/public/workspace/apache-commons/net/dist/commons-net-25042008.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/public/workspace/jakarta-bcel/target/bcel-5.3-SNAPSHOT.jar:bsf-gump-23042008.jar:/srv/gump/public/workspace/logging-log4j-12/dist/lib/log4j-25042008.jar:/srv/gump/public/workspace/jakarta-oro/jakarta-oro-25042008.jar:/srv/gump/public/workspace/jakarta-rege xp/build/jakarta-regexp-25042008.jar:/srv/gump/public/workspace/jakarta-servletapi-4/lib/servlet.jar:/srv/gump/packages/javamail-1.4/mail.jar:/srv/gump/packages/javamail-1.4/lib/mailapi.jar:/srv/gump/packages/jdepend-2.6/lib/jdepend.jar:/srv/gump/packages/jsch/jsch-0.1.28.jar:/srv/gump/public/workspace/xml-stylebook/bin/stylebook-1.0-b3_xalan-2.jar:/srv/gump/public/workspace/ant-antlibs/antunit/build/ant-antunit-25042008.jar:/srv/gump/public/workspace/junit/dist/junit-25042008.jar:/srv/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-compiler.jar:/srv/gump/public/workspace/jakarta-tomcat-4.0/dist/common/lib/jasper-runtime.jar:/srv/gump/public/workspace/xml-commons/java/build/which.jar:/srv/gump/public/workspace/rhino/build/rhino_25042008/js.jar:/srv/gump/packages/bsh-2.0b4/bsh-commands-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-classpath-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-core-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-bsf-2.0b4.jar:/srv/gump/packages/ bsh-2.0b4/bsh-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-reflect-2.0b4.jar:/srv/gump/packages/bsh-2.0b4/bsh-util-2.0b4.jar:/srv/gump/public/workspace/apache-commons/codec/dist/commons-codec-25042008.jar - [au:antunit] Target: testValueWorks caused an ERROR [au:antunit]at line 78, column 33 [au:antunit]Message: The following error occurred while executing this line: [au:antunit]
[jira] Commented: (IVY-809) Using ivy:settings with the id attribute not behaving as expected.
[ https://issues.apache.org/jira/browse/IVY-809?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592443#action_12592443 ] Matt Inger commented on IVY-809: Are both of these fixed in the trunk? I will build from source and give it a shot, but i don't want this closed out if both of these issues are not fixed in the trunk. Using ivy:settings with the id attribute not behaving as expected. Key: IVY-809 URL: https://issues.apache.org/jira/browse/IVY-809 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 2.0.0-beta-2 Environment: Fedora 9 ANT 1.6.5 / Ant 1.7.0 Reporter: Matt Inger Attachments: build.xml, ivysettings.properties, ivysettings.xml Using the attached build file, I have encountered 2 issues: 1. When using ivy:settings with the id attribute, i get an immediate failure if I do not use the override flag: Buildfile: build.xml foo: BUILD FAILED /home/minger/build.xml:5: overriding a previous definition of ivy:settings with the id 'settings1' is not allowed when using override='notallowed'. Total time: 0 seconds 2. If i enable the override flag (as done in the bar target), it seems to be constructing the deafult ivy instance when i execute a resolve or post-resolve task with a settingsRef defined. It seems to still pick up on the reference it's given. However, it should not need to create the default ivy.settings instance if you give it a reference. In fact, it's very confusing and misleading to the user. Not to mention the [null] task name it's outputting in that case. it also seems that the default ivy instance is using deprecated elements and/or properties. Buildfile: build.xml bar: :: Ivy 2.0.0-beta2 - 20080225093827 :: http://ant.apache.org/ivy/ :: [ivy:settings] :: loading settings :: file = /home/minger/ivysettings.xml No ivy:settings found for the default reference 'ivy.instance'. A default instance will be used [null] DEPRECATED: 'ivy.conf.file' is deprecated, use 'ivy.settings.file' instead [null] :: loading settings :: file = /home/minger/ivysettings.xml [ivy:cachepath] :: resolving dependencies :: apache#commons-lang-caller;working [ivy:cachepath] confs: [default] [ivy:cachepath] found apache#commons-lang;2.3 in master-http [ivy:cachepath] :: resolution report :: resolve 118ms :: artifacts dl 5ms - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | default | 1 | 0 | 0 | 0 || 1 | 0 | - BUILD SUCCESSFUL Total time: 1 second -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-809) Using ivy:settings with the id attribute not behaving as expected.
[ https://issues.apache.org/jira/browse/IVY-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-809. --- Resolution: Fixed Fix Version/s: 2.0-RC1 Assignee: Maarten Coene I've committed a fix to SVN trunk that will hopefully solve your second issue. Could you give it a try? Using ivy:settings with the id attribute not behaving as expected. Key: IVY-809 URL: https://issues.apache.org/jira/browse/IVY-809 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 2.0.0-beta-2 Environment: Fedora 9 ANT 1.6.5 / Ant 1.7.0 Reporter: Matt Inger Assignee: Maarten Coene Fix For: 2.0-RC1 Attachments: build.xml, ivysettings.properties, ivysettings.xml Using the attached build file, I have encountered 2 issues: 1. When using ivy:settings with the id attribute, i get an immediate failure if I do not use the override flag: Buildfile: build.xml foo: BUILD FAILED /home/minger/build.xml:5: overriding a previous definition of ivy:settings with the id 'settings1' is not allowed when using override='notallowed'. Total time: 0 seconds 2. If i enable the override flag (as done in the bar target), it seems to be constructing the deafult ivy instance when i execute a resolve or post-resolve task with a settingsRef defined. It seems to still pick up on the reference it's given. However, it should not need to create the default ivy.settings instance if you give it a reference. In fact, it's very confusing and misleading to the user. Not to mention the [null] task name it's outputting in that case. it also seems that the default ivy instance is using deprecated elements and/or properties. Buildfile: build.xml bar: :: Ivy 2.0.0-beta2 - 20080225093827 :: http://ant.apache.org/ivy/ :: [ivy:settings] :: loading settings :: file = /home/minger/ivysettings.xml No ivy:settings found for the default reference 'ivy.instance'. A default instance will be used [null] DEPRECATED: 'ivy.conf.file' is deprecated, use 'ivy.settings.file' instead [null] :: loading settings :: file = /home/minger/ivysettings.xml [ivy:cachepath] :: resolving dependencies :: apache#commons-lang-caller;working [ivy:cachepath] confs: [default] [ivy:cachepath] found apache#commons-lang;2.3 in master-http [ivy:cachepath] :: resolution report :: resolve 118ms :: artifacts dl 5ms - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | default | 1 | 0 | 0 | 0 || 1 | 0 | - BUILD SUCCESSFUL Total time: 1 second -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-810) Duplidate entries after a resolve.
Duplidate entries after a resolve. -- Key: IVY-810 URL: https://issues.apache.org/jira/browse/IVY-810 Project: Ivy Issue Type: Bug Affects Versions: 2.0.0-beta-2 Reporter: James Rosko I'm getting this error in the ivy console: There are some duplicates entries due to conflicts between the resolved configurations (*): I'm using the latest-revision conflict-manager. Project A has two dependencies that depend on different versions of a 4th project. A is getting both versions. A depends on B and B depends on version 1 of D. A also depends on C and C depends on version 2 of D. In this case A does not directly depend on D. D is not listed as a dependency of projects A's ivy.xml file. A-B-D1 and A-C-D2 The problem does not occur when A directly depends on D A-D What could be causing this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-810) Duplidate entries after a resolve.
[ https://issues.apache.org/jira/browse/IVY-810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Rosko updated IVY-810: Description: I'm getting this error in the ivy console: There are some duplicates entries due to conflicts between the resolved configurations (*): and one dependent module is being picked up twice, two versions of the same project. I'm using the latest-revision conflict-manager. Project A has two dependencies that depend on different versions of a 4th project. A is getting both versions. A depends on B and B depends on version 1 of D. A also depends on C and C depends on version 2 of D. In this case A does not directly depend on D. D is not listed as a dependency of projects A's ivy.xml file. A-B-D1 and A-C-D2 The problem does not occur when A directly depends on D A-D What could be causing this? was: I'm getting this error in the ivy console: There are some duplicates entries due to conflicts between the resolved configurations (*): I'm using the latest-revision conflict-manager. Project A has two dependencies that depend on different versions of a 4th project. A is getting both versions. A depends on B and B depends on version 1 of D. A also depends on C and C depends on version 2 of D. In this case A does not directly depend on D. D is not listed as a dependency of projects A's ivy.xml file. A-B-D1 and A-C-D2 The problem does not occur when A directly depends on D A-D What could be causing this? Duplidate entries after a resolve. -- Key: IVY-810 URL: https://issues.apache.org/jira/browse/IVY-810 Project: Ivy Issue Type: Bug Affects Versions: 2.0.0-beta-2 Reporter: James Rosko I'm getting this error in the ivy console: There are some duplicates entries due to conflicts between the resolved configurations (*): and one dependent module is being picked up twice, two versions of the same project. I'm using the latest-revision conflict-manager. Project A has two dependencies that depend on different versions of a 4th project. A is getting both versions. A depends on B and B depends on version 1 of D. A also depends on C and C depends on version 2 of D. In this case A does not directly depend on D. D is not listed as a dependency of projects A's ivy.xml file. A-B-D1 and A-C-D2 The problem does not occur when A directly depends on D A-D What could be causing this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
