DO NOT REPLY [Bug 49261] Copy task fails to overwrite readonly files even with overwrite=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=49261 Stefan Bodewig bode...@apache.org changed: What|Removed |Added OS/Version||All --- Comment #1 from Stefan Bodewig bode...@apache.org 2010-05-07 05:14:26 EDT --- My guess is that our changed copy code using NIO is taking the target's permissions into account whlie the old stream based approach did not. overwrite really only says write even if the dest isn't out of date and never had any influence on whether a readonly dest file would get overwritten. If you create dest befaore source in your testcase Ant 1.7.1 will happily overwrite dest without the overwrite attribute as well. I must admit that I actually like the change - Ant shouldn't ignore the read-only state if the destination. We may want to throw in an additional attribute that controls the behavior. If my guess is correct then you can trick Ant into using the non-NIO code by filtering- i.e. you could throw in a filter that doesn't change your files. This will not work for binary files. Another trick would be to ZIP or TAR up the sources and extract from there since the NIO code is only used if source and dest are files and no filtering occurs at all. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
svn commit: r942085 - /ant/core/trunk/src/tests/antunit/taskdefs/copy-test.xml
Author: bodewig
Date: Fri May 7 14:32:09 2010
New Revision: 942085
URL: http://svn.apache.org/viewvc?rev=942085view=rev
Log:
testcase for PR 49261
Modified:
ant/core/trunk/src/tests/antunit/taskdefs/copy-test.xml
Modified: ant/core/trunk/src/tests/antunit/taskdefs/copy-test.xml
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/tests/antunit/taskdefs/copy-test.xml?rev=942085r1=942084r2=942085view=diff
==
--- ant/core/trunk/src/tests/antunit/taskdefs/copy-test.xml (original)
+++ ant/core/trunk/src/tests/antunit/taskdefs/copy-test.xml Fri May 7 14:32:09
2010
@@ -295,4 +295,61 @@ public class NullByteStreamResource exte
/copy
/target
+ !-- stolen from ../types/readwrite-test.xml - create a read-only file --
+ property name=file value=testfile/
+ condition property=unix
+os family=unix/
+ /condition
+ target name=createTestdir
+mkdir dir=${output}/
+mkdir dir=${input}/
+touch file=${output}/${file}/
+ /target
+ target name=makeFileUnwritable
+
depends=createTestdir,makeFileUnwritable-Unix,makeFileUnwritable-Windows/
+ target name=makeFileUnwritable-Unix id=unix
+chmod file=${output}/${file} perm=444/
+ /target
+ target name=makeFileUnwritable-Windows unless=unix
+attrib file=${output}/${file} readonly=true/
+ /target
+
+ target name=XtestCopyOverReadOnlyFile depends=makeFileUnwritable
+sleep seconds=2/
+touch file=${input}/${file}/
+copy toDir=${output}
+ fileset dir=${input}/
+/copy
+ /target
+
+ target name=testFilteredCopyOverReadOnlyFile depends=makeFileUnwritable
+sleep seconds=2/
+touch file=${input}/${file}/
+copy toDir=${output}
+ fileset dir=${input}/
+ filterset
+filter token=foo value=bar/
+ /filterset
+/copy
+ /target
+
+ target name=XtestCopyOverReadOnlyFileWithOverwrite
+ depends=makeFileUnwritable
+touch file=${input}/${file}/
+copy toDir=${output} overwrite=true
+ fileset dir=${input}/
+/copy
+ /target
+
+ target name=testFilteredCopyOverReadOnlyFileWithOverwrite
+ depends=makeFileUnwritable
+touch file=${input}/${file}/
+copy toDir=${output} overwrite=true
+ fileset dir=${input}/
+ filterset
+filter token=foo value=bar/
+ /filterset
+/copy
+ /target
+
/project
DO NOT REPLY [Bug 49261] Copy task fails to overwrite readonly files even with overwrite=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=49261 --- Comment #2 from Stefan Bodewig bode...@apache.org 2010-05-07 10:34:56 EDT --- my guess seems to be correct. I've added four testcases to Ant in svn revision 942805 - two of them disabled because they fail with Ant 1.8.x. If I specify a dummy filterset Ant will happily overwrite the existing file, without one - when Ant uses NIO - it won't but throw an exception instead. Discussion about how to deal with it for Ant 1.8.2 will follow on the dev list. -- 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 49261] Copy task fails to overwrite readonly files even with overwrite=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=49261 --- Comment #3 from Stefan Bodewig bode...@apache.org 2010-05-07 10:36:11 EDT --- (In reply to comment #2) in revision 942805 should have been svn revision 942085 -- 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 49117] Unable to rename old file to temporary file JAR TASK
https://issues.apache.org/bugzilla/show_bug.cgi?id=49117 --- Comment #14 from Arinjay arinjay...@gmail.com 2010-05-07 10:37:57 EDT --- (In reply to comment #13) Created an attachment (id=25341) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25341) [details] test using antcall I'm afraid the antcall layer isn't enough to cause problems - the attached build file still works for me. Sorry for the delay! I will require your email id ...will not be possible to send you the build but will try to reproduce something similar. -- 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 49117] Unable to rename old file to temporary file JAR TASK
https://issues.apache.org/bugzilla/show_bug.cgi?id=49117 --- Comment #15 from Arinjay arinjay...@gmail.com 2010-05-07 10:41:14 EDT --- (In reply to comment #14) (In reply to comment #13) Created an attachment (id=25341) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25341) [details] [details] test using antcall I'm afraid the antcall layer isn't enough to cause problems - the attached build file still works for me. Sorry for the delay! I will require your email id ...will not be possible to send you the build but will try to reproduce something similar. For the 1.8.0, I get this at the end...after I put a debug to the build: C:\work\subscriptions\cvssubscriptions\esc\source\java\build\build.xml:1709: Una ble to rename old file (C:\work\subscriptions\cvssubscriptions\esc\source\java\b uildpackage\buildtemp\eartemp\ICECommon-ejbs.jar) to temporary file at org.apache.tools.ant.taskdefs.Zip.renameFile(Zip.java:757) at org.apache.tools.ant.taskdefs.Zip.executeMain(Zip.java:636) at org.apache.tools.ant.taskdefs.Zip.execute(Zip.java:568) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68) at net.sf.antcontrib.logic.IfTask.execute(IfTask.java:217) at sun.reflect.GeneratedMethodAccessor71.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.TaskAdapter.execute(TaskAdapter.java:154) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1360) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(Single CheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1212) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105) at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68) at net.sf.antcontrib.logic.ForEach.executeSequential(ForEach.java:178) at net.sf.antcontrib.logic.ForEach.execute(ForEach.java:254) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.jav a:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1360) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(Single CheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1212) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441) at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor66.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at
DO NOT REPLY [Bug 49261] Copy task fails to overwrite readonly files even with overwrite=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=49261 Carl Quinn carl.qu...@gmail.com changed: What|Removed |Added CC||carl.qu...@gmail.com -- 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 49266] New: ant does not work with empty CLASSPATH
https://issues.apache.org/bugzilla/show_bug.cgi?id=49266 Summary: ant does not work with empty CLASSPATH Product: Ant Version: 1.8.0 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Wrapper scripts AssignedTo: notifications@ant.apache.org ReportedBy: sze...@ira.uka.de Have a look at the output of ant commands taken from the ant manual's Check Installation section and the ant website's Having Problems? page when they are executed with an empty CLASSPATH variable (which is even suggested by the Having Problems? page!): $ unset CLASSPATH $ ant The -cp argument must be followed by a classpath expression $ ant -version Buildfile: build.xml does not exist! Build failed $ ant -diagnostics Buildfile: build.xml does not exist! Build failed $ ant -verbose Buildfile: build.xml does not exist! Build failed This is obviously not good; ant does not even print its version. The problem is at the end of the bin/ant startup script, where the ant_exec_command variable is assembled. The -cp $CLASSPATH options are appended to the command line even when the CLASSPATH is empty, resulting in a command line which looks like 'exec java ... -cp '. Java then sees the -cp option without a class path or jar file and errors out, or it sees something like ... -cp -version and treats that first argument as a class path or jar file. The attached patch resolves this issue by checking CLASSPATH's emptyness and omiting the -cp option in that case. -- 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 49266] ant does not work with empty CLASSPATH
https://issues.apache.org/bugzilla/show_bug.cgi?id=49266 --- Comment #1 from sze...@ira.uka.de 2010-05-07 15:48:48 EDT --- Created an attachment (id=25417) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25417) Bugfix -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
svn commit: r942195 [3/3] - in /ant/ivy/core/trunk: ./ doc/ doc/ivyfile/ doc/use/ src/java/org/apache/ivy/ant/ src/java/org/apache/ivy/core/deliver/ src/java/org/apache/ivy/core/module/descriptor/ src
Added: ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-all.xml URL: http://svn.apache.org/viewvc/ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-all.xml?rev=942195view=auto == --- ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-all.xml (added) +++ ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-all.xml Fri May 7 20:00:48 2010 @@ -0,0 +1,32 @@ +!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + License); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +-- +ivy-module version=1.0 + info organisation=myorg + module=mymodule + status=integration + publication=2009120600 + extends organisation=myorg module=myparent revision=latest.revision location=test-extends-parent.xml/ + /info + configurations + conf name=conf2 visibility=private/ + /configurations + dependencies + dependency name=mymodule2 rev=2.0 conf=conf1,conf2/ + /dependencies +/ivy-module Propchange: ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-all.xml -- svn:mime-type = text/plain Added: ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-cached.xml URL: http://svn.apache.org/viewvc/ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-cached.xml?rev=942195view=auto == --- ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-cached.xml (added) +++ ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-cached.xml Fri May 7 20:00:48 2010 @@ -0,0 +1,32 @@ +!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + License); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. +-- +ivy-module version=1.0 + info organisation=myorg + module=mymodule + status=integration + publication=2009120600 + extends organisation=myorg module=myparent revision=latest.revision/ + /info + configurations + conf name=conf2 visibility=private/ + /configurations + dependencies + dependency name=mymodule2 rev=2.0 conf=conf1,conf2/ + /dependencies +/ivy-module Propchange: ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-cached.xml -- svn:mime-type = text/plain Added: ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-configurations.xml URL: http://svn.apache.org/viewvc/ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-configurations.xml?rev=942195view=auto == --- ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-configurations.xml (added) +++ ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-configurations.xml Fri May 7 20:00:48 2010 @@ -0,0 +1,33 @@ +!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file
svn commit: r942195 [1/3] - in /ant/ivy/core/trunk: ./ doc/ doc/ivyfile/ doc/use/ src/java/org/apache/ivy/ant/ src/java/org/apache/ivy/core/deliver/ src/java/org/apache/ivy/core/module/descriptor/ src
Author: maartenc Date: Fri May 7 20:00:48 2010 New Revision: 942195 URL: http://svn.apache.org/viewvc?rev=942195view=rev Log: NEW: Support ivy.xml parent mechanism (IVY-742) (thanks to Jason Trump and Jean-Louis Boudart) Added: ant/ivy/core/trunk/doc/ivyfile/extends.html (with props) ant/ivy/core/trunk/src/java/org/apache/ivy/core/module/descriptor/DefaultExtendsDescriptor.java (with props) ant/ivy/core/trunk/src/java/org/apache/ivy/core/module/descriptor/ExtendsDescriptor.java (with props) ant/ivy/core/trunk/src/java/org/apache/ivy/core/module/descriptor/InheritableItem.java (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/ant/ivy-extends-merged.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/ant/ivy-extends-minimal-merged.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/ant/ivy-extends-minimal.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/ant/ivy-extends-multiconf.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-all.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-cached.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-configurations.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-dependencies.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-description-override.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-description.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-mixed.xml (with props) ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/test-extends-parent.xml (with props) Modified: ant/ivy/core/trunk/CHANGES.txt ant/ivy/core/trunk/doc/ivyfile/info.html ant/ivy/core/trunk/doc/toc.json ant/ivy/core/trunk/doc/use/deliver.html ant/ivy/core/trunk/doc/use/publish.html ant/ivy/core/trunk/src/java/org/apache/ivy/ant/IvyDeliver.java ant/ivy/core/trunk/src/java/org/apache/ivy/ant/IvyPublish.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/deliver/DeliverEngine.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/deliver/DeliverOptions.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/module/descriptor/Configuration.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/module/descriptor/DefaultDependencyDescriptor.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/module/descriptor/DefaultModuleDescriptor.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/module/descriptor/DependencyDescriptor.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/module/descriptor/ModuleDescriptor.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/publish/PublishEngine.java ant/ivy/core/trunk/src/java/org/apache/ivy/core/publish/PublishOptions.java ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/xml/UpdateOptions.java ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/xml/XmlModuleDescriptorParser.java ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/xml/XmlModuleDescriptorUpdater.java ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/xml/XmlModuleDescriptorWriter.java ant/ivy/core/trunk/src/java/org/apache/ivy/plugins/parser/xml/ivy.xsd ant/ivy/core/trunk/test/java/org/apache/ivy/ant/IvyDeliverTest.java ant/ivy/core/trunk/test/java/org/apache/ivy/ant/IvyPublishTest.java ant/ivy/core/trunk/test/java/org/apache/ivy/ant/ivy-multiconf.xml ant/ivy/core/trunk/test/java/org/apache/ivy/plugins/parser/xml/XmlModuleDescriptorParserTest.java Modified: ant/ivy/core/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=942195r1=942194r2=942195view=diff == --- ant/ivy/core/trunk/CHANGES.txt (original) +++ ant/ivy/core/trunk/CHANGES.txt Fri May 7 20:00:48 2010 @@ -24,6 +24,7 @@ for detailed view of each issue, please Jeffrey Blattman Jasper Blues Jim Bonanno + Jean-Louis Boudart Dave Brosius Matthieu Brouillard Carlton Brown @@ -111,6 +112,7 @@ for detailed view of each issue, please - DOCUMENTATION: ivy-doc.xsl does not show configurations (IVY-1151) (thanks to Jasper Blues) - DOCUMENTATION: Added documentation of the 'changing' attribute on the ivy:resolve Ant task (IVY-1180) +- NEW: Support ivy.xml parent mechanism (IVY-742) (thanks to Jason Trump and Jean-Louis Boudart) - NEW: Make ivy.xml conf description available (IVY-1158) - IMPROVEMENT: Support changing=true for inline retrieve (IVY-1180) Added: ant/ivy/core/trunk/doc/ivyfile/extends.html URL:
[jira] Resolved: (IVY-742) Support ivy.xml parent mechanism
[
https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-742.
---
Assignee: Maarten Coene
Fix Version/s: trunk
Resolution: Fixed
I've committed your patch. I've made 1 modification: the default of the merge
attribute is true instead of false.
Please give current version from trunk a try to check if it is still working.
Thanks a lot for the contribution!
Maarten
Support ivy.xml parent mechanism
Key: IVY-742
URL: https://issues.apache.org/jira/browse/IVY-742
Project: Ivy
Issue Type: New Feature
Components: Core
Environment: Any
Reporter: Neil Lott
Assignee: Maarten Coene
Fix For: trunk
Attachments: extendsIvyFile-ivy-r709181.patch,
extendsIvyFile-ivy-r920176.patch
Here's the email that details this feature:
On Thu, Feb 21, 2008 at 11:22 PM, Neil Lott neilmatthewl...@yahoo.com
wrote:
Let's say I have multiple modules each with their own ivy.xml
ivy-module version=2.0
info organisation=${organization.name} module=$
{interface.jar.prefix}/
configurations
conf name=interface description=dependencies for
interface/
include file=path/to/included-configurations.xml/
/configurations
publications
artifact name=${interface.jar.prefix} type=jar
conf=interface ext=jar/
/publications
dependencies
dependency org=twc name=mas-core rev=${mas.version}
conf=interface-server/
/dependencies
/ivy-module
and I want them all to share an inherited configuration found in a
file: included-configurations.xml
configuration
conf name=test/
/configuration
dependencies
dependency name=testng rev=5.7 conf=test/
/dependencies
so in the inherited configurations file I'd also like to include a
dependency that goes along with that configuration.
Is something like this possible?
No, this is not possible in Ivy, but you can use text or xml processing
tools to recompose your Ivy file before asking Ivy to resolve the
dependencies of your module.
Alternatively, since what you ask is close to maven 2 parent mechanism, I
think it could be a nice addition to Ivy feature set. So feel free to open
an issue, and even provide a patch :-)
Xavier
Thanks,
Neil
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-981) caches requires defaultCacheDir to be set
[
https://issues.apache.org/jira/browse/IVY-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-981:
--
Fix Version/s: 2.2.0-RC1
(was: trunk)
caches requires defaultCacheDir to be set
---
Key: IVY-981
URL: https://issues.apache.org/jira/browse/IVY-981
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0-RC2
Reporter: Jesper Pedersen
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
I have deployed ivy.jar in $ANT_HOME/lib - and have the following in my
build.xml
target name=init
ivy:settings file=${basedir}/ivy.settings.xml/
/target
in my ivy.settings.xml file I have
caches defaultCacheDir=${user.home}/.ivy2/cache
artifactPattern=[organisation]/[module]/[type]s/[artifact]-[revision](-[classifier]).[ext]
checkUpToDate=true/
If I remove the defaultCacheDir attribute it conplains about ${ivy.cache.dir}
isn't set.
The documentation lists defaultCacheDir as a non-required attribute for
caches
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-956) Latest Compatible Conflict Manager + Extra Attributes in Dependencies' IVY files == inifinite loop
[
https://issues.apache.org/jira/browse/IVY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-956:
--
Fix Version/s: 2.2.0-RC1
(was: trunk)
Latest Compatible Conflict Manager + Extra Attributes in Dependencies' IVY
files == inifinite loop
--
Key: IVY-956
URL: https://issues.apache.org/jira/browse/IVY-956
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0-RC1
Environment: Windows XP
Java 6
Reporter: Scott Hebert
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: extra-att-multipledependencies.zip
When using the Latest Compatible Conflict Manager with the resolution of
modules/revisions that contain extra attributes, you get into an infinite
loop.
The dependencies on my repository contains this in their info/ element:
{code:xml}
info organisation=CAE-VSK module=VSK-FC revision=0.54.0.0
status=Development publication=20081016173017 buddies=
approver=Somebody
{code}
If the ivy.xml that I would like to resolve contains this:
{code:xml}
dependencies
dependency org=CAE-VSK name=VSK-FC rev=0.53.0.1 transitive=false
force=true conf=BuildTimeDependencies-gt;* policydependency=true
/dependency
dependency org=CAE-VSK name=VSK-FC rev=[0.50.0.0,0.55.0.0]
transitive=false force=true conf=BuildTimeDependencies-gt;*
/dependency
/dependencies
{code}
then the ResolveEngine gets into an infinite loop with this being displayed
over and over again:
{noformat}
[ivy:resolve] found CAE-VSK#VSK-FC#MAIN;0.54.1.0 in attribs
[ivy:resolve] [0.54.1.0] CAE-VSK#VSK-FC#MAIN;[0.50.0.0,0.55.0.0]
[ivy:resolve] BLACKLISTING [CAE-VSK#VSK-FC#MAIN;0.54.1.0 blacklisted to evict
CAE-VSK#VSK-FC#MAIN;0.54.1.0 in favor of CAE-VSK#VSK-FC#MAIN;0.53.0.1 in
CAE#TESTA#MAIN;work...@pc6346 for BuildTimeDependencies]
{noformat}
I'm going to attach 2 tests -- one that operates on a repository that
contains revs with NO attribs and one that operates on a repository that
contains revs WITH attribs.
Thanks,
Scott
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-968) FileSystem resolver with m2compatible=true throws error when publishing modules with dotted organisation names
[
https://issues.apache.org/jira/browse/IVY-968?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-968:
--
Fix Version/s: 2.2.0-RC1
(was: trunk)
FileSystem resolver with m2compatible=true throws error when publishing
modules with dotted organisation names
--
Key: IVY-968
URL: https://issues.apache.org/jira/browse/IVY-968
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0-RC2, 2.1.0
Environment: Windows XP, JDK 1.6
Reporter: Michael Kebe
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: ivy-968-test_r885277.patch
When you try to publish an artifact with a . (dot) in its organisationname
to a maven2 compatible file system resolver you get:
\\
\\
{code:title=Ant Output}install-local:
:: delivering :: org.test#testlib;work...@kebap :: 0.0-dev-20081114110649 ::
integration :: Fri Nov 14 11:06:53 CET 2008
delivering ivy file to D:\workspace\testlib\dist\ivys\ivy.xml
:: publishing :: org.test#testlib
published testlib to C:\Dokumente und
Einstellungen\kebe\.ivy2/local/org/test/testlib/0.0-dev-20081114110649.part/testlib-0.0-dev-20081114110649.jar
published ivy to C:\Dokumente und
Einstellungen\kebe\.ivy2/local/org/test/testlib/0.0-dev-20081114110649.part/ivy.xml
BUILD FAILED
Xx-common.ant:459: impossible to publish artifacts for
org.test#testlib;work...@kebap: java.lang.IllegalStateException: no current
transaction!{code}
Here is the settings snippet:
{code:title=From ivysettings.xml}
filesystem name=local m2compatible=true
ivy
pattern=${repository.local.path}/[organisation]/[module]/[revision]/ivy.xml
/
artifact
pattern=${repository.local.path}/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]
/
/filesystem
{code}
Publishing with organisation without a . works. If you set transactional of
the filesystem resolver to false it works, too.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1118) IvyNodeEviction.cleanEvicted has bad comparison logic
[
https://issues.apache.org/jira/browse/IVY-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1118:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
IvyNodeEviction.cleanEvicted has bad comparison logic
-
Key: IVY-1118
URL: https://issues.apache.org/jira/browse/IVY-1118
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0-RC2
Reporter: Dave Brosius
Assignee: Maarten Coene
Priority: Minor
Fix For: 2.2.0-RC1
clean evicted compares an IvyNode to an IvyNodeEviction which will always be
false
private void cleanEvicted() {
// check if it was evicted by a node that we are now the real node for
for (Iterator iter = evicted.keySet().iterator(); iter.hasNext();) {
String rootModuleConf = (String) iter.next();
EvictionData ed = (EvictionData) evicted.get(rootModuleConf);
Collection sel = ed.getSelected();
if (sel != null) {
for (Iterator iterator = sel.iterator(); iterator.hasNext();)
{
IvyNode n = (IvyNode) iterator.next();
if (n.getRealNode().equals(this)) {
// yes, we are the real node for a selected one !
// we are no more evicted in this conf !
iter.remove();
}
}
}
}
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1152) Ivy does not close URL connection to ivy-report.xsl properly
[ https://issues.apache.org/jira/browse/IVY-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1152: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Ivy does not close URL connection to ivy-report.xsl properly Key: IVY-1152 URL: https://issues.apache.org/jira/browse/IVY-1152 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0, 2.1.0 Reporter: Pavel Sher Assignee: Maarten Coene Fix For: 2.2.0-RC1 It seems BasicURLHanlder.disconnect() does not properly close URL connection to ivy-report.xsl file. In my case URL looks like: jar:file:/path/ivy-2.0.jar!/org/apache/ivy/plugins/report/ivy-report.xsl In disconnect() method there is a check for URL connection class: sun.net.www.protocol.file.FileURLConnection.equals(con.getClass().getName()) However in runtime this check does not work because instead of FileURLConnection there is JarURLConnection: sun.net.www.protocol.jar.JarURLConnection This leads to leaked input streams if Ivy is used programmatically within the same JVM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1147) Use of a shared DocumentBuilder causes SAXException during parallel resolutions
[ https://issues.apache.org/jira/browse/IVY-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1147: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Use of a shared DocumentBuilder causes SAXException during parallel resolutions --- Key: IVY-1147 URL: https://issues.apache.org/jira/browse/IVY-1147 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0 Environment: Vista 32bit Sun JDK 1.6.0_17 Reporter: Brian Atkinson Assignee: Maarten Coene Fix For: 2.2.0-RC1 I am in need of running multiple instances of ivy in parallel from within the same jvm. When I do this I am seeing the following exception: org.xml.sax.SAXException: FWK005 parse may not be called while parsing. at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:253) at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:283) at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:153) at org.apache.ivy.util.XMLHelper.parseToDom(XMLHelper.java:198) at org.apache.ivy.plugins.parser.m2.PomReader.init(PomReader.java:94) at org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:115) at org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:105) at org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:638) at org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68) at org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:655) at org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:942) at org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:542) at org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:263) at org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:501) at org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:130) at org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:130) at org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:170) at org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:274) at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:671) at org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:757) at org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:679) at org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:551) at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:235) at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:193) at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:138) at org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:134) at org.apache.ivy.Ivy.resolve(Ivy.java:473) It seems that the DocumentBuilder created in org.apache.ivy.util.XMLHelper.getDocBuilder(EntityResolver) is stored in a static variable and only initialized once. Would it be possible to cache the DocumentBuilderFactory rather then the DocumentBuilder? Doing this would allow for parallel XML parsing. Additionally the entity resolver provided on the first call is the only one used for the lifetime of the DocumentBuilder. I don't know if this was intended, but the method signature does not seem to suggest it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1135) still use defaultconf when defaultconfmapping is defined
[ https://issues.apache.org/jira/browse/IVY-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1135: --- Fix Version/s: 2.2.0-RC1 (was: trunk) still use defaultconf when defaultconfmapping is defined Key: IVY-1135 URL: https://issues.apache.org/jira/browse/IVY-1135 Project: Ivy Issue Type: Improvement Affects Versions: 2.1.0 Reporter: Stephen Haberman Assignee: Maarten Coene Fix For: 2.2.0-RC1 Attachments: ivy-1135-doc.patch, ivy-1135.patch Per this forum post: http://www.nabble.com/defaultconf-and-defaultconfmapping-td25582330.html#a25582330 I think it would be possible (and more intuitive) if defaultconf and defaultconfmapping could be used at the same time. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1106) URLResource does not properly support authentication
[ https://issues.apache.org/jira/browse/IVY-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1106: --- Fix Version/s: 2.2.0-RC1 (was: trunk) URLResource does not properly support authentication Key: IVY-1106 URL: https://issues.apache.org/jira/browse/IVY-1106 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0-RC2 Reporter: Heschi Kreinick Assignee: Maarten Coene Fix For: 2.2.0-RC1 org.apache.ivy.plugins.repository.url.UrlResource#openStream uses java.net.URL#openStream rather than going through the URLHandlerRegistry like init does. This breaks authentication support. I encountered this bug when using a version range specification (1.+) against a secured Maven repository, but I imagine that it can cause any number of other problems. The fix is simply to change openStream to work the same way init does, by replacing return url.openStream(); with return URLHandlerRegistry.getDefault().openStream(url); This change passes all tests and solves my problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1150) Artifact report NPE when artifact is not in cache
[ https://issues.apache.org/jira/browse/IVY-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1150: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Artifact report NPE when artifact is not in cache - Key: IVY-1150 URL: https://issues.apache.org/jira/browse/IVY-1150 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 2.1.0 Environment: Fedora 12, Sun JDK 1.6.0 u16, Ant 1.7.0 Reporter: Steve Jones Assignee: Maarten Coene Fix For: 2.2.0-RC1 Attachments: ivy_2_1_0_artifactReport.patch When an artifact report is generated after using resolve and publish with the option haltonfailure=false an NPE will occur if an artifact is not in the cache: java.lang.NullPointerException at org.apache.ivy.ant.IvyArtifactReport.writeCacheLocation(IvyArtifactReport.java:251) at org.apache.ivy.ant.IvyArtifactReport.generateXml(IvyArtifactReport.java:158) at org.apache.ivy.ant.IvyArtifactReport.doExecute(IvyArtifactReport.java:117) at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1157) buildnumber does not work when there is a dependency referenced by the same ivy file.
[
https://issues.apache.org/jira/browse/IVY-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1157:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
buildnumber does not work when there is a dependency referenced by the same
ivy file.
-
Key: IVY-1157
URL: https://issues.apache.org/jira/browse/IVY-1157
Project: Ivy
Issue Type: Bug
Components: Ant
Affects Versions: 2.1.0
Environment: MacOSX, IVY 2.1.0
Reporter: Dan Diodati
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
I ran into a case where I resolve one ivy file that references a artifact
called tools. Then later I try to get a new build number of the tools
artifact and it acts as if it does not exist and starts at 1.
This seems to occur because in the IvyBuildNumber it uses a ModuleId object
which does some caching of the module information and then does object
comparisions in the getMatcher method.
In my case the String object ends up changing and so it thinks there is not
an existing artifact giving me the 1.0 version instead of the correct one.
I have some test build to simulate the problem and would attach it if I
could. You can ping me and I can send it to you.
Note the second output will be: [echo] tool current revision is:
work...@sfdanmac.local; new revision is: 1.0
Since there is a tools artifact with 1.1.0 it should return a result of 1.2
and not 1.0.
I found the fix was to modify the IvyBuildNumber to do String comparisons
using the equals operator instead of the ==. Here is the diff that fixes the
issue:
{noformat}
Index: src/java/org/apache/ivy/ant/IvyBuildNumber.java
===
--- src/java/org/apache/ivy/ant/IvyBuildNumber.java (revision 888715)
+++ src/java/org/apache/ivy/ant/IvyBuildNumber.java (working copy)
@@ -165,9 +165,9 @@
private PatternMatcher regexp = new
ExactOrRegexpPatternMatcher();
public Matcher getMatcher(String expression) {
-if ((expression == organisation)
-|| (expression == module)
-|| (expression == branch)) {
+if ((expression.equals(organisation))
+|| (expression.equals(module))
+|| (expression.equals(branch))) {
return exact.getMatcher(expression);
}
return regexp.getMatcher(expression);
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-742) Support ivy.xml parent mechanism
[
https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-742:
--
Fix Version/s: 2.2.0-RC1
(was: trunk)
Support ivy.xml parent mechanism
Key: IVY-742
URL: https://issues.apache.org/jira/browse/IVY-742
Project: Ivy
Issue Type: New Feature
Components: Core
Environment: Any
Reporter: Neil Lott
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: extendsIvyFile-ivy-r709181.patch,
extendsIvyFile-ivy-r920176.patch
Here's the email that details this feature:
On Thu, Feb 21, 2008 at 11:22 PM, Neil Lott neilmatthewl...@yahoo.com
wrote:
Let's say I have multiple modules each with their own ivy.xml
ivy-module version=2.0
info organisation=${organization.name} module=$
{interface.jar.prefix}/
configurations
conf name=interface description=dependencies for
interface/
include file=path/to/included-configurations.xml/
/configurations
publications
artifact name=${interface.jar.prefix} type=jar
conf=interface ext=jar/
/publications
dependencies
dependency org=twc name=mas-core rev=${mas.version}
conf=interface-server/
/dependencies
/ivy-module
and I want them all to share an inherited configuration found in a
file: included-configurations.xml
configuration
conf name=test/
/configuration
dependencies
dependency name=testng rev=5.7 conf=test/
/dependencies
so in the inherited configurations file I'd also like to include a
dependency that goes along with that configuration.
Is something like this possible?
No, this is not possible in Ivy, but you can use text or xml processing
tools to recompose your Ivy file before asking Ivy to resolve the
dependencies of your module.
Alternatively, since what you ask is close to maven 2 parent mechanism, I
think it could be a nice addition to Ivy feature set. So feel free to open
an issue, and even provide a patch :-)
Xavier
Thanks,
Neil
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1131) override ignored in dynamic resolve mode
[ https://issues.apache.org/jira/browse/IVY-1131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1131: --- Fix Version/s: 2.2.0-RC1 (was: trunk) override ignored in dynamic resolve mode -- Key: IVY-1131 URL: https://issues.apache.org/jira/browse/IVY-1131 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0-RC2 Reporter: Jacob Aleksynas Assignee: Maarten Coene Fix For: 2.2.0-RC1 Switched ivysettings to resolveMode=dynamic existing override dependencies were not respected. Switching the setting back resolved correct revisions. Perhaps this just needs a documentation update, do overrides need revConstraint to properly resolve dynamically or something? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1167) Using SFTP resolver with full pattern URL prevents use of dynamic versions
[
https://issues.apache.org/jira/browse/IVY-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1167:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Using SFTP resolver with full pattern URL prevents use of dynamic versions
--
Key: IVY-1167
URL: https://issues.apache.org/jira/browse/IVY-1167
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0
Environment: Jsch 0.1.31 and 0.1.42.
JDK 1.6+
ant 1.8RC1
Linux Gentoo
Reporter: Gregory Fernandez
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: sftp.patch
Hello !
I'm using a sftp repository. Let's say there is a module called foo, revsions
1.2.3 and 1.2.4 are present.
I add : dependency org=org.my name=foo rev=1.2.*+*/
Resolve is unsucessful if I declare my repository as an full URL :
{code:xml}
resolvers
sftp name=public user=rep.user userPassword=rep.password
ivy
pattern=sftp://rep.host/home/ivy/repository/[organisation]/[module]/[revision]/ivys/ivy.xml/
artifact
pattern=sftp://rep.host/home/ivy/repository/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]/
/sftp
/resolvers
{code}
But everything works if I declare my repository using attributes :
{code:xml}
resolvers
sftp name=public host=rep.host user=rep.user
userPassword=rep.password
ivy
pattern=/home/ivy/repository/[organisation]/[module]/[revision]/ivys/ivy.xml/
artifact
pattern=/home/ivy/repository/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]/
/sftp
/resolvers
{code}
In fact, the list method use the pattern as a path, and don't remove the
*sftp://host* .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1179) Packager resolver always extracts all files from archives even when the packaging instructions contains include tags
[
https://issues.apache.org/jira/browse/IVY-1179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1179:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Packager resolver always extracts all files from archives even when the
packaging instructions contains include tags
Key: IVY-1179
URL: https://issues.apache.org/jira/browse/IVY-1179
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0, trunk
Reporter: Stefan De Boey
Assignee: Maarten Coene
Priority: Minor
Fix For: 2.2.0-RC1
Attachments: IVY-1179-unittests.zip, IVY-1179-unittests.zip,
IVY-1179.patch, IVY-1179.patch
According to the documentation the packager resolver should unzip/untar only
specific files and folders (and not the complete archive) from downloaded
resources in case the packager module description specfies include tags.
Let's assume we have a module testng (example is taken from the examples in
the Packager Resolver documentation) and we have a packager module descriptor
(the packaging instructions) packager.xml specifying the following resource:
{code:xml}
resource dest=archive url=http://testng.org/${zipname}.zip;
sha1=2ea19275dc17453306f8bb780fe6ef6e9af7756b
include name=${zipname}/*.jar/
/resource
{code}
this instructs the package resolver to download the resources from
http://testng.org/... and then extract the archive, but only all JAR files in
the root of the archive.
in this case only the JAR's in the ZIP file should be extracted from the
resource, but that's not the case. at first i didn't notice this, but i was
creating the packaging instructions for a project which is in a huge ZIP file
and so i only wanted to extract the files that i actually needed, but i
noticed that the extraction took way to long.
i then configured the packager resolver to preserve the build directories
(where the archive is extracted) for debugging purposes and i noticed that
the complete archive was still extracted although the packager.xml file
contained the necessary 'include' tags to only inluce 3 JAR's.
when using the preserveBuildDirectories switch on the packager resolver, it's
also possible to view the ANT build file packager-output.xml (this one is
generated by the packager resolver based on the packaging instructions). this
build file is executed by the package resolver to do the extraction process.
this is the relevant part of the packager-output.xml file for the above
mentioded example for TestNG:
{code:xml}
unzip src=${resdir.N65541}${file.separator}${filename.N65541}
dest=archive
fileset dir=.
include name=testng-2.5/*.jar/
/fileset
/unzip
{code}
but this is incorrect and that's why the complete zip is still extracted. the
'fileset' tag should be used to indicate a set of ZIP files that need to be
extracted, not to indicate which resources from the archive (specified in the
'src' attribute of the unzip tag) need to be included when extracting.
'patternset' is what we need here instead of 'fileset'
the actual problem is situated in the file
src/java/org/apache/ivy/plugins/resolver/packager/packager.xsl on line 420
(in the ivy core project).
{code:xml}
xsl:when test=$type = 'zip' or $type = 'war' or $type = 'jar'
unzip src={$file} dest={$dir}
xsl:if test=$includes
fileset dir=.
xsl:copy-of select=$includes/
/fileset
/xsl:if
/unzip
/xsl:when
{code}
should be:
{code:xml}
xsl:when test=$type = 'zip' or $type = 'war' or $type = 'jar'
unzip src={$file} dest={$dir}
xsl:if test=$includes
patternset
xsl:copy-of select=$includes/
/patternset
/xsl:if
/unzip
/xsl:when
{code}
the same needs to be done for the TAR part in the packages.xsl file.
i already tried this fix and it works.
if that's OK, i'll create a patch for this and provide the necessary unit
tests to illustrate the problem and the fix.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1178) Transitive dependencies resolutions issue when eviction is triggered
[ https://issues.apache.org/jira/browse/IVY-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1178: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Transitive dependencies resolutions issue when eviction is triggered Key: IVY-1178 URL: https://issues.apache.org/jira/browse/IVY-1178 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0 Environment: Linux / ant 1.7.0 Reporter: david herviou Assignee: Maarten Coene Fix For: 2.2.0-RC1 Attachments: jira-ivy-1178.zip Originally described in ivy-user list : http://old.nabble.com/Transitive-resolving-issue---td27984462.html Here just a part of the discussion that explain the problem and the temporary work around : Consider the following use case : moduleA has one of its dependencies like this : dependency org=log4j name=log4j rev=1.2.14 transitive=false/ moduleB has one of its dependencies like this : dependency org=log4j name=log4j rev=1.2.15 transitive=false/ While moduleC use moduleA and moduleB I have something like this : dependency org=moduleA.org name=moduleA rev=moduleA.rev/ dependency org=moduleB.org name=moduleB rev=moduleB.rev/ This seems to be very banal BUT, when running the ivy:resolve task the log4j-1.2.15 evicts the log4j-1.2.14 which seems to be a good thing! but thereafter the resolve task does not consider the transitivity has false and try to resolve all the dependencies of log4j-1.2.15 If I remove moduleA.org and use only moduleB.org then the resolve task behave correctly (I mean there is no resolution of transitives dependencies). The reverse case is also true. A work-around is available by resolving conflict explicitly with something like : conflict org=moduleA.org module=moduleA rev=moduleA.rev/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1181) Fix broken links on ivy links page
[ https://issues.apache.org/jira/browse/IVY-1181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1181: --- Fix Version/s: (was: trunk) 2.2.0-RC1 Fix broken links on ivy links page -- Key: IVY-1181 URL: https://issues.apache.org/jira/browse/IVY-1181 Project: Ivy Issue Type: Bug Components: Documentation Affects Versions: 2.1.0 Reporter: Archie Cobbs Assignee: Maarten Coene Fix For: 2.2.0-RC1 Two changes for this page: http://ant.apache.org/ivy/links.html # The link to IvyRep should be removed, this repository no longer exists # Replace it with a link to [Ivy RoundUp|http://ivyroundup.googlecode.com/] which does exist and is actually used by a bunch of people -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1171) Cannot publish wildcard configurations other than *
[ https://issues.apache.org/jira/browse/IVY-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1171: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Cannot publish wildcard configurations other than * --- Key: IVY-1171 URL: https://issues.apache.org/jira/browse/IVY-1171 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0 Reporter: Matt Benson Assignee: Matt Benson Fix For: 2.2.0-RC1 PublishEngine.publish(ModuleDescriptor, Collection, DependencyResolver, PublishOptions) should replace conf wildcards rather than just processing * explicitly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1079) Resolve with Extra Attributes, Forced Dependencies causes invalid delivered ivy file
[
https://issues.apache.org/jira/browse/IVY-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1079:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Resolve with Extra Attributes, Forced Dependencies causes invalid delivered
ivy file
Key: IVY-1079
URL: https://issues.apache.org/jira/browse/IVY-1079
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0-RC1
Reporter: Scott Hebert
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: DeliverWithExtraAttribs.zip
I had the following situation:
#A;working- { #B;[1.0] #C;[2.0,2.5] }
#B;1.0-#C;2.1
#B and #C have extra attributes in the info/ section.
All dependencies/ use the force attribute.
When I resolve and deliver A using the latest-compatible conflict manager, I
expect to see #C;2.1 in my deliver IVY file. However, I am seeing #C;[2.0,2.5]
Attached are 2 tests. One which uses a file repository with ivy files for #B
and #C with no extra attributes. One which does not.
Thanks,
Scott
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1123) Change spelling of 'occured' to 'occurred'
[
https://issues.apache.org/jira/browse/IVY-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1123:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Change spelling of 'occured' to 'occurred'
--
Key: IVY-1123
URL: https://issues.apache.org/jira/browse/IVY-1123
Project: Ivy
Issue Type: Bug
Components: Ant, Core, Documentation
Reporter: Brian Egge
Assignee: Maarten Coene
Priority: Trivial
Fix For: 2.2.0-RC1
The following files contain this spelling mistake:
find . -path '*/.svn' -prune -o -type f | xargs grep occured
./doc/samples/apache-hello-ivy-default.html:0 errors img
src=http://ivy.jayasoft.org/images/error.gif; alt=error title=module
revisions on which error occured)/td
./doc/samples/jayasoft-ivyrep-example-default.html:0 errors img
title=module revisions on which error occured alt=error
src=../images/error.gif)/td
./doc/xooki/xooki.js: xooki.error(e, t(error
occured while processing filter ${0}, filters[i]));
./doc/xooki/xooki.js: xooki.debug(error occured while
loading +url);
./src/example/multi-project/projects/version/src/version/Version.java:
System.err.println(an error occured while registering + module + :
./src/java/org/apache/ivy/core/cache/RepositoryCacheManager.java: *
if an exception occured while parsing the module descriptor
./src/java/org/apache/ivy/core/resolve/ResolveEngine.java: *
if a parsing problem occured in the ivy file
./src/java/org/apache/ivy/core/resolve/ResolveEngine.java: *
level. It may be empty if no conflict resolution has occured for this node
yet, or
./src/java/org/apache/ivy/plugins/parser/xml/XmlModuleDescriptorParser.java:
ParseException ex = new ParseException(exception occured while
parsing + res, 0);
./src/java/org/apache/ivy/plugins/parser/xml/XmlModuleDescriptorParser.java:
SAXException sax = new SAXException(Problem occured while
parsing ivy file:
./src/java/org/apache/ivy/plugins/parser/xml/XmlModuleDescriptorUpdater.java:
Message.warn(exception occured while importing
configurations:
./src/java/org/apache/ivy/plugins/report/ivy-report.xsl:
xsl:value-of select=count($errors)/ errors img
src=http://ant.apache.org/ivy/images/error.gif; alt=error title=module
revisions on which error occured/)/td/tr
./src/java/org/apache/ivy/plugins/repository/TransferEvent.java: * An
error occured during transfer
./src/java/org/apache/ivy/plugins/resolver/ChainResolver.java:
Message.verbose(problem occured while resolving + dd + with + resolver
./src/java/org/apache/ivy/plugins/resolver/ChainResolver.java:
throw new RuntimeException(several problems occured while resolving + dd +
:\n
./src/java/org/apache/ivy/util/CredentialsUtil.java:
Message.warn(error occured while saving password file + passfile + : +
e);
./src/java/org/apache/ivy/util/CredentialsUtil.java:
Message.warn(error occured while loading password file + passfile + : +
e);
./src/java/org/apache/ivy/util/PropertiesFile.java:
Message.warn(exception occured while reading properties file + file + :
./src/java/org/apache/ivy/util/PropertiesFile.java:
Message.warn(exception occured while writing properties file + file + :
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1109) Change org.apache to commons-cli at jdbc-example
[ https://issues.apache.org/jira/browse/IVY-1109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1109: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Change org.apache to commons-cli at jdbc-example Key: IVY-1109 URL: https://issues.apache.org/jira/browse/IVY-1109 Project: Ivy Issue Type: Bug Components: Documentation Affects Versions: 2.1.0-RC2 Reporter: Claudio Miranda Assignee: Maarten Coene Priority: Trivial Fix For: 2.2.0-RC1 The current example at /src/example/configurations/jdbc-example cannot find the org.apache#commons-cli;1.0!commons-cli.jar Changing it will make it work From dependency org=org.apache name=commons-cli rev=1.0 / To dependency org=commons-cli name=commons-cli rev=1.0 / The error message [ivy:retrieve] [ivy:retrieve] :: problems summary :: [ivy:retrieve] WARNINGS [ivy:retrieve] module not found: org.apache#commons-cli;1.0 [ivy:retrieve] local: tried [ivy:retrieve] /home/claudio/.ivy2/local/org.apache/commons-cli/1.0/ivys/ivy.xml [ivy:retrieve]-- artifact org.apache#commons-cli;1.0!commons-cli.jar: [ivy:retrieve] /home/claudio/.ivy2/local/org.apache/commons-cli/1.0/jars/commons-cli.jar [ivy:retrieve] shared: tried [ivy:retrieve] /home/claudio/.ivy2/shared/org.apache/commons-cli/1.0/ivys/ivy.xml [ivy:retrieve]-- artifact org.apache#commons-cli;1.0!commons-cli.jar: [ivy:retrieve] /home/claudio/.ivy2/shared/org.apache/commons-cli/1.0/jars/commons-cli.jar [ivy:retrieve] public: tried [ivy:retrieve] http://repo1.maven.org/maven2/org/apache/commons-cli/1.0/commons-cli-1.0.pom [ivy:retrieve]-- artifact org.apache#commons-cli;1.0!commons-cli.jar: [ivy:retrieve] http://repo1.maven.org/maven2/org/apache/commons-cli/1.0/commons-cli-1.0.jar [ivy:retrieve] :: [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: [ivy:retrieve] :: [ivy:retrieve] :: org.apache#commons-cli;1.0: not found [ivy:retrieve] :: [ivy:retrieve] [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS BUILD FAILED /opt/lib/apache-ivy-2.1.0-rc2/src/example/configurations/jdbc-example/build.xml:43: impossible to resolve dependencies: resolve failed - see output for details -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1144) revisions are not replaces using deliver-task if an extra-attribute is set
[
https://issues.apache.org/jira/browse/IVY-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1144:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
revisions are not replaces using deliver-task if an extra-attribute is set
--
Key: IVY-1144
URL: https://issues.apache.org/jira/browse/IVY-1144
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0
Reporter: Daniel Schwager
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
I'm using extra attributes in my ivy-file dtn:envelop. If i try to deliver,
the revision latest.${ivy.status} is not replaced to the resolvedretrieved
revision number:
?xml-stylesheet type=text/xsl
href=http://www.jayasoft.fr/org/ivyrep/ivy-doc.xsl;?
ivy-module version=2.0 xmlns:dtn=http://dtnet.de/ivy/extra;
...
dependency org=dtnet name=foundation
rev=latest.${ivy.status}
dtn:envelop= revConstraint=latest.integration
conf=
runtime, eclipse, compile -
dtnet-startup, dtnet-exec, dtnet-net ;
tools - dtnet-prop2class;
source ;
license/
If i remove the extra attribute
dependency org=dtnet name=foundation
rev=latest.${ivy.status}
revConstraint=latest.integration
conf=
runtime, eclipse, compile -
dtnet-startup, dtnet-exec, dtnet-net ;
.
all works fine an my new, generated ivy.xml includes the replace revisions:
dependency org=dtnet name=foundation rev=2.7.3 ...
My deliver task looks like this:
ivy:deliver
pubrevision=${gen.new.revision}
generateRevConstraint=true
replacedynamicrev=true
pubdate=${now}
status=${ivy.status}
validate=true
deliverpattern=${artifacts.dir}/[artifact].[ext] /
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1163) add ability to programmatically change default resolver
[ https://issues.apache.org/jira/browse/IVY-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1163: --- Fix Version/s: 2.2.0-RC1 (was: trunk) add ability to programmatically change default resolver --- Key: IVY-1163 URL: https://issues.apache.org/jira/browse/IVY-1163 Project: Ivy Issue Type: Improvement Components: Core Affects Versions: 2.1.0 Reporter: Jason Trump Assignee: Maarten Coene Priority: Minor Fix For: 2.2.0-RC1 Attachments: ivy-1163-r902503.patch I would like the ability to change the default resolver programmatically. For example, from an Ant task. The API exists for this (IvySettings.setDefaultResolver), but it does not work reliably. The fix looks pretty easy. When you call IvySettings.setDefaultResolver, it changes the value of defaultResolverName, of type String. However, it doesn't change the cache variable defaultResolver. So if you've called IvySettings.getDefaultResolver once, it will always return the original value, even if you later try to change it with setDefaultResolver. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1142) ivy:retrieve sync=true does nothing if first variable is optional
[
https://issues.apache.org/jira/browse/IVY-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1142:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
ivy:retrieve sync=true does nothing if first variable is optional
---
Key: IVY-1142
URL: https://issues.apache.org/jira/browse/IVY-1142
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0
Environment: Not relevant
Reporter: Andreas Axelsson
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: IVY-1142.patch
if the ivy.retrieve.pattern contains an optional parameter as the first
parameter, the sync feature of ivy:retrieve will get a path with a trailing
'(' causing it to find nothing to sync, leaving old files still in the
retrieve path.
Example:
ivy.retrieve.pattern = lib/([type]/)/[artifact].[ext]
sync will try to match orphaned files against lib/( which obviously contains
nothing.
The problem is in IvyPatternHelper.java getTokenRoot(), which only checks for
the first '[', but in the pattern above it needs to check for the first '('.
I could see that nothing but the Resolver uses this function so it looks like
it'll be pretty safe to just fix the check. I've attached a suggested fix
below. I rarely touch java, so there might be simpler ways to do it, but at
least it works.
{noformat}
diff -r 616a4e764dd1 src/java/org/apache/ivy/core/IvyPatternHelper.java
--- a/src/java/org/apache/ivy/core/IvyPatternHelper.javaFri Nov 20
11:38:53 2009 +0100
+++ b/src/java/org/apache/ivy/core/IvyPatternHelper.javaFri Nov 20
12:54:27 2009 +0100
@@ -472,7 +472,15 @@
}
public static String getTokenRoot(String pattern) {
-int index = pattern.indexOf('[');
+int[] delimiters = {'[', '('};
+for (int index = 0; index delimiters.length; ++index) {
+pattern = getTokenRoot(pattern, delimiters[index]);
+}
+return pattern;
+}
+
+private static String getTokenRoot(String pattern, int delimiter) {
+int index = pattern.indexOf(delimiter);
if (index == -1) {
return pattern;
} else {
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1172) Grammatical and typographic errors in documentation
[
https://issues.apache.org/jira/browse/IVY-1172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1172:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Grammatical and typographic errors in documentation
---
Key: IVY-1172
URL: https://issues.apache.org/jira/browse/IVY-1172
Project: Ivy
Issue Type: Bug
Components: Documentation
Affects Versions: 2.1.0
Reporter: J. Lewis Muir
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: ivy-doc-fixes.patch
Thank you for all the effort to write the documentation. Attached is a patch
against {{https://svn.apache.org/repos/asf/ant/ivy/core/trunk/doc}} to fix
grammatical and typographic errors in the documentation to make it better. I
didn't have time to go through all of the documentation, but this fixes some
of it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1175) ApacheURLLister does not allow directories not containing a dot
[ https://issues.apache.org/jira/browse/IVY-1175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1175: --- Fix Version/s: 2.2.0-RC1 (was: trunk) ApacheURLLister does not allow directories not containing a dot --- Key: IVY-1175 URL: https://issues.apache.org/jira/browse/IVY-1175 Project: Ivy Issue Type: Bug Components: Core Affects Versions: trunk Reporter: Anders Jacobsson Assignee: Maarten Coene Priority: Minor Fix For: 2.2.0-RC1 Attachments: artifactory_directory_listing.zip, patch.diff I need to use a different revision scheme that looks like R1A01, i.e. not the normal scheme x.y.z, for my company internal dependencies. When doing this, I discovered that ApacheURLLister does not handle directories without a dot (.) properly as it filters those out. If it does not find a dot in the directory name, it compares the href with the text but forgets to check for a trailing slash in href. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1158) Make ivy.xml conf description available
[ https://issues.apache.org/jira/browse/IVY-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1158: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Make ivy.xml conf description available - Key: IVY-1158 URL: https://issues.apache.org/jira/browse/IVY-1158 Project: Ivy Issue Type: New Feature Components: Ant Reporter: Jan Matรจrne Assignee: Maarten Coene Priority: Minor Fix For: 2.2.0-RC1 You can (an IMHO should) write an explanation of the configuration in the ivy file ivy-module version=2.0 configurations conf name=runtime description=Runtime Libraries/ /configurations /ivy-module The Ant task ivy:info/ makes the names names available, but not the descriptions. So the first RFE is making them available (accoding to 'infotest.configurations') as 'infotest.configuration.descriptions'. Another RFE is enhanding ivy:retrieve/ to create a describing file in the destination directory which contains this information. E.e. with Ivy pattern lib/[conf]/[artifact].[ext] you would create with ivy:retrieve descriptionfile=readme.txt/ a file lib/runtime/readme.txt with content Runtime Libraries. (!! Recreate old files, but beware that multiple confs could result in the same dir if the ivy pattern doesnt contain a [conf]. ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1145) metadata lock files not always deleted from cache
[ https://issues.apache.org/jira/browse/IVY-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1145: --- Fix Version/s: 2.2.0-RC1 (was: trunk) metadata lock files not always deleted from cache - Key: IVY-1145 URL: https://issues.apache.org/jira/browse/IVY-1145 Project: Ivy Issue Type: Bug Components: Core Affects Versions: trunk Reporter: Jason Trump Assignee: Maarten Coene Fix For: 2.2.0-RC1 DefaultRepositoryCacheManager.cacheModuleDescriptor() sometimes leaves metadata*.lck files in the cache directory after a successful resolve. the problem seems to only occur when the searched artifact is actually found in the cache. The problem starts on DefaultRepositoryCacheManager:880, where the lock is created. It looks like lock / unlock should always happen in a try/finally, which doesn't happen here. In my case, the method returns on line 920 without ever unlocking the file. The issue started at revision 805346 (the most recent revision to this file). happy coding jt -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1180) Support changing=true for inline resolve/retrieve
[ https://issues.apache.org/jira/browse/IVY-1180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1180: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Support changing=true for inline resolve/retrieve --- Key: IVY-1180 URL: https://issues.apache.org/jira/browse/IVY-1180 Project: Ivy Issue Type: New Feature Components: Ant Affects Versions: 2.1.0 Reporter: Phil Clay Assignee: Maarten Coene Fix For: 2.2.0-RC1 For dependencies in an ivy.xml file, I can specify changing=true. I would like to be able to specify changing=true for inline resolve/retrieves as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-807) Ivy doesn't support Maven 2.0.9 'import' scope
[ https://issues.apache.org/jira/browse/IVY-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-807: -- Fix Version/s: 2.2.0-RC1 (was: trunk) Ivy doesn't support Maven 2.0.9 'import' scope -- Key: IVY-807 URL: https://issues.apache.org/jira/browse/IVY-807 Project: Ivy Issue Type: Improvement Components: Maven Compatibility Reporter: Xavier Hanin Assignee: Maarten Coene Fix For: 2.2.0-RC1 Recently releases Maven 2.0.9 introduced a new scope, which is not yet supported by Ivy. See here for details about this new scope: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Importing_Dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1102) ivy parse exception when using publications defaultconf
[ https://issues.apache.org/jira/browse/IVY-1102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1102: --- Fix Version/s: 2.2.0-RC1 (was: trunk) ivy parse exception when using publications defaultconf - Key: IVY-1102 URL: https://issues.apache.org/jira/browse/IVY-1102 Project: Ivy Issue Type: Bug Reporter: Shawn Castrianni Assignee: Maarten Coene Fix For: 2.2.0-RC1 I have an ivy.xml file that uses the somewhat new feature of defaultconf in the publications XML tag. This allows a default conf settings for all publications that do not specify one. When using this AND not publishing all configurations, I get this: 16:39:32,3 [lgcbuild-publish-reposit...@buildmaster2:8080] WARN - /d01/QuickBuild/workspace/root/lgcbuilds/lgcbuild/lgcbuild/ivy/build/master.xml:2793: impossible to publish artifacts for Landmark#jTableTools#HEAD;work...@buildmaster2: java.lang.IllegalStateException: bad ivy file for Landmark#jTableTools#HEAD;work...@buildmaster2: /d01/QuickBuild/workspace/root/lgcbuilds/DSInfrastructure/jTableTools/DS_5000_4_0_0/jTableTools/build/module/ivy/ivy.xml: java.text.ParseException: Cannot add artifact 'module.xml(homes)' to configuration 'all' of module Landmark#jTableTools#HEAD;DS_5000_4_0_0.HEAD.090710.1 because this configuration doesn't exist! in file:/d01/QuickBuild/workspace/root/lgcbuilds/DSInfrastructure/jTableTools/DS_5000_4_0_0/jTableTools/build/module/ivy/ivy.xml In my example, I have: publications defaultconf=all,win32,win64,linux,linux64,solaris but in this case, I am only trying to publish configurations generic and linux64. Therefore, my delivered ivy file only has those two conf defined: configurations conf name=generic/ conf name=linux64/ /configurations This is causing the error above. If I remove the defaultconf and put the conf by all the artifacts, this problem goes away. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1165) During retreieve: Creation of symlinks problematic in Windows with Cygwin 1.7
[ https://issues.apache.org/jira/browse/IVY-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1165: --- Fix Version/s: 2.2.0-RC1 (was: trunk) During retreieve: Creation of symlinks problematic in Windows with Cygwin 1.7 - Key: IVY-1165 URL: https://issues.apache.org/jira/browse/IVY-1165 Project: Ivy Issue Type: Bug Affects Versions: 2.1.0-RC2 Environment: Windows 7 64 bit Cygwin 1.7 Cygwin's bin directory on PATH Reporter: John Brandy Assignee: Maarten Coene Fix For: 2.2.0-RC1 On Windows with the Cygwin 1.7 bin directory on the PATH, Ivy will create a ~1kb symlink file instead of copying the jar to the ivylib directory. This causes the retrieve process to fail. As described in [IVY-353|http://issues.apache.org/jira/browse/IVY-353], the creation of symlinks with cygwin was problematic for Windows systems. The fix as I understand it was to attempt to create a symlink, if that failed (the expected file did not exist) then copy the jar. That worked with the default configuration of Cygwin 1.5 which attempted to create Windows link (file.lnk) files. However as of 1.7 cygwin does not default to that behavior anymore and now Ivy fails in this case. For either version, if cygwin's environment option winsymlinks is turned to off -- which 1.7 defaults to -- then Ivy won't successfully retrieve due to thinking that the creation of a symlink was successful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1177) Can't deal with [VERSION] version pattern from Maven
[
https://issues.apache.org/jira/browse/IVY-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1177:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Can't deal with [VERSION] version pattern from Maven
Key: IVY-1177
URL: https://issues.apache.org/jira/browse/IVY-1177
Project: Ivy
Issue Type: Bug
Affects Versions: 2.1.0
Environment: Windows XP and Mac OS
Reporter: Richard Vowles
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
If you want a specific version of a resource in Maven, [VERSION] is a valid
request - e.g. [1.5.8]
I am using grape (from Groovy) and
grape -d install org.slf4j slf4j-api [1.5.8]
will not work. These dependencies are all over the place in our maven repo
(and presumably others). I fixed it by adding to ModuleRevisionId.java
protected static String normalizeRevision(String asked) {
if ( asked.startsWith( [ ) asked.endsWith( ] )
asked.indexOf(',') == -1 ) {
return asked.substring(1, asked.length() - 1 );
} else
return asked;
}
and using it in the constructor:
this.revision = revision == null ? Ivy.getWorkingRevision() :
normalizeRevision(revision);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1111) Ivy deliver fails to replace dynamic revision when using extra attributes
[
https://issues.apache.org/jira/browse/IVY-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Ivy deliver fails to replace dynamic revision when using extra attributes
-
Key: IVY-
URL: https://issues.apache.org/jira/browse/IVY-
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0-RC2
Environment: Ivy 2.1.0-rc2 - 20090704004254
Apache Ant version 1.7.0 compiled on December 13 2006
Reporter: Michael Scheetz
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: IVY-.svn.patch, ivy-.zip
Running ivy:deliver does not replace the dynamic revision correctly if I also
use extended attributes.
My Repository contains four modules: junit in revision 3.8 and 4.4. A Module
A that depends on junit 4.4 and a module B that depends on junit 3.8.+. (I
just copied this layout from a similar defect, IVY-999). (I will add a zip
with this setup once I figure out how).
My ivy.xml file:
?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0 xmlns:e=http://ant.apache.org/ivy/extra;
info organisation=test module=c e:att=att /
!--adressmodul --
configurations
conf name=default visibility=public/
/configurations
publications/
dependencies
dependency org=test name=a rev=latest.integration/
dependency org=junit name=junit conf=default
rev=latest.integration/
dependency org=test name=b rev=latest.integration e:att=att/
/dependencies
/ivy-module
The resultant ivy.xml after running the deliver task:
?xml version=1.0 encoding=UTF-8?
ivy-module version=2.0 xmlns:e=http://ant.apache.org/ivy/extra;
info organisation=test module=c revision=2009081924
status=integration publication=2009081924 e:att=att/
!--adressmodul --
configurations
conf name=default visibility=public/
/configurations
publications/
dependencies
dependency org=test name=a rev=1
revConstraint=latest.integration/
dependency org=junit name=junit conf=default rev=4.4
revConstraint=latest.integration/
dependency org=test name=b rev=latest.integration e:att=att/
/dependencies
/ivy-module
Update:
A problem appears to be in the DeliverEngine.deliver(ModuleRevisionId,
String, String, DeliverOptions) method, in step #3. Using SVN revision
811164, the line at 159 is:
String rev = (String)
resolvedRevisions.get(dependencies[i].getDependencyRevisionId());
if (rev == null) {
rev = dependencies[i].getDependencyRevisionId().getRevision();
}
There are two ModuleRevisionId objects, one in the map and one in the
DependencyDescriptor but they have different extra attributes. The one in
the DependencyDescriptor includes the namespace on the extra attribute while
the one in the map does not. Hence the lookup in the map is a miss so the
failover action is to use the revision out of the DependencyDescriptor
objects ModuleRevisionId, which is a dynamic revision.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1139) Avoid spaces in organization name, module name or both?
[ https://issues.apache.org/jira/browse/IVY-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1139: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Avoid spaces in organization name, module name or both? --- Key: IVY-1139 URL: https://issues.apache.org/jira/browse/IVY-1139 Project: Ivy Issue Type: Improvement Components: Documentation Reporter: Iouri Goussev Assignee: Nicolas Lalevรฉe Priority: Minor Fix For: 2.2.0-RC1 Original Estimate: 0.25h Remaining Estimate: 0.25h http://ant.apache.org/ivy/history/latest-milestone/tutorial/start.html Tutorial states Then there is an info tag, which is used to give information about the module for which we are defining dependencies. Here we define only the organization and module name, you are free to choose whatever you want for them, but we recommend avoiding spaces. Can you clarify is spaces are do be avoided in organization name or in module name. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-491) Australian mirror on Ivy samples needs changing
[ https://issues.apache.org/jira/browse/IVY-491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-491: -- Fix Version/s: 2.2.0-RC1 (was: trunk) Australian mirror on Ivy samples needs changing --- Key: IVY-491 URL: https://issues.apache.org/jira/browse/IVY-491 Project: Ivy Issue Type: Improvement Components: Documentation Affects Versions: 2.0.0-alpha-1 Reporter: Matt Havilah Assignee: Maarten Coene Priority: Trivial Fix For: 2.2.0-RC1 The Australian Maven2 mirror to planetmirror needs its hostname to be changed in the Ivy examples. (eg, $IVY_ROOT\src\example\build-a-ivy-repository\config\ivy-maven2-ivysettings.xml). It is currently listed as: http://public.planetmirror.com/pub/maven2/ but this is the HTML/web based browser for the repository which sends HTML summary pages before redirecting to the download host. When used with the build-a-repository Ant examples, this mirror will break the ibiblio Maven2 client. I suggest changing it to: http://downloads.planetmirror.com/pub/maven2/ == ivy-maven2-ivysettings.xml excerpt = ivysettings !-- you can override this property to use mirrors http://mirrors.dotsrc.org/maven2 http://ftp.ggi-project.org/pub/packages/maven2 http://mirrors.sunsite.dk/maven2 http://downloads.planetmirror.com/pub/maven2 == AUS http://ibiblio.lsu.edu/main/pub/packages/maven2 http://www.ibiblio.net/pub/packages/maven2 -- !-- property name=ibiblio-maven2-root value=http://www.ibiblio.org/maven2/; override=false / -- property name=ibiblio-maven2-root value=http://downloads.planetmirror.com/pub/maven2; override=false / property name=ibiblio-maven2-pattern value=[organisation]/[module]/[revision]/[module]-[revision].[ext] override=false / == ivy-maven2-ivysettings.xml excerpt = -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1021) add flag or exclude option to ivy:install to avoid source or javadoc packages
[ https://issues.apache.org/jira/browse/IVY-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1021: --- Fix Version/s: 2.2.0-RC1 (was: trunk) add flag or exclude option to ivy:install to avoid source or javadoc packages - Key: IVY-1021 URL: https://issues.apache.org/jira/browse/IVY-1021 Project: Ivy Issue Type: Improvement Components: Ant Affects Versions: 2.0 Environment: ivy beta 2 is affected Reporter: Brian Matzon Assignee: Gilles Scokart Priority: Critical Fix For: 2.2.0-RC1 Changes comitted in IVY-325 results in ivy:install to install source and javadoc files. This is all fine, except if people dont use [type] in their pattern it will fail because its trying to download multiple files with the same name (but different type). This is a change in behavior since 2.0 beta2. it would be nice to either add a flag to avoid this behavior or add and exclude/include section, like the dependencies. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1169) parent.groupId is not resolved in maven 2 parser
[
https://issues.apache.org/jira/browse/IVY-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1169:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
parent.groupId is not resolved in maven 2 parser
Key: IVY-1169
URL: https://issues.apache.org/jira/browse/IVY-1169
Project: Ivy
Issue Type: Bug
Components: Maven Compatibility
Affects Versions: 2.1.0
Reporter: Achim H.
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: ivy-groupid_2010_02_09.patch
A reference to the groupId of the parent module is not resolved correctly.
Example (from
http://www.fornax-platform.org/archiva/repository/releases/org/openarchitectureware/oaw-core-expressions/4.3.1/oaw-core-expressions-4.3.1.pom):
project
...
groupId${parent.groupId}/groupId
version1.0/version
This breaks the build
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1057) resolver attribute for listmodules task
[ https://issues.apache.org/jira/browse/IVY-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1057: --- Fix Version/s: 2.2.0-RC1 (was: trunk) resolver attribute for listmodules task --- Key: IVY-1057 URL: https://issues.apache.org/jira/browse/IVY-1057 Project: Ivy Issue Type: Improvement Reporter: Michael Kebe Assignee: Maarten Coene Priority: Minor Fix For: 2.2.0-RC1 listmodules task should have an optional resolver attribute like the buildnumber task. See similar (already closed) issue: https://issues.apache.org/jira/browse/IVY-1019 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1128) SearchEngine.listModules returns MRID without extra attributes.
[ https://issues.apache.org/jira/browse/IVY-1128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1128: --- Fix Version/s: 2.2.0-RC1 (was: trunk) SearchEngine.listModules returns MRID without extra attributes. --- Key: IVY-1128 URL: https://issues.apache.org/jira/browse/IVY-1128 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0-RC2 Environment: Ivy 2.1.0-rc2 - 20090704004254 Apache Ant version 1.7.0 compiled on December 13 2006 Reporter: Michael Scheetz Assignee: Maarten Coene Fix For: 2.2.0-RC1 Attachments: IVY-1128.fix.svn.patch, IVY-1128b.improvetest.patch The ModuleRevisionId objects that are returned by the SearchEngine.listModules(ModuleRevisionId, PatternMatcher) method does not contain any extra attributes. If extra attributes are passed in then they should also be added to the returned module. Without the extra attributes then then the modules returned are practically useless for any further use. This method is published in the Ivy class, too. See attached for test and fix patch. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1138) discover src sources in maven repos
[ https://issues.apache.org/jira/browse/IVY-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1138: --- Fix Version/s: 2.2.0-RC1 (was: trunk) discover src sources in maven repos --- Key: IVY-1138 URL: https://issues.apache.org/jira/browse/IVY-1138 Project: Ivy Issue Type: Improvement Components: Core Affects Versions: 2.1.0 Reporter: Stephen Haberman Assignee: Maarten Coene Fix For: 2.2.0-RC1 Velocity decided to be different and publish their src as -src instead of -sources: http://mirrors.ibiblio.org/pub/mirrors/maven2/org/apache/velocity/velocity/1.6.2/ But ivy does not pick it up, only the main jar and the artifact are recognized: http://sprunge.us/EbQW It'd be nice if, like IvyDEs -sources/-src suffix option, that the Velocity source artifact was discovered as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1146) Cannot find the correct version of dependencies in pom that doesn't list versions
[ https://issues.apache.org/jira/browse/IVY-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1146: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Cannot find the correct version of dependencies in pom that doesn't list versions - Key: IVY-1146 URL: https://issues.apache.org/jira/browse/IVY-1146 Project: Ivy Issue Type: Bug Components: Maven Compatibility Affects Versions: 2.1.0-RC1, 2.1.0-RC2, 2.1.0 Reporter: Jason Porter Assignee: Maarten Coene Fix For: 2.2.0-RC1 The weld-core pom (http://repo1.maven.org/maven2/org/jboss/weld/weld-core/1.0.0/weld-core-1.0.0.pom) doesn't list the versions of the dependencies. Instead they're listed in a parent pom further up the chain (two or three IIRC). Odd thing is it worked fine when I pulled them down from a local artifactory install that was caching central. It does not work when fetching straight from central. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1115) ResolveEngine.getDependencies does not work using extra attributes.
[
https://issues.apache.org/jira/browse/IVY-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1115:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
ResolveEngine.getDependencies does not work using extra attributes.
---
Key: IVY-1115
URL: https://issues.apache.org/jira/browse/IVY-1115
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0-RC2
Environment: Ivy SVN version 808087
Apache Ant version 1.7.0 compiled on December 13 2006
Reporter: Michael Scheetz
Assignee: Maarten Coene
Priority: Minor
Fix For: 2.2.0-RC1
Attachments: IVY-1115.tests.svn.patch
I wrote these two tests for
'test/java/org/apache/ivy/core/resolve/ResolveEngineTest.java'. The one
using extra attributes to build a dependency list does not return the
complete set of dependencies.
public void testBuildDependencyList_ExtraAtt() throws Exception {
System.setProperty(ivy.local.default.root, new
File(test/repositories/extra-attributes).getAbsolutePath());
System.setProperty(ivy.settings.file,
test/repositories/extra-attributes/ivysettings.xml);
String org = apache;
String mod = mymodule;
String rev = 1749;
Map extraAttributes = new HashMap();
extraAttributes.put(eatt, task2);
extraAttributes.put(eatt2, test);
ResolveEngine engine = new ResolveEngine(ivy.getSettings(),
ivy.getEventManager(), ivy.getSortEngine());
ModuleRevisionId mRevId = ModuleRevisionId.newInstance(org, mod, rev,
extraAttributes);
DefaultModuleDescriptor md =
DefaultModuleDescriptor.newCallerInstance(mRevId, new String[] {*}, true,
false);
String resolveId = ResolveOptions.getDefaultResolveId(md);
ResolveOptions options = new ResolveOptions();
options.setConfs(new String[] {*});
options.setResolveId(resolveId);
ResolveReport report = new ResolveReport(md, options.getResolveId());
IvyNode[] deps = engine.getDependencies(md, options, report);
assertEquals(2, deps.length);
assertTrue(Arrays.toString(deps).contains(apache#mymodule;1749));
assertTrue(Arrays.toString(deps).contains(apache#module2;1976));
}
public void testBuildDependencyList_MultiDeps() throws Exception {
System.setProperty(ivy.local.default.root, new
File(test/repositories/1).getAbsolutePath());
System.setProperty(ivy.settings.file,
test/repositories/ivysettings-1.xml);
String org = org2;
String mod = mod2.3;
String rev = 0.4;
ResolveEngine engine = new ResolveEngine(ivy.getSettings(),
ivy.getEventManager(), ivy.getSortEngine());
ModuleRevisionId mRevId = ModuleRevisionId.newInstance(org, mod, rev);
DefaultModuleDescriptor md =
DefaultModuleDescriptor.newCallerInstance(mRevId, new String[] {*}, true,
false);
String resolveId = ResolveOptions.getDefaultResolveId(md);
ResolveOptions options = new ResolveOptions();
options.setConfs(new String[] {*});
options.setResolveId(resolveId);
ResolveReport report = new ResolveReport(md, options.getResolveId());
IvyNode[] deps = engine.getDependencies(md, options, report);
assertEquals(4, deps.length);
}
Update:
There seems to be parsing issue using extra attributes on the artifact, or
perhaps there is a test setup issue. Lookup with only module level extra
attributes seems to work.
java.text.ParseException: [xml parsing: ivy.xml.original:28:60:
cvc-complex-type.3.2.2: Attribute 'platform' is not allowed to appear in
element 'artifact'. in
file:/Project/ivy/test/repositories/extra-attributes/cache/apache/mymodule/task2/1749/ivy.xml.original
, xml parsing: ivy.xml.original:29:58: cvc-complex-type.3.2.2: Attribute
'platform' is not allowed to appear in element 'artifact'. in
file:/Project/ivy/test/repositories/extra-attributes/cache/apache/mymodule/task2/1749/ivy.xml.original
]
at
org.apache.ivy.plugins.parser.AbstractModuleDescriptorParser$AbstractParser.checkErrors(AbstractModuleDescriptorParser.java:89)
at
org.apache.ivy.plugins.parser.AbstractModuleDescriptorParser$AbstractParser.getModuleDescriptor(AbstractModuleDescriptorParser.java:342)
at
org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser.parseDescriptor(XmlModuleDescriptorParser.java:103)
at
org.apache.ivy.plugins.parser.AbstractModuleDescriptorParser.parseDescriptor(AbstractModuleDescriptorParser.java:48)
at
[jira] Updated: (IVY-1168) Authentication won't work in some situations
[
https://issues.apache.org/jira/browse/IVY-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1168:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Authentication won't work in some situations
Key: IVY-1168
URL: https://issues.apache.org/jira/browse/IVY-1168
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0
Reporter: Sven Walter
Assignee: Maarten Coene
Priority: Minor
Fix For: 2.2.0-RC1
Attachments: changes.zip, patch_from_trunk.patch
Hi,
Regarding a requirement to publish an artifact (Hudson - ivy (v.2.1.0)) only
after a successful authentication against Archiva and LDAP I tried to realize
it with the tag credential which is part of the ivysettings.xml.
Unfortunately, it was quite hard to get this finally done. Different forum
discussions did not provide enough help to solve my problems. After
investigation and debugging of the ivy code I found the following
issues/problems:
1. IvyAuthenticator was sometimes not the default:
We have a very complex build process which includes some sub-ant calls. This
leads to the problem that the default Authenticator will be changed to the
java default or at least not the IvyAuthenticator. To ensure that the right
one will be used I changed the BasicURLHandler and set the default before
establishing the connection and publishing or retrieving an artifact.
...
public void upload(...) { ...
Authenticator.setDefault(IvyAuthenticator.INSTANCE); ... }
...
2. Unexpected realm information
By using the HttpClient the realm won't be considered. We have different
repositories in our Archiva (and only one host). The implementation adds the
credential twice (key=re...@host and key=host). The last one will win because
the HttpClient does not get the realm information. I think a better approach
in this situation is to authenticate without the realm
(HttpClientHandler.java). The current implementation works only if you have
one repository or the last defined credential is always the right one.
...
new AuthScope(c.getHost(), AuthScope.ANY_PORT, AuthScope.ANY_REALM) ...
...
3. The mystery of the realm
The documentation is not very clear about the realm. It is hard to find out
what the right realm is. To get a better overview I extend the class
CredentialsStore with additional logging information to get more light into
the dark.
...
public Credentials getCredentials(...) { Message.debug(try to get
credentials for: + realm + @ + host); ... }
...
I build a new ivy.jar including all of my changes and now, it works. To avoid
further costs in the future (by upgrading ivy) and supporting ivy I want to
incorporate my changes into one of the next ivy releases. Is this possible or
in general what do you think about the changes?
Best regards,
Sven Walter
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1162) ivy.settings.dir space escaping problem
[ https://issues.apache.org/jira/browse/IVY-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1162: --- Fix Version/s: 2.2.0-RC1 (was: trunk) ivy.settings.dir space escaping problem --- Key: IVY-1162 URL: https://issues.apache.org/jira/browse/IVY-1162 Project: Ivy Issue Type: Bug Affects Versions: 2.1.0 Reporter: Geoff Reedy Assignee: Maarten Coene Fix For: 2.2.0-RC1 Attachments: ivybug.zip When an ivysettings file is included from a path with spaces in it, the ivy.settings.dir property becomes doubly escaped. I run into this problem when trying to configure the ivy classpath. This is causing a lot of pain for our team members using windows since they want to keep everything under their home directory which includes spaces in the path due to the C:\Documents and Settings directory. I'll be attaching a testcase which throws an exception when java -jar ivy-2.1.0.jar -settings ivysettings.xml is called. The exception root cause is: Caused by: java.lang.RuntimeException: impossible to define new type: class not found: Foo in [file:/tmp/x/dir%2520with%2520spaces/foo.jar] nor Ivy classloader at org.apache.ivy.core.settings.IvySettings.classForName(IvySettings.java:648) at org.apache.ivy.core.settings.IvySettings.typeDef(IvySettings.java:632) at org.apache.ivy.core.settings.IvySettings.typeDef(IvySettings.java:628) at org.apache.ivy.core.settings.XmlSettingsParser.typedefStarted(XmlSettingsParser.java:503) at org.apache.ivy.core.settings.XmlSettingsParser.startElement(XmlSettingsParser.java:205) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:504) at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:182) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanStartElement(XMLDocumentFragmentScannerImpl.java:1315) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2723) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:624) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:486) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:810) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:740) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:110) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1208) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:525) at javax.xml.parsers.SAXParser.parse(SAXParser.java:392) at javax.xml.parsers.SAXParser.parse(SAXParser.java:274) at org.apache.ivy.core.settings.XmlSettingsParser.doParse(XmlSettingsParser.java:160) ... 23 more -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1151) Report stylesheet does not show configurations
[ https://issues.apache.org/jira/browse/IVY-1151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1151: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Report stylesheet does not show configurations -- Key: IVY-1151 URL: https://issues.apache.org/jira/browse/IVY-1151 Project: Ivy Issue Type: Improvement Components: Documentation Affects Versions: 2.1.0 Environment: all Reporter: Jasper Blues Assignee: Maarten Coene Priority: Minor Fix For: 2.2.0-RC1 Attachments: ivy-doc.xsl The ivy-doc.xsl report template should include a column for configuration in the dependencies section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1155) Ivy cannot parse alternate format for Maven MD5 files
[
https://issues.apache.org/jira/browse/IVY-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1155:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
Ivy cannot parse alternate format for Maven MD5 files
-
Key: IVY-1155
URL: https://issues.apache.org/jira/browse/IVY-1155
Project: Ivy
Issue Type: Bug
Components: Maven Compatibility
Affects Versions: 2.1.0
Environment: Windows 7, Sun JDK 1.6.0_16, Ant 1.7.1
Reporter: Ryan Saunders
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Some projects in the public maven repositories have their MD5 sums in an
alternate format, like so:
{noformat}fontbox-0.8.0-incubating.jar: 68 7C AB 04 4C 8F 93 7B 89 57 16 62
72 F1 DA 3C{noformat}
Ivy cannot handle this...it interprets fontbox-0.8.0-incubating.jar as the
expected MD5 sum, and then concludes that the associated .jar file is corrupt
and refuses to use it. The same problem exists for some of the .pom files.
This minor issue makes these projects unusable in the maven repo. (So far,
I've only found this issue with org.apache.pdfbox and org.apache.fontbox.)
Ideally, Ivy would be able to read the alternate format, but it would
probably be acceptable if there were some way to selectively ignore the
checksum files.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1105) Excessive hits to missing URLs uses up all ports on Windows
[ https://issues.apache.org/jira/browse/IVY-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1105: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Excessive hits to missing URLs uses up all ports on Windows --- Key: IVY-1105 URL: https://issues.apache.org/jira/browse/IVY-1105 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0-RC1 Environment: windows xp sp3, running Ivy repository through http for remote resolving Reporter: Ernest Pasour Assignee: Maarten Coene Fix For: 2.2.0-RC1 Attachments: ApacheURLLister.java Modified description to be clearer: Ivy is extremely aggressive towards repositories . This can result in failures to resolve, even against a healthy repository and with no network latency. The symptom: [ivy:resolve] 01-07-2008 13:16:24 org.apache.commons.httpclient.HttpMethodDirector executeWithRetry [ivy:resolve] INFO: I/O exception (java.net.BindException) caught when processing request: Address already in use: connect. This is especially a problem with large repositories (lots of revisions) and resolving against latest.integration as this will fetch ivy.xml md5 and sha1 files for every revision. As I've included in a comment, the problem appears to be Ivy's attempts to list URLs that don't actually exist. Ivy builds up URLs using the repository location and appending organizations and module names. We have ivy chains that contain 5 links or more. So for each successful attempt to list an URL, there are several attempts to list non-existent URLs. This is wasteful in terms of time, and can lead to using up all of the available Windows ports on the client machine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1119) VstfpRepository.readResponse uses bad compare logic
[
https://issues.apache.org/jira/browse/IVY-1119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1119:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
VstfpRepository.readResponse uses bad compare logic
---
Key: IVY-1119
URL: https://issues.apache.org/jira/browse/IVY-1119
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0-RC2
Reporter: Dave Brosius
Assignee: Maarten Coene
Priority: Minor
Fix For: 2.2.0-RC1
VsftpRepository.readResponse compares a string to a stringbuffer
if (Not connected..equals(response)) {
should be
if (Not connected..equals(response.toString())) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1133) ChainResolver Checkmodified override bug
[
https://issues.apache.org/jira/browse/IVY-1133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1133:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
ChainResolver Checkmodified override bug
Key: IVY-1133
URL: https://issues.apache.org/jira/browse/IVY-1133
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0-RC2
Reporter: jaco uys
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: Checkmodified.patch
I have found an issue some time ago with resolving dependencies via a
chain resolver.
I can not remember the exact scenario, but had to do with resolving A
- B - C where A and C comes from a local repo and B from a 'shared'
repo.
The issue seems to be with ChainResolver that overrides 'public void
setCheckmodified(boolean check)'. The 'checkModified' value is not
propagated through to the base class 'AbstractResolver'. This results
in the 'AbstractResolver.getCacheOptions(ResolveData data)' behaving
incorrectly when creating the 'CacheMetadataOptions'.
The fix I made was to change the 'ChainResolver.setCheckmodified' to:
public void setCheckmodified(boolean check) {
checkmodified = Boolean.valueOf(check);
super.setCheckmodified(check);
}
I've attached an svn patch for it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1148) Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts
[ https://issues.apache.org/jira/browse/IVY-1148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1148: --- Fix Version/s: 2.2.0-RC1 (was: trunk) Encountered 'multiple artifacts retrieved to same file' error when module does not have multiple artifacts -- Key: IVY-1148 URL: https://issues.apache.org/jira/browse/IVY-1148 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0 Environment: Windows or Linux, i386 Reporter: Carlton Brown Assignee: Maarten Coene Fix For: 2.2.0-RC1 Attachments: ArtifactDownloadReport.patch, ivy_1148.xml Recently we started experiencing intermittent problems with the error 'multiple artifacts retrieved to same module' for artifacts that did not have multiple artifacts. I have not been able to create a simple contrived error, though I can generally reproduce it in our complex set of environments and artifacts. It started happening when we started using the branch attribute in our modules.Usually the problem happens when a module has a both a direct and an indirect dependency on another module. We were working around it by excluding the module from being resolved indirectly. During debugging, I traced it to the fact that a certain identical module revision was not being handled as identical. Specifically, in line 335 of RetrieveEngine, the artifact was being added to the conflictsReports HashSet. The ArtifactDownloadReport.equals() was determining them to be equal, so I did not expect them to be inserted. But the ArtifactDownloadReport.hashCode() was coming up with different integers. The cause of this is that one of the artifacts had an additional qualified attributed called 'merged' which was not different, even though this was the same version of the same artifact. The value of the attribute looked like: orgA#moduleA#trunk;build1245 - orgB#moduleB#trunk;build833 Where module Z is the module being resolved, and it has a direct dependency on module A and moduleB, and moduleB has a direct dependency on moduleA. So because of the different qualified attribute, an artifact that represented the same file was returning a different hash code. I'm not sure what this extra 'merged' information represents. It seems to represent something about how the artifact was resolved. There is no possible retrieve pattern that could (or should) differentiate artifacts that differ only in the 'merged' attribute, so I think this is a little too strict. My strategy, for which I am attaching a patch that passes existing unit tests, is to use a hashCode() and equals() method that represents the minimum necessary to determine whether an artifact maps to a unique file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1120) IvyBuildNumber non-deterministic behaviour
[
https://issues.apache.org/jira/browse/IVY-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1120:
---
Fix Version/s: 2.2.0-RC1
(was: trunk)
IvyBuildNumber non-deterministic behaviour
--
Key: IVY-1120
URL: https://issues.apache.org/jira/browse/IVY-1120
Project: Ivy
Issue Type: Bug
Components: Ant
Affects Versions: 2.1.0-RC2
Environment: ant 1.7.1, windows xp
Reporter: Lucas Lech
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
IvyBuildNumber.java - doExecute()
creates an inline patternMatcher with this method:
{code:title=IvyBuildNumber.java|borderStyle=solid}
public Matcher getMatcher(String expression) {
if ((expression == organisation)
|| (expression == module)
|| (expression == branch)) {
return exact.getMatcher(expression);
}
return regexp.getMatcher(expression);
}
{code}
I'm guessing the == comparison is a typo ? Shouldn't it be saying *.equals* ?
I've been having issues with this task - non-deterministic results - I got
down in my debug to this place where I get wrong matcher when
*reference address comparison* fails.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1095) ZipTask should support an option to allow the task to define the last modified date for content stored in the zip, jar, or war.
[ https://issues.apache.org/jira/browse/IVY-1095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1095: --- Fix Version/s: 2.2.0-RC1 (was: trunk) ZipTask should support an option to allow the task to define the last modified date for content stored in the zip, jar, or war. --- Key: IVY-1095 URL: https://issues.apache.org/jira/browse/IVY-1095 Project: Ivy Issue Type: Improvement Components: Ant Affects Versions: trunk Reporter: Mark Farnsworth Fix For: 2.2.0-RC1 Attachments: Zip.java.patch Original Estimate: 1h Remaining Estimate: 1h Currently with ANT Tasks it is not possible to fully control the way Zip, Jar, Ear, or War files are produced. The issue is that the default behavior of the task includes the last modified date information from the file system when in creates an archive. The result is that with the exact same source code the archive produced from any given build will vary based on where and when the build was run. In an environment like HUDSON where you wish to build on different servers, from different branches, and at different times this is problematic since the MD5 hash value of the artifact the build produces will not reflect the content of the code but rather reflect a combination of the content of the code and the current time of the server where the build was run. ANT should support an option for the task to define the last modified date of the archive. If support for this option is added to the Zip task then it will be automatically available in tasks that extend it. The patch file attached to this issue provides an implementation of the last modified attribute and can be applied to SVN revision 784603 of Zip.java. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1124) IbiblioResolver not always correctly configured when using JRE 1.5
[
https://issues.apache.org/jira/browse/IVY-1124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1124:
---
Fix Version/s: (was: trunk)
2.2.0-RC1
IbiblioResolver not always correctly configured when using JRE 1.5
--
Key: IVY-1124
URL: https://issues.apache.org/jira/browse/IVY-1124
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0-RC2
Environment: Linux
Reporter: Flavio Coutinho da Costa
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: IBiblioRepository.java.diff, IvyTest.zip
IBiblioResolver has a small bug due to a change in the behaviour between
Java5 and Java6.
After spending quite a lot of time debugging this I finally found where the
problem is.
I've added some debugging messages to the following methods so that I could
keep track of what is happening behind the scenes.
* setM2compatible
* setUsepoms
* setPattern
* setRoot
All the debug does it print the name of the method that's getting called and
print the hash code of the instance (just for the sake of identifying in
which repository the call happened)
From the documentation and from the code we can see that the 'usepoms'
property defaults to 'true'.
Now let's take a look the following snippet of code extracted from
IBiblioResolver:
private void updateWholePattern() {
if (isM2compatible() isUsepoms()) {
setIvyPatterns(Collections.singletonList(getWholePattern()));
}
setArtifactPatterns(Collections.singletonList(getWholePattern()));
}
Assuming that setM2compatible(true) happens before a setUsepoms(false) Ivy
would end up calling setIvyPatterns(...) and therefore setting an invalid Ivy
pattern (actually it's not invalid but a default one like this:
http://repo1.maven.org/maven2/). After this happens Ivy won't have a chance
to ever unset/reset the Ivy patterns list and because of that any artifact
which type equals to ivy will (try) to be uploaded to Maven Central
repository as this code extracted from RepositoryResolver highlights:
public void publish(Artifact artifact, File src, boolean overwrite)
throws IOException {
String destPattern;
if (ivy.equals(artifact.getType())
!getIvyPatterns().isEmpty()) {
destPattern = (String) getIvyPatterns().get(0);
} else if (!getArtifactPatterns().isEmpty()) {
destPattern = (String) getArtifactPatterns().get(0);
}
...
}
Instead of falling back to getArtifactPatterns (as desired and expected), Ivy
sees that the List returned by getIvyPatterns() is not empty (due to the bug
mentioned above) and tries to upload the ivy.xml file to Maven Central
(where, most of the mortals, can't HTTP PUT) resulting on the following:
/home/flavio/workspace/IvyTestCase/build.xml:16: impossible to publish
artifacts for my.test.case#ivy-test;1.0: java.io.IOException: PUT operation
to URL http://repo1.maven.org/maven2/my/test/case/ivy-test/1.0/ivy-1.0.xml
failed with status code 405
Enough of side effects, let's get back to the actual bug.
Like I said before this bug happens due to a difference in behaviour between
Java5 and Java6. The following ant output shows that:
--- Running Java(TM) SE Runtime Environment - 1.6.0_16-b01
[ivy:configure] :: Ivy 2.2.x-local-20090917003317 - 20090917003317 ::
http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file =
/home/flavio/workspace/IvyTestCase/ivysettings.xml
[ivy:configure] setM2compatible called for repo: 9740137
[ivy:configure] setUsepoms called for repo: 13228332
[ivy:configure] setPattern called for repo: 13228332
[ivy:configure] setRoot called for repo: 13228332
[ivy:configure] setM2compatible called for repo: 13228332
setUsepoms(false) is called before setM2compatible(true) so the bug is never
triggered because the condition in IBiblioResolver.updateWholePattern()
evaluates to false and setIvyPatterns(...) is NEVER called thus resulting on
getIvyPatterns() returning an empty List later on and because of that
RepositoryResolver falls back to getArtifactPatterns(). Everything works just
fine.
--- Running Java(TM) 2 Runtime Environment, Standard Edition - 1.5.0_21-b01
[ivy:configure] :: Ivy 2.2.x-local-20090917003317 - 20090917003317 ::
http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file =
/home/flavio/workspace/IvyTestCase/ivysettings.xml
[ivy:configure] setM2compatible called for repo: 18923308
[ivy:configure] setM2compatible called for repo: 13078969
[ivy:configure] setUsepoms called for repo: 13078969
[jira] Updated: (IVY-395) Enhance info/ task to access the 'publication', 'branch' and published artifacts as ant propeties.
[
https://issues.apache.org/jira/browse/IVY-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-395:
--
Fix Version/s: 2.2.0-RC1
(was: trunk)
Enhance info/ task to access the 'publication', 'branch' and published
artifacts as ant propeties.
Key: IVY-395
URL: https://issues.apache.org/jira/browse/IVY-395
Project: Ivy
Issue Type: Improvement
Components: Ant
Affects Versions: 1.4.1
Reporter: paolo di tommaso
Assignee: Maarten Coene
Fix For: 2.2.0-RC1
Attachments: ivy-395-2.patch, ivy-395-3.patch, ivy-395.patch
The pubblication attribute on info / element in IVY file is very useful.
When the attribute is not specified IVY set the attribute to the current
timestamp.
It would be very useful to access to 'publication' attribute from ANT during
artifacts build using a ${ivy.publication} property.
Using ANT task tstamp / to simulate that can create incoherent situation
because the two timestamps are not 'synchronized'
Similarly, a property for the 'branch' attribute could be added.
Access to the published artifacts declared in the ivy file as ant properties
would also be useful. This would allow a multi-project build system with a
common build file define the produced artifacts solely in the Ivy file and
have the common build file retrieve the names of the artifacts that it needs
to create from that ivy file via the info/ task.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-982) Dependency Configuration Negation does not work
[
https://issues.apache.org/jira/browse/IVY-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-982:
--
Fix Version/s: (was: trunk)
Dependency Configuration Negation does not work
---
Key: IVY-982
URL: https://issues.apache.org/jira/browse/IVY-982
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0-RC2, 2.0
Environment: windows xp
java 1.5 build 1.5.0_14-b03
ant 1.7.0
Reporter: Marc De Boeck
Assignee: Maarten Coene
Attachments: ant-d_resolve_with_ivy_rev_745851.txt
I am trying the define a dependency for all configurations in my module,
except for the configuration named hibernate. So I defined the following
dependency in my ivy.xml file:
bq. dependency org=spring name=spring-framework rev=2.5.1 conf=*,
!hibernate - web/
However, when resolving, I get the following error:
bq. [ivy:resolve] :: ivy-dependency-stubs#toolset#C2.0;MRC2.0:
java.text.ParseException: Problem occured while parsing ivy file:
Configuration '!hibernate' does not exist in module module:
ivy-dependency-stubs#toolset#C2.0;MRC2.0 status=release publication=Fri Dec
05 10:50:34 CET 2008 configurations={compile=compile, test=test, ear=ear,
hibernate=hibernate}
artifacts={compile=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt],
hibernate=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt],
ear=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt],
test=[ivy-dependency-stubs#toolset#C2.0;MRC2.0!toolset.txt]}
dependencies=[dependency: hibernate#hibernate#C2.0;3.2.6 {*=[default]},
dependency: spring#spring-framework#C2.0;2.5.1 {*=[web]}] in
file:/R:/ext950_r_costa_INCEPTION_int_dn/devtools/oobs/var/cache/ivy-dependency-stubs/toolset/C2.0/ivy-MRC2.0.xml.original
A similar problem has already been reported to the ivy-user group by somebody
else using the IvyDE, so I suspect it's a Ivy-core problem?
See:
http://www.nabble.com/Dependency-Configuration-Negation-ts20129596.html#a20129596
Attached is the stack trace:
{quote}
BUILD FAILED
R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:124: The
following error occurred while executing this line
:
R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:125:
impossible to resolve dependencies:
resolve failed - see output for details
at
org.apache.tools.ant.ProjectHelper.addLocationToBuildException(ProjectHelper.java:541)
at
org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:394)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at
org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at org.apache.tools.ant.Main.runBuild(Main.java:698)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
Caused by:
R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-base.xml:125:
impossible to resolve dependencies:
resolve failed - see output for details
at org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.java:315)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at
org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:62)
at
org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor2.invoke(Unknown Source)
at
[jira] Updated: (IVY-1044) retrieve doesn't retrive files if the current one is more recent
[ https://issues.apache.org/jira/browse/IVY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1044: --- Assignee: Maarten Coene Fix Version/s: 2.2.0-RC1 Component/s: Core retrieve doesn't retrive files if the current one is more recent Key: IVY-1044 URL: https://issues.apache.org/jira/browse/IVY-1044 Project: Ivy Issue Type: Bug Components: Ant, Core Affects Versions: 2.0 Environment: Win XP, J2SE 1.6.0_11-b03 Reporter: Daniel Dekany Assignee: Maarten Coene Fix For: 2.2.0-RC1 The retrieve task will not retrieve files (artifacts) whose file modification date is greater than of the file in the repository (in the resolver), not even if sync=true. This way the target directory goes out of sync if (a) the module is downgraded in the repository or (b) the developer has overwritten the artifact manually when experiencing with something. Thus the only way to keep the target directory in sync is deleting it before retrieving, but of course that means suboptimal performance, and makes sync=true useless anyway. Simply, a file should be retrieved if the date (or size!) is *different* than in the repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1159) Resolved Ivy Properties written to cache during ivy:resolve incorrectly represents transitive evictions
[
https://issues.apache.org/jira/browse/IVY-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1159:
---
Fix Version/s: 2.2.0-RC1
Resolved Ivy Properties written to cache during ivy:resolve incorrectly
represents transitive evictions
Key: IVY-1159
URL: https://issues.apache.org/jira/browse/IVY-1159
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: trunk
Reporter: Ed Burcher
Fix For: 2.2.0-RC1
Attachments: IVY1159.tar.gz
In ResolveEngine.resolve the code that writes the properties file appears to
be incorrect.
When the dependencies collection includes two or more entries for the same
dependency (one from the root ivy file and the others being transitives), the
properties file will always only ever be populated with the information from
the IvyNode that belongs to the root ivy file (effectively the comment states
this, so it certainly appears intentional).
This produces the following bugs / undesirable effects:
* incorrect delivered descriptor in some situations (where a dependency is
both directly and transitively imported)
* order of declaration of dependencies alters behaviour
These are pretty major problems because (as demonstrated below) a
delivered/published ivy descriptor can identify completely bogus revisions
for the dynamic-static replacements, which are not to the actual revisions
used when compiling etc
Set up
module *one* has no dependencies and has been published (as rev = 1, say)
module *two* has a dependency on module one (only) and has been published (as
rev = 1, also)
module *three* has dependencies on both modules one and two and *lists them
in the order two,one*
In the module three descriptor the revisions mentioned for two and one do not
actually exist (two=0 one=0 say - repository only contains rev=1 of both)
Ivy settings (attached) has a resolver that refers to a local repo, and has
force=true and local=true set.
Problem Case - use case: publishing module 3
1) ivy:resolve on module three, using refresh=true, transitive=true.
Otherwise nothing special here.
then
2) ivy:deliver (status=reelase, pubdate=now, deliverpattern supplied,
pubrevision supplied (rev=1))
3) (lastly, the ivy:publish step woud happen here, but is not relevant to the
problem)
Expected outcome:
Because the primary resolver has force=true, rev 1 of both module
dependencies of 'three' should be selected [Because rev=1 publications are
the only ones present in the repository] when resolving three's declared deps
(both of which declare a dep on rev=0).
Actual outcome:
Delivered descriptor correctly names two as being resolved to rev=1.
Incorrectly names module one as being resolved to rev=0 (which doesn't exist
- and never has!)
Workaround:
Reverse the order of the declared dependencies in three's ivy descriptor (i.e
new order is one, two) - problem does not occur.
Diagnosis:
Logs for resolve appear to show everything is fine (the eviction is noted,
the generated report xml shows the declared direct dependency (one, rev=0)
being evicted by the transitive dependency (one, rev=1 as declared in two's
published ivy descriptor)
However, debugging DeliverEngine.java and ResolveEngine.java - it is apparent
that the 'resolved ivy properties file' is used to drive the replacement of
dynamic revisions with static ones during deliver. In the error case, the
properties file shows this:
+revision\:\...@\#\:+0\:\...@\#\:+module\:\...@\#\:+one\: snip :=0 ?
+revision\:\...@\#\:+0\:\...@\#\:+module\:\...@\#\:+two\: snip :=1 release
The '?' is put there because the IvyNode that represented the direct
dependency has no descriptor (correctly, because it has been evicted).
Because the real selected revision is not put into the properties file, the
ivy:deliver task is doomed to produce wrong results.
The correct behaviour in this case would be for the EvictionInfo stored
against the evicted IvyNode to be inspected to find the appropriate revision
information. I have attached a pretty ugly example of how this could be
achieved.
Just before the comment (The evicted modules have no description, so we
can't put their status)
{code}
if (depDescriptor == null) {
EvictionData ed = null;
for (int j=0; jconfs.length ed == null;
j++) {
ed = dependencies[i].getEvictedData(confs[j]);
}
if (ed != null) {
Collection selected = ed.getSelected();
if (selected != null) {
[jira] Updated: (IVY-1044) retrieve doesn't retrive files if the current one is more recent
[ https://issues.apache.org/jira/browse/IVY-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1044: --- Issue Type: Improvement (was: Bug) retrieve doesn't retrive files if the current one is more recent Key: IVY-1044 URL: https://issues.apache.org/jira/browse/IVY-1044 Project: Ivy Issue Type: Improvement Components: Ant, Core Affects Versions: 2.0 Environment: Win XP, J2SE 1.6.0_11-b03 Reporter: Daniel Dekany Assignee: Maarten Coene Fix For: 2.2.0-RC1 The retrieve task will not retrieve files (artifacts) whose file modification date is greater than of the file in the repository (in the resolver), not even if sync=true. This way the target directory goes out of sync if (a) the module is downgraded in the repository or (b) the developer has overwritten the artifact manually when experiencing with something. Thus the only way to keep the target directory in sync is deleting it before retrieving, but of course that means suboptimal performance, and makes sync=true useless anyway. Simply, a file should be retrieved if the date (or size!) is *different* than in the repository. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1174) resolved module can include configurations of evicted versions
[ https://issues.apache.org/jira/browse/IVY-1174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1174: --- Fix Version/s: 2.2.0-RC1 resolved module can include configurations of evicted versions -- Key: IVY-1174 URL: https://issues.apache.org/jira/browse/IVY-1174 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.1.0-RC2 Reporter: Willem Verstraeten Fix For: 2.2.0-RC1 Scenario: module_parent, with two revisions: 1.0, which has configurations default and runtime, where default extends runtime 1.0.3, which only has configuration default module_middle, which depends on module_parent:1.0 module_between, which depends on module_parent:1.0.3 module_entry, which depends on module_middle and module_between When resolving module_entry, version 1.0 of module_parent will be evicted, but ivy will complain about module_parent not having a runtime configuration. Apparently, ivy has mashed the configurations from the 1.0 version (which was evicted) with those of 1.0.3, where there actually is no runtime configuration. -- 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 49266] ant does not work with empty CLASSPATH
https://issues.apache.org/bugzilla/show_bug.cgi?id=49266
Jesse Glick jgl...@netbeans.org changed:
What|Removed |Added
CC||jgl...@netbeans.org
--- Comment #2 from Jesse Glick jgl...@netbeans.org 2010-05-07 16:26:02 EDT
---
(In reply to comment #0)
$ unset CLASSPATH
$ ant
The -cp argument must be followed by a classpath expression
Does not happen to me. Are you using a custom java launcher wrapper shell
script? Run
file `which java`
and if it is not something like ELF 32-bit LSB executable, you might have a
buggy launcher - e.g. using $* or $@ rather than $@ for program arguments.
The -cp $CLASSPATH options are
appended to the command line even when the CLASSPATH is empty, resulting in a
command line which looks like 'exec java ... -cp '
More like:
exec java -classpath ...antstuff... -Dant.home=... -D...
org.apache.tools.ant.launch.Launcher -version -cp
i.e. three args are passed to main(String[]) in this example: {-version,
-cp, }, which should be fine.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
svn commit: r942269 - in /ant/core/trunk: doap_Ant.rdf docs/antnews.html docs/bindownload.html docs/faq.html docs/index.html docs/srcdownload.html xdocs/antnews.xml xdocs/bindownload.xml xdocs/faq.xml
Author: antoine Date: Fri May 7 23:25:55 2010 New Revision: 942269 URL: http://svn.apache.org/viewvc?rev=942269view=rev Log: actual release date is May 7th 2010 for Apache Ant 1.8.1 Modified: ant/core/trunk/doap_Ant.rdf ant/core/trunk/docs/antnews.html ant/core/trunk/docs/bindownload.html ant/core/trunk/docs/faq.html ant/core/trunk/docs/index.html ant/core/trunk/docs/srcdownload.html ant/core/trunk/xdocs/antnews.xml ant/core/trunk/xdocs/bindownload.xml ant/core/trunk/xdocs/faq.xml ant/core/trunk/xdocs/index.xml ant/core/trunk/xdocs/srcdownload.xml Modified: ant/core/trunk/doap_Ant.rdf URL: http://svn.apache.org/viewvc/ant/core/trunk/doap_Ant.rdf?rev=942269r1=942268r2=942269view=diff == --- ant/core/trunk/doap_Ant.rdf (original) +++ ant/core/trunk/doap_Ant.rdf Fri May 7 23:25:55 2010 @@ -35,6 +35,13 @@ category rdf:resource=http://projects.apache.org/category/build-management; / release Version +nameApache Ant 1.8.1/name +created2010-05-07/created +revision1.8.0/revision + /Version +/release +release + Version nameApache Ant 1.8.0/name created2010-02-08/created revision1.8.0/revision Modified: ant/core/trunk/docs/antnews.html URL: http://svn.apache.org/viewvc/ant/core/trunk/docs/antnews.html?rev=942269r1=942268r2=942269view=diff == --- ant/core/trunk/docs/antnews.html (original) +++ ant/core/trunk/docs/antnews.html Fri May 7 23:25:55 2010 @@ -208,7 +208,7 @@ a name=Ant1.8.1/a Ant1.8.1 /h3 -h3May 6th, 2010 - Ant 1.8.1 Released/h3 +h3May 7th, 2010 - Ant 1.8.1 Released/h3 pApache Ant 1.8.1 is now available for download as source or binary (with and without dependencies) from a href=http://ant.apache.org/bindownload.cgi;http://ant.apache.org/bindownload.cgi/a./p Modified: ant/core/trunk/docs/bindownload.html URL: http://svn.apache.org/viewvc/ant/core/trunk/docs/bindownload.html?rev=942269r1=942268r2=942269view=diff == --- ant/core/trunk/docs/bindownload.html (original) +++ ant/core/trunk/docs/bindownload.html Fri May 7 23:25:55 2010 @@ -248,7 +248,7 @@ Other mirrors: select name=Preferred a href=[preferred]/ant/README.htmlrelease notes/a./p div class=warning div class=labelNote/div -div class=contentAnt 1.8.1 was released on 6-May-2010 and +div class=contentAnt 1.8.1 was released on 7-May-2010 and may not be available on all mirrors for a few days./div /div br / Modified: ant/core/trunk/docs/faq.html URL: http://svn.apache.org/viewvc/ant/core/trunk/docs/faq.html?rev=942269r1=942268r2=942269view=diff == --- ant/core/trunk/docs/faq.html (original) +++ ant/core/trunk/docs/faq.html Fri May 7 23:25:55 2010 @@ -728,7 +728,7 @@ /td td colspan=1 rowspan=1 valign=top align=left - 6 May 2010 + 7 May 2010 /td /tr /table Modified: ant/core/trunk/docs/index.html URL: http://svn.apache.org/viewvc/ant/core/trunk/docs/index.html?rev=942269r1=942268r2=942269view=diff == --- ant/core/trunk/docs/index.html (original) +++ ant/core/trunk/docs/index.html Fri May 7 23:25:55 2010 @@ -204,7 +204,7 @@ a name=Ant1.8.1/a Ant1.8.1 /h3 -h3May 6th, 2010 - Ant 1.8.1 Released/h3 +h3May 7th, 2010 - Ant 1.8.1 Released/h3 pApache Ant 1.8.1 is now available for download as source or binary (with and without dependencies) from a href=http://ant.apache.org/bindownload.cgi;http://ant.apache.org/bindownload.cgi/a./p Modified: ant/core/trunk/docs/srcdownload.html URL: http://svn.apache.org/viewvc/ant/core/trunk/docs/srcdownload.html?rev=942269r1=942268r2=942269view=diff == --- ant/core/trunk/docs/srcdownload.html (original) +++ ant/core/trunk/docs/srcdownload.html Fri May 7 23:25:55 2010 @@ -246,7 +246,7 @@ Other mirrors: select name=Preferred a href=[preferred]/ant/README.htmlrelease notes/a./p div class=warning div class=labelNote/div -div class=contentAnt 1.8.1 was released on 6-May-2010 and +div class=contentAnt 1.8.1 was released on 7-May-2010 and may not be available on all mirrors for a few days./div /div br / Modified: ant/core/trunk/xdocs/antnews.xml URL:
svn commit: r942275 - /ant/core/trunk/ReleaseInstructions
Author: antoine Date: Fri May 7 23:50:44 2010 New Revision: 942275 URL: http://svn.apache.org/viewvc?rev=942275view=rev Log: the newsgroup comp.lang.java.announce is being retired. See http://groups.google.com/group/comp.lang.java.announce/msg/8476c676269b Modified: ant/core/trunk/ReleaseInstructions Modified: ant/core/trunk/ReleaseInstructions URL: http://svn.apache.org/viewvc/ant/core/trunk/ReleaseInstructions?rev=942275r1=942274r2=942275view=diff == --- ant/core/trunk/ReleaseInstructions (original) +++ ant/core/trunk/ReleaseInstructions Fri May 7 23:50:44 2010 @@ -285,8 +285,7 @@ Note: This document was updated in the c Announce release at freshmeat.net (Stefan Bodewig is the owner of Ant's project entry - bug him ;-). -Announce release in the usenet groups comp.lang.java.softwaretools -and comp.lang.java.announce. +Announce release in the usenet group comp.lang.java.softwaretools . 24. Add a new release tag to doap_Ant.rdf in Ant's trunk.
DO NOT REPLY [Bug 49015] Invoking ant -p fails when a path with ID ant.targets exists.
https://issues.apache.org/bugzilla/show_bug.cgi?id=49015 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 44239] Add ability of Ant resource classes to act as factories for relative resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=44239 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 48711] FTP task hangs when given incorrect configuration
https://issues.apache.org/bugzilla/show_bug.cgi?id=48711 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 44045] example unit test cases to create new JUnitReport format
https://issues.apache.org/bugzilla/show_bug.cgi?id=44045 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 45429] the zip package should support more modern zip features
https://issues.apache.org/bugzilla/show_bug.cgi?id=45429 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 44241] add JavaConstantResource to read string constants.
https://issues.apache.org/bugzilla/show_bug.cgi?id=44241 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 49261] Copy task fails to overwrite readonly files even with overwrite=true
https://issues.apache.org/bugzilla/show_bug.cgi?id=49261 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 48725] Include Property Rewriting
https://issues.apache.org/bugzilla/show_bug.cgi?id=48725 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 40608] xmlvalidate/schemavalidate would gain from a grammar caching
https://issues.apache.org/bugzilla/show_bug.cgi?id=40608 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 48529] [PATCH]Provide tree-like xml/html reports for TestSuite use
https://issues.apache.org/bugzilla/show_bug.cgi?id=48529 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 46058] Ant needs a streamable log format
https://issues.apache.org/bugzilla/show_bug.cgi?id=46058 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 49021] TaskDef/ScriptDef in Sub Build = Memory Disaster
https://issues.apache.org/bugzilla/show_bug.cgi?id=49021 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 44242] Add funtest task for functional testing
https://issues.apache.org/bugzilla/show_bug.cgi?id=44242 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 48985] Special characters like $ and ยง are not supported in password attribute of sshexec task
https://issues.apache.org/bugzilla/show_bug.cgi?id=48985 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 47153] Support tar files 8 GByte
https://issues.apache.org/bugzilla/show_bug.cgi?id=47153 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 45089] tstamp granularity attribute
https://issues.apache.org/bugzilla/show_bug.cgi?id=45089 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 45612] [Patch] Subproject Addressing and Simulation Mode
https://issues.apache.org/bugzilla/show_bug.cgi?id=45612 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 45536] JUnit PlainJUnitResultFormatter goes OOM at the end of a run
https://issues.apache.org/bugzilla/show_bug.cgi?id=45536 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 43447] Use Java 5 attributes as a replacement for XDoclet docs
https://issues.apache.org/bugzilla/show_bug.cgi?id=43447 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 43144] tar task is very slow when a zipfileset is used as the source resource
https://issues.apache.org/bugzilla/show_bug.cgi?id=43144 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 48641] ant -u url should enable ant to launch with a build.xml located on a remote server, currently ant requires build.xml to be a local file
https://issues.apache.org/bugzilla/show_bug.cgi?id=48641 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 47860] [PATCH] ftp task to provide feedback on succeeded/failed transfers
https://issues.apache.org/bugzilla/show_bug.cgi?id=47860 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 42594] add a checksummed resource which can checksum a resource
https://issues.apache.org/bugzilla/show_bug.cgi?id=42594 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 40455] ReaderInputStream handling character sets having preamples incorrect;ly
https://issues.apache.org/bugzilla/show_bug.cgi?id=40455 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 41961] StarTeam Checkout does not update case of filenames
https://issues.apache.org/bugzilla/show_bug.cgi?id=41961 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- 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 49162] incorrect duplicated project name warning when imports from URL-providing resource
https://issues.apache.org/bugzilla/show_bug.cgi?id=49162 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.8.0 |1.8.1 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
