[jira] (IVY-1197) OutOfMemoryError during ivy:publish
[ https://issues.apache.org/jira/browse/IVY-1197 ]
Maarten Coene deleted comment on IVY-1197:
was (Author: ekkara...@gmail.com):
http://ekkara...@gmail.com
> OutOfMemoryError during ivy:publish
> ---
>
> Key: IVY-1197
> URL: https://issues.apache.org/jira/browse/IVY-1197
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0
>Reporter: Michael Rumpf
>Priority: Major
> Attachments: ASF.LICENSE.NOT.GRANTED--clipboard.txt, ivylarge.zip,
> org.apache.ivy.util.url.HttpClientHandler.patch
>
>
> When publishing a large file, an OutOfMemoryError occurs.
> {code}
> [ivy:publish] published ppg to
>
> BUILD FAILED
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:152:
> The following error occurred while executing this line:
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:277:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2786)
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
> at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:168)
> at
> org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:200)
> at
> org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:140)
> at
> org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:85)
> at
> org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:219)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:282)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:261)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:170)
> at org.apache.ivy.Ivy.publish(Ivy.java:600)
> at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:299)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: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:1397)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
> at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Total time: 14 minutes 24 seconds
> Finished: FAILURE
> {code}
> The size of the file that is being uploaded is: 687712714, so around
> 650-700MB.
> The publish task is part of a Hudson Ant build where the artefacts are
> published to an Artifactory repository at the end.
> I have given the Job 1300MB for the max heap size.
> It seems as if the whole file is loaded into memory for the upload.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IVY-1197) OutOfMemoryError during ivy:publish
[
https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17620615#comment-17620615
]
Maarten Coene commented on IVY-1197:
[~andrew norman] : did you configure Ivy to use the Apache HTTP client
libraries?
> OutOfMemoryError during ivy:publish
> ---
>
> Key: IVY-1197
> URL: https://issues.apache.org/jira/browse/IVY-1197
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0
>Reporter: Michael Rumpf
>Priority: Major
> Attachments: ASF.LICENSE.NOT.GRANTED--clipboard.txt, ivylarge.zip,
> org.apache.ivy.util.url.HttpClientHandler.patch
>
>
> When publishing a large file, an OutOfMemoryError occurs.
> {code}
> [ivy:publish] published ppg to
>
> BUILD FAILED
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:152:
> The following error occurred while executing this line:
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:277:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2786)
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
> at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:168)
> at
> org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:200)
> at
> org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:140)
> at
> org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:85)
> at
> org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:219)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:282)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:261)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:170)
> at org.apache.ivy.Ivy.publish(Ivy.java:600)
> at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:299)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: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:1397)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
> at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Total time: 14 minutes 24 seconds
> Finished: FAILURE
> {code}
> The size of the file that is being uploaded is: 687712714, so around
> 650-700MB.
> The publish task is part of a Hudson Ant build where the artefacts are
> published to an Artifactory repository at the end.
> I have given the Job 1300MB for the max heap size.
> It seems as if the whole file is loaded into memory for the upload.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IVY-1638) Stop resolving dependencies when a wrong username/password is provided.
Maarten Coene created IVY-1638: -- Summary: Stop resolving dependencies when a wrong username/password is provided. Key: IVY-1638 URL: https://issues.apache.org/jira/browse/IVY-1638 Project: Ivy Issue Type: Improvement Components: Core Affects Versions: 2.5.0 Reporter: Maarten Coene When a wrong username/password is provided for some URL repository, Ivy will try this wrong combination for every module it wants to download from that repository. This can give issues on some servers (like for instance Artifactory) that lock user accounts after some failed login attempts. To prevent this from happening, it would be great if Ivy stops connecting to this server during the resolution process (for instance after a HTTP 401 response). Perhaps this should be made configurable somewhere to avoid backwards compatible issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IVY-1631) ivy:retrieve task doesn't create empty set
[ https://issues.apache.org/jira/browse/IVY-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1631. Fix Version/s: master Resolution: Fixed > ivy:retrieve task doesn't create empty set > -- > > Key: IVY-1631 > URL: https://issues.apache.org/jira/browse/IVY-1631 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.4.0, 2.5.0 >Reporter: Maarten Coene >Assignee: Maarten Coene >Priority: Major > Fix For: master > > Time Spent: 50m > Remaining Estimate: 0h > > Scenario: > * specify a setId on ivy:retrieve > * the ivy:retrieve task retrieves no files > * the target directory already contained some other files > Instead of an empty FileSet, the FileSet created by ivy:retrieve task will > contain all existing files located in that target directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IVY-1631) ivy:retrieve task doesn't create empty set
Maarten Coene created IVY-1631: -- Summary: ivy:retrieve task doesn't create empty set Key: IVY-1631 URL: https://issues.apache.org/jira/browse/IVY-1631 Project: Ivy Issue Type: Bug Affects Versions: 2.5.0, 2.4.0 Reporter: Maarten Coene Assignee: Maarten Coene Scenario: * specify a setId on ivy:retrieve * the ivy:retrieve task retrieves no files * the target directory already contained some other files Instead of an empty FileSet, the FileSet created by ivy:retrieve task will contain all existing files located in that target directory -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IVY-1293) buildlist root and leaf should support organisation specific modules
[ https://issues.apache.org/jira/browse/IVY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1293. Resolution: Fixed Fix Version/s: master Will be fixed in the next release. > buildlist root and leaf should support organisation specific modules > > > Key: IVY-1293 > URL: https://issues.apache.org/jira/browse/IVY-1293 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.2.0 >Reporter: Brice Beard >Assignee: Maarten Coene >Priority: Major > Fix For: master > > > If working with a project having multiple organisation it's impossible to > specify root or leaf module for specific organisation, this is a problem when > same module names are used by two different orgs (ie common, core, ..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IVY-1242) Ivy Buildlist Revision Support
[ https://issues.apache.org/jira/browse/IVY-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1242. Resolution: Fixed Fix Version/s: master Will be fixed in the next release > Ivy Buildlist Revision Support > -- > > Key: IVY-1242 > URL: https://issues.apache.org/jira/browse/IVY-1242 > Project: Ivy > Issue Type: New Feature > Components: Core >Affects Versions: 2.2.0 >Reporter: Ralph C >Assignee: Maarten Coene >Priority: Major > Fix For: master > > > Currently buildlist does not support revisions while filtering leafs and > roots. > The leaf and root attribute should handle specifying revisions (and even > organizations) in the form of (org#module#revision,org#module#revision,...) > and should return a list also of the form > (org#module#revision,org#module#revision,...). > This is crucial when new dependencies are introduced in new releases of a > certain project. > A use case for this is in continuous integration scripts, where a change in a > certain org1#module1#revision1 should trigger a recompilation of a dependent > org2#module2#revision2 (All other org2#module2 projects should not need > rebuilding) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IVY-1242) Ivy Buildlist Revision Support
[ https://issues.apache.org/jira/browse/IVY-1242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-1242: -- Assignee: Maarten Coene > Ivy Buildlist Revision Support > -- > > Key: IVY-1242 > URL: https://issues.apache.org/jira/browse/IVY-1242 > Project: Ivy > Issue Type: New Feature > Components: Core >Affects Versions: 2.2.0 >Reporter: Ralph C >Assignee: Maarten Coene >Priority: Major > > Currently buildlist does not support revisions while filtering leafs and > roots. > The leaf and root attribute should handle specifying revisions (and even > organizations) in the form of (org#module#revision,org#module#revision,...) > and should return a list also of the form > (org#module#revision,org#module#revision,...). > This is crucial when new dependencies are introduced in new releases of a > certain project. > A use case for this is in continuous integration scripts, where a change in a > certain org1#module1#revision1 should trigger a recompilation of a dependent > org2#module2#revision2 (All other org2#module2 projects should not need > rebuilding) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IVY-1293) buildlist root and leaf should support organisation specific modules
[ https://issues.apache.org/jira/browse/IVY-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-1293: -- Assignee: Maarten Coene > buildlist root and leaf should support organisation specific modules > > > Key: IVY-1293 > URL: https://issues.apache.org/jira/browse/IVY-1293 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.2.0 >Reporter: Brice Beard >Assignee: Maarten Coene >Priority: Major > > If working with a project having multiple organisation it's impossible to > specify root or leaf module for specific organisation, this is a problem when > same module names are used by two different orgs (ie common, core, ..) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IVY-1404) Local conflict managers in ivy.xml not working
[
https://issues.apache.org/jira/browse/IVY-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1404.
Resolution: Fixed
Assignee: Maarten Coene
Fix Version/s: master
Fixed in next release.
> Local conflict managers in ivy.xml not working
> --
>
> Key: IVY-1404
> URL: https://issues.apache.org/jira/browse/IVY-1404
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0
>Reporter: Carsten Pfeiffer
>Assignee: Maarten Coene
> Fix For: master
>
> Attachments: ivy-conflict-bug.zip
>
>
> I'm trying to retrieve the single dependency selenium-server from
> maven-central, using the default conflict manager "latest-compatible".
> This leads to an error because "xml-apis" is referenced in two different
> versions. Setting the default resolver to latest-revision indeed fixes this.
> I do not want to change the entire build to latest-revision though, so I'd
> like use the "conflict" tag in ivy.xml:
> {code}
>
> {code}
> (ideally even with org and module set).
> Alas, this doesn't work. It will use the default conflict manager anyway,
> ignoring the latest-revision manager altogether.
> {code}
> org.apache.ivy.plugins.conflict.StrictConflictException:
> xml-apis#xml-apis;1.4.01 (needed by [xerces#xercesImpl;2.10.0]) conflicts
> with xml-apis#xml-apis;1.3.04 (needed by [xalan#serializer;2.7.1])
> at
> org.apache.ivy.plugins.conflict.LatestCompatibleConflictManager.handleUnsolvableConflict(LatestCompatibleConflictManager.java:292)
> at
> org.apache.ivy.plugins.conflict.LatestCompatibleConflictManager.handleIncompatibleConflict(LatestCompatibleConflictManager.java:173)
> at
> org.apache.ivy.plugins.conflict.LatestCompatibleConflictManager.resolveConflicts(LatestCompatibleConflictManager.java:114)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolveConflicts(ResolveEngine.java:1018)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolveConflict(ResolveEngine.java:895)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolveConflict(ResolveEngine.java:945)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolveConflict(ResolveEngine.java:833)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:692)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:780)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:780)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:780)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:780)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:780)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:768)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:768)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:780)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:575)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:233)
> at
> org.apache.ivyde.eclipse.resolve.IvyResolver.doResolve(IvyResolver.java:230)
> at
> org.apache.ivyde.eclipse.resolve.IvyResolver.resolve(IvyResolver.java:137)
> at
> org.apache.ivyde.eclipse.resolve.IvyResolveJob$1.run(IvyResolveJob.java:243)
> at java.lang.Thread.run(Thread.java:662)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (IVY-1499) NullPointerException while Retrieve
[
https://issues.apache.org/jira/browse/IVY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene reassigned IVY-1499:
--
Assignee: Maarten Coene
> NullPointerException while Retrieve
> ---
>
> Key: IVY-1499
> URL: https://issues.apache.org/jira/browse/IVY-1499
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4.0-RC1
> Environment: Hard to say:
> Worked on my System: Win 7 64, Java 6u45, Eclipse Luna and Kepler with
> current Plugins (Ant, Ant Ivy, IvyDE, Ant Ivy Tasker)
> Occured on a very similar system and on my Test System with Lubuntu 14.04 64,
> OpenJDK 1.7.0_65
>Reporter: Marc Meier
>Assignee: Maarten Coene
>Priority: Minor
> Labels: NullPointerException
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I encountered a NullPointerException while retrieving an ivy file.
> Unfortunately I'm not able to recreate it properly.
> {panel:title=Stacktrace}
> BUILD FAILED
> /var/lib/jenkins/jobs/antivy/workspace/dev/all.xml:12: The following error
> occurred while executing this line:
> /var/lib/jenkins/jobs/antivy/workspace/dev/common_module_build.xml:74:
> impossible to ivy retrieve: java.lang.RuntimeException: problem during
> retrieve of org.example#org.example.converter: java.lang.NullPointerException
> at
> org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:249)
> at org.apache.ivy.Ivy.retrieve(Ivy.java:561)
> at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:98)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:271)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:440)
> at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:306)
> at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:622)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
> at org.apache.tools.ant.Main.runBuild(Main.java:851)
> at org.apache.tools.ant.Main.startAnt(Main.java:235)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109)
> Caused by: java.lang.NullPointerException
> at
> org.apache.ivy.core.IvyPatternHelper.substituteTokens(IvyPatternHelper.java:239)
> at
> org.apache.ivy.core.IvyPatternHelper.substitute(IvyPatternHelper.java:171)
> at
> org.apache.ivy.core.retrieve.RetrieveEngine.determineArtifactsToCopy(RetrieveEngine.java:355)
> at
> org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:118)
> ... 34 more
> {panel}
> The converter (which is the project I try to build) depends on the core,
> which is also one of our projects. Since we only need the core for its
> dependencies, only the ivy.xml is published in my local repository and needed
> by the converter.
> I tried to figure out, what the problem is. It seems, ivy is unable to
> determine the destPattern (RetrieveEngine.java:355) while retrieving the
> core. While debu
[jira] [Resolved] (IVY-1488) Apache IVY to Maven : Bug Excluding Artifacts?
[ https://issues.apache.org/jira/browse/IVY-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1488. Resolution: Invalid ok, this doesn't seems an issue, please reopen if you disagree. > Apache IVY to Maven : Bug Excluding Artifacts? > -- > > Key: IVY-1488 > URL: https://issues.apache.org/jira/browse/IVY-1488 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.3.0 >Reporter: Iker > Labels: ivy, ivy-module, maven, pom.xml > Original Estimate: 1h > Remaining Estimate: 1h > > I think there is a bug translating from ivy to maven "makepom" when the > excursion set of artifacts: > For example, this IVY xml : > transitive="true" conf="compile->master"> > > > > Is translated this way to POM > > org.apache.xmlgraphics > fop > 1.0 > compile > > >org.apache.xmlgraphics >* > > > > As seen, rather than exclude the artifact "batik-awt-util" , all artifacts > (*) are excluded !! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (IVY-1553) PGP signing during publication shouldn't require bouncy castle dependencies to be in .ant/lib or forking another java process with classpath explicitly configured to cont
[
https://issues.apache.org/jira/browse/IVY-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15759690#comment-15759690
]
Maarten Coene commented on IVY-1553:
"You should add these libraries to Ivy's classpath", meaning the classpath used
to load the ivy task.
You could use something like this:
Suggestions about a more clear documentation are always welcome.
> PGP signing during publication shouldn't require bouncy castle dependencies
> to be in .ant/lib or forking another java process with classpath explicitly
> configured to contain bouncy castle modules
> ---
>
> Key: IVY-1553
> URL: https://issues.apache.org/jira/browse/IVY-1553
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4.0
>Reporter: Reşat SABIQ
> Labels: pgp
>
> With
>
>password="${pgp.password}"/>
>
> in ivysettings.xml,
> ivy kept throwing CNFE until i put these dependencies in .ant/lib:
>rev="1.49" conf="default"/>
>rev="1.49" conf="default"/>
> I ended up putting the following comment in ivy.xml:
>
> P.S. I believe this issue is ongoing since 2012/13.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IVY-1482) NPE in XmlReportOutputter
[
https://issues.apache.org/jira/browse/IVY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1482.
Resolution: Fixed
Assignee: Maarten Coene
Fix Version/s: master
> NPE in XmlReportOutputter
> -
>
> Key: IVY-1482
> URL: https://issues.apache.org/jira/browse/IVY-1482
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4.0-RC1
>Reporter: M Kim
>Assignee: Maarten Coene
> Fix For: master
>
>
> {code}
> public void output(ConfigurationResolveReport report, String resolveId,
> String[] confs, ResolutionCacheManager cacheMgr) throws IOException {
> File reportFile =
> cacheMgr.getConfigurationResolveReportInCache(resolveId,
> report.getConfiguration());
> File reportParentDir = reportFile.getParentFile();
> reportParentDir.mkdirs(); // NPE
> OutputStream stream = new FileOutputStream(reportFile);
> writer.output(report, confs, stream);
> stream.close();
> //...
> }
> {code}
> In XmlReportOutputter.output method, NPE occurs when
> reportFile.getParentFile() returns null. I think a proper error handling is
> needed for reportFile and reportParentDir before OutputStream is created.
>
> {code}
> public void test1() {
> Ivy14 ivy = new org.apache.ivy.Ivy14();
> ManifestHeaderElement header = new ManifestHeaderElement();
> ModuleRevisionId resolveId = ModuleRevisionId.newInstance("", "ISO-8859-1",
> "default", "default", header.getAttributes(), true);
> Pack200Packing pack = new Pack200Packing();
> String[] strings = pack.getNames();
> ResolveReport report = ivy.resolve(resolveId, strings);
> ResolveOptions options = new ResolveOptions();
> report.output(new ReportOutputter[]{new XmlReportOutputter()},
> (ResolutionCacheManager)new DefaultResolutionCacheManager(),
> options.setResolveId("latest-revision").setOutputReport(true));
> }
> {code}
>
> {code}
> 1) test1(Test0)java.lang.NullPointerException
> at
> org.apache.ivy.plugins.report.XmlReportOutputter.output(XmlReportOutputter.java:56)
> at
> org.apache.ivy.plugins.report.XmlReportOutputter.output(XmlReportOutputter.java:47)
> at org.apache.ivy.core.report.ResolveReport.output(ResolveReport.java:106)
> at Test0.test1(Test0.java:48)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (IVY-1482) NPE in XmlReportOutputter
[
https://issues.apache.org/jira/browse/IVY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15743552#comment-15743552
]
Maarten Coene commented on IVY-1482:
I think the example and usecase are invalid.
The ResolutionCacheManager should have a basedir set.
I've updated the implementation of DefaultResolutionCacheManager to throw an
appropriate exception if this isn't the case.
Maarten
> NPE in XmlReportOutputter
> -
>
> Key: IVY-1482
> URL: https://issues.apache.org/jira/browse/IVY-1482
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4.0-RC1
>Reporter: M Kim
>
> {code}
> public void output(ConfigurationResolveReport report, String resolveId,
> String[] confs, ResolutionCacheManager cacheMgr) throws IOException {
> File reportFile =
> cacheMgr.getConfigurationResolveReportInCache(resolveId,
> report.getConfiguration());
> File reportParentDir = reportFile.getParentFile();
> reportParentDir.mkdirs(); // NPE
> OutputStream stream = new FileOutputStream(reportFile);
> writer.output(report, confs, stream);
> stream.close();
> //...
> }
> {code}
> In XmlReportOutputter.output method, NPE occurs when
> reportFile.getParentFile() returns null. I think a proper error handling is
> needed for reportFile and reportParentDir before OutputStream is created.
>
> {code}
> public void test1() {
> Ivy14 ivy = new org.apache.ivy.Ivy14();
> ManifestHeaderElement header = new ManifestHeaderElement();
> ModuleRevisionId resolveId = ModuleRevisionId.newInstance("", "ISO-8859-1",
> "default", "default", header.getAttributes(), true);
> Pack200Packing pack = new Pack200Packing();
> String[] strings = pack.getNames();
> ResolveReport report = ivy.resolve(resolveId, strings);
> ResolveOptions options = new ResolveOptions();
> report.output(new ReportOutputter[]{new XmlReportOutputter()},
> (ResolutionCacheManager)new DefaultResolutionCacheManager(),
> options.setResolveId("latest-revision").setOutputReport(true));
> }
> {code}
>
> {code}
> 1) test1(Test0)java.lang.NullPointerException
> at
> org.apache.ivy.plugins.report.XmlReportOutputter.output(XmlReportOutputter.java:56)
> at
> org.apache.ivy.plugins.report.XmlReportOutputter.output(XmlReportOutputter.java:47)
> at org.apache.ivy.core.report.ResolveReport.output(ResolveReport.java:106)
> at Test0.test1(Test0.java:48)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IVY-1444) maven tests artifacts cannot be downloaded because they are mapped to private configurations
[
https://issues.apache.org/jira/browse/IVY-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1444.
Resolution: Fixed
Assignee: Maarten Coene
Fix Version/s: master
Sorry for the late response, it will be fixed in the next release.
kind regards,
Maarten Coene
> maven tests artifacts cannot be downloaded because they are mapped to private
> configurations
>
>
> Key: IVY-1444
> URL: https://issues.apache.org/jira/browse/IVY-1444
> Project: Ivy
> Issue Type: Bug
> Components: Maven Compatibility
>Affects Versions: 2.3.0
>Reporter: subes
>Assignee: Maarten Coene
>Priority: Blocker
> Fix For: master
>
>
> To run an embedded hadoop server, one has to use hadoops test libraries since
> version 2.1.0-beta.
> Though fetching those test libraries fails with:
> {quote}
> configuration not public in xxx#yyy;2.1.0-rc2: 'test'. It was
> required from zzz#bbb;working test
> {quote}
> This is because the maven pom.xml converter creates this configuration entry:
> {quote}
> visibility="private"
> description="this scope indicates that the dependency is not
> required for normal use of the application, and is only available for the test
> compilation and execution phases."
> extends="runtime"/>
> {quote}
> This makes it impossible to download test artifacts with ivy. Then the
> question arises, why are those tests jars in the maven repos anyway?
> Is there any way how to download the actual test artifacts of maven modules?
> Maybe the pom.xml converter needs to be adjusted to generate:
> {quote}
> visibility="public"
> description="this scope indicates that the dependency is not
> required for normal use of the application, and is only available for the test
> compilation and execution phases."
> extends="runtime"/>
> {quote}
> To fix this...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IVY-1539) NullPointerException in dependencytree with no dependencies
[
https://issues.apache.org/jira/browse/IVY-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1539.
Resolution: Fixed
Assignee: Maarten Coene
Fix Version/s: master
Fixed in next release.
Thanks for reporting.
Maarten
> NullPointerException in dependencytree with no dependencies
> ---
>
> Key: IVY-1539
> URL: https://issues.apache.org/jira/browse/IVY-1539
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.4.0
>Reporter: Brett Wooldridge
>Assignee: Maarten Coene
> Fix For: master
>
>
> When running in a project with no declared
> dependencies a NPE is generated:
> {code:java}
> /Users/brettw/Documents/lvi/netld/netld/common.xml:16:
> java.lang.NullPointerException
> at
> org.apache.ivy.ant.IvyDependencyTree.printDependencies(IvyDependencyTree.java:56)
> at
> org.apache.ivy.ant.IvyDependencyTree.doExecute(IvyDependencyTree.java:52)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:271)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
> at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:441)
> at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:309)
> at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:224)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:293)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
> at org.apache.tools.ant.Task.perform(Task.java:348)
> at org.apache.tools.ant.Target.execute(Target.java:435)
> at org.apache.tools.ant.Target.performTasks(Target.java:456)
> at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1405)
> at org.apache.tools.ant.Project.executeTarget(Project.java:1376)
> at
> org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1260)
> at org.apache.tools.ant.Main.runBuild(Main.java:853)
> at org.apache.tools.ant.Main.startAnt(Main.java:235)
> at org.apache.tools.ant.launch.Launcher.run(Launcher.java:285)
> at org.apache.tools.ant.launch.Launcher.main(Launcher.java:112)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (IVY-1549) checkIfChanged is not settable attribute for checkdepsupdate ant task
[ https://issues.apache.org/jira/browse/IVY-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1549. Resolution: Fixed Assignee: Maarten Coene Fix Version/s: master Fixed in next release. Thanks for reporting! > checkIfChanged is not settable attribute for checkdepsupdate ant task > - > > Key: IVY-1549 > URL: https://issues.apache.org/jira/browse/IVY-1549 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.4.0 >Reporter: Timothy E Cronin >Assignee: Maarten Coene > Fix For: master > > > tried using the ant task and get unsupported attribute error for > checkIfChanged > looking at the source for IvyDependencyUpdateChecker there's a private member > but no getter/setter -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (IVY-1491) generate pom with /xsd/maven-4.0.0.xsd schema instead of obsolete /maven-v4_0_0.xsd
[ https://issues.apache.org/jira/browse/IVY-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-1491: -- Assignee: Maarten Coene > generate pom with /xsd/maven-4.0.0.xsd schema instead of obsolete > /maven-v4_0_0.xsd > --- > > Key: IVY-1491 > URL: https://issues.apache.org/jira/browse/IVY-1491 > Project: Ivy > Issue Type: Improvement > Components: Maven Compatibility >Affects Versions: 2.3.0, 2.4.0-RC1 >Reporter: Hervé Boutemy >Assignee: Maarten Coene > Fix For: trunk > > > see http://maven.apache.org/ref/3.2.3/maven-model/maven.html for preferred > POM structure -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (IVY-1491) generate pom with /xsd/maven-4.0.0.xsd schema instead of obsolete /maven-v4_0_0.xsd
[ https://issues.apache.org/jira/browse/IVY-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1491. Resolution: Fixed Fix Version/s: trunk Fixed in the master branch. Thanks! > generate pom with /xsd/maven-4.0.0.xsd schema instead of obsolete > /maven-v4_0_0.xsd > --- > > Key: IVY-1491 > URL: https://issues.apache.org/jira/browse/IVY-1491 > Project: Ivy > Issue Type: Improvement > Components: Maven Compatibility >Affects Versions: 2.3.0, 2.4.0-RC1 >Reporter: Hervé Boutemy > Fix For: trunk > > > see http://maven.apache.org/ref/3.2.3/maven-model/maven.html for preferred > POM structure -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (IVY-1472) Failed to resolve dependency due to extra "slash" in URL
[
https://issues.apache.org/jira/browse/IVY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1472:
---
Fix Version/s: trunk
> Failed to resolve dependency due to extra "slash" in URL
>
>
> Key: IVY-1472
> URL: https://issues.apache.org/jira/browse/IVY-1472
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4.0-RC1
> Environment: Mac OS X 10.9.2., Ivy 2.4.0-RC1, Ant 1.9.3, JDK 1.7.0_55
>Reporter: Jifeng Zhang
>Assignee: Maarten Coene
>Priority: Critical
> Fix For: trunk
>
> Attachments: IVY-1472.patch, IVY-1472.zip
>
>
> We have a self build ivy repo (basically a http server serving files, not
> maven 2 compatible) for storing in house built libraries and all 3rd party
> libs, this is how our resolver looks like:
> {code:xml}
>
>
>
>
>
> pattern="http://dev/repo/[org]/[module]/[module]-[revision]/ivy-[revision].xml";
> />
> pattern="http://dev/repo/[org]/[module]/[module]-[revision]/[artifact]-[revision].[ext]";
> />
>
>
>
>
>
>
> {code}
> We have been using ivy 2.2.0 for some time and everything works. Recently we
> tried to use ivy 2.4.0-RC1, suddenly we can not resolve the libraries using
> the version matcher, for example:
> {code:xml}
>
> {code}
> Ivy complains
> {code}
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.1/ivy-0.0.1/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.2/ivy-0.0.2/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.3/ivy-0.0.3/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.4/ivy-0.0.4/.xml
> {code}
> You can notice that there is an extra "/" after the version number, before
> the .xml extension.
> With -verbose option, I noticed that when it found revs, it output:
> {code}
> found revs: [0.0.1/, 0.0.2/, 0.0.3/, 0.0.4/]
> {code}
> When we use ivy-2.2.0, the output is:
> {code}
> found revs: [0.0.1, 0.0.2, 0.0.3, 0.0.4]
> {code}
> Further digging into source code of Ivy,
> In version 2.2.0, org.apache.ivy.plugins.resolver.util.ResolverHelper, line
> 76 uses following pattern to match and remove the tailing slash:
> {code}
> String acceptNamePattern = ".*?"+
> IvyPatternHelper.substituteToken(namePattern, token, "([^" + fileSep+ "]+)")
> + "($|" + fileSep + ".*)";
> {code}
> But in 2.4.0-RC1, line 76 , that code has been changed to:
> {code}
> namePattern = IvyPatternHelper.substituteToken(namePattern, token, "(.+)");
> {code}
> Which will fail to remove the tailing slash.
> Is this a bug or what is the background of changing the regex?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (IVY-1472) Failed to resolve dependency due to extra "slash" in URL
[
https://issues.apache.org/jira/browse/IVY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1472.
Resolution: Fixed
Thanks for the great analysis of the problem, it was a really helpfull :-)
I've committed a fix in SVN trunk for the problem, could you give it a try?
> Failed to resolve dependency due to extra "slash" in URL
>
>
> Key: IVY-1472
> URL: https://issues.apache.org/jira/browse/IVY-1472
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4.0-RC1
> Environment: Mac OS X 10.9.2., Ivy 2.4.0-RC1, Ant 1.9.3, JDK 1.7.0_55
>Reporter: Jifeng Zhang
>Assignee: Maarten Coene
>Priority: Critical
> Attachments: IVY-1472.patch, IVY-1472.zip
>
>
> We have a self build ivy repo (basically a http server serving files, not
> maven 2 compatible) for storing in house built libraries and all 3rd party
> libs, this is how our resolver looks like:
> {code:xml}
>
>
>
>
>
> pattern="http://dev/repo/[org]/[module]/[module]-[revision]/ivy-[revision].xml";
> />
> pattern="http://dev/repo/[org]/[module]/[module]-[revision]/[artifact]-[revision].[ext]";
> />
>
>
>
>
>
>
> {code}
> We have been using ivy 2.2.0 for some time and everything works. Recently we
> tried to use ivy 2.4.0-RC1, suddenly we can not resolve the libraries using
> the version matcher, for example:
> {code:xml}
>
> {code}
> Ivy complains
> {code}
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.1/ivy-0.0.1/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.2/ivy-0.0.2/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.3/ivy-0.0.3/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.4/ivy-0.0.4/.xml
> {code}
> You can notice that there is an extra "/" after the version number, before
> the .xml extension.
> With -verbose option, I noticed that when it found revs, it output:
> {code}
> found revs: [0.0.1/, 0.0.2/, 0.0.3/, 0.0.4/]
> {code}
> When we use ivy-2.2.0, the output is:
> {code}
> found revs: [0.0.1, 0.0.2, 0.0.3, 0.0.4]
> {code}
> Further digging into source code of Ivy,
> In version 2.2.0, org.apache.ivy.plugins.resolver.util.ResolverHelper, line
> 76 uses following pattern to match and remove the tailing slash:
> {code}
> String acceptNamePattern = ".*?"+
> IvyPatternHelper.substituteToken(namePattern, token, "([^" + fileSep+ "]+)")
> + "($|" + fileSep + ".*)";
> {code}
> But in 2.4.0-RC1, line 76 , that code has been changed to:
> {code}
> namePattern = IvyPatternHelper.substituteToken(namePattern, token, "(.+)");
> {code}
> Which will fail to remove the tailing slash.
> Is this a bug or what is the background of changing the regex?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (IVY-1472) Failed to resolve dependency due to extra "slash" in URL
[
https://issues.apache.org/jira/browse/IVY-1472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene reassigned IVY-1472:
--
Assignee: Maarten Coene
> Failed to resolve dependency due to extra "slash" in URL
>
>
> Key: IVY-1472
> URL: https://issues.apache.org/jira/browse/IVY-1472
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4.0-RC1
> Environment: Mac OS X 10.9.2., Ivy 2.4.0-RC1, Ant 1.9.3, JDK 1.7.0_55
>Reporter: Jifeng Zhang
>Assignee: Maarten Coene
>Priority: Critical
> Attachments: IVY-1472.patch, IVY-1472.zip
>
>
> We have a self build ivy repo (basically a http server serving files, not
> maven 2 compatible) for storing in house built libraries and all 3rd party
> libs, this is how our resolver looks like:
> {code:xml}
>
>
>
>
>
> pattern="http://dev/repo/[org]/[module]/[module]-[revision]/ivy-[revision].xml";
> />
> pattern="http://dev/repo/[org]/[module]/[module]-[revision]/[artifact]-[revision].[ext]";
> />
>
>
>
>
>
>
> {code}
> We have been using ivy 2.2.0 for some time and everything works. Recently we
> tried to use ivy 2.4.0-RC1, suddenly we can not resolve the libraries using
> the version matcher, for example:
> {code:xml}
>
> {code}
> Ivy complains
> {code}
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.1/ivy-0.0.1/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.2/ivy-0.0.2/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.3/ivy-0.0.3/.xml
> CLIENT ERROR: Not Found
> url=http://dev/repo/foo/module1/module1-0.0.4/ivy-0.0.4/.xml
> {code}
> You can notice that there is an extra "/" after the version number, before
> the .xml extension.
> With -verbose option, I noticed that when it found revs, it output:
> {code}
> found revs: [0.0.1/, 0.0.2/, 0.0.3/, 0.0.4/]
> {code}
> When we use ivy-2.2.0, the output is:
> {code}
> found revs: [0.0.1, 0.0.2, 0.0.3, 0.0.4]
> {code}
> Further digging into source code of Ivy,
> In version 2.2.0, org.apache.ivy.plugins.resolver.util.ResolverHelper, line
> 76 uses following pattern to match and remove the tailing slash:
> {code}
> String acceptNamePattern = ".*?"+
> IvyPatternHelper.substituteToken(namePattern, token, "([^" + fileSep+ "]+)")
> + "($|" + fileSep + ".*)";
> {code}
> But in 2.4.0-RC1, line 76 , that code has been changed to:
> {code}
> namePattern = IvyPatternHelper.substituteToken(namePattern, token, "(.+)");
> {code}
> Which will fail to remove the tailing slash.
> Is this a bug or what is the background of changing the regex?
> Thanks.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (IVY-1470) Transform transitive=false to wildcards exclusion
[
https://issues.apache.org/jira/browse/IVY-1470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1470.
Resolution: Fixed
Fix Version/s: trunk
Assignee: Maarten Coene
Fixed in SVN trunk, could you give it a try if possible?
> Transform transitive=false to wildcards exclusion
> -
>
> Key: IVY-1470
> URL: https://issues.apache.org/jira/browse/IVY-1470
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.4.0-RC1
>Reporter: Stevo Slavic
>Assignee: Maarten Coene
> Labels: makepom
> Fix For: trunk
>
>
> In Apache Ivy, one can declare a dependency and exclude all of its transitive
> dependencies with {{transitive}} attribute set to {{false}}. E.g. this
> feature is used a lot in Apache Zookeeer, an Ivy based build. Currently (Ivy
> 2.4.0-rc1) Maven pom file generated for such Ivy built project (e.g.
> zookeeper 3.4.6) does not reflect in any way that all transitive dependencies
> for a given dependency are excluded, even though Maven supports this feature
> (find more info on exclusions in Maven in
> [docs|http://maven.apache.org/pom.html#Exclusions] and [JIRA
> ticket|http://jira.codehaus.org/browse/MNG-3832])
> Please support in makepom task transformation from Ivy's transitive=false to
> Maven's wildcards exclusion.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (IVY-1463) Ivy refuses to download timestamped snapshot artifacts from a Nexus Pro repository
[ https://issues.apache.org/jira/browse/IVY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-1463: -- Assignee: Maarten Coene > Ivy refuses to download timestamped snapshot artifacts from a Nexus Pro > repository > -- > > Key: IVY-1463 > URL: https://issues.apache.org/jira/browse/IVY-1463 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility > Environment: Windows 7 >Reporter: David M. Karr >Assignee: Maarten Coene > Attachments: ivy-0.0.1-SNAPSHOT.xml > > > I've described my problem on StackOverflow, at: > http://stackoverflow.com/questions/21888490/ivy-wont-download-a-timestamped-snapshot-artifact-from-nexus-pro > . > I've followed all of the reasonable instructions I can find, but Ivy simply > doesn't download the artifact. It doesn't report errors, it just seems to > not try. It clearly "resolves" the artifact on the repo, but that's all. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (IVY-1463) Ivy refuses to download timestamped snapshot artifacts from a Nexus Pro repository
[ https://issues.apache.org/jira/browse/IVY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960433#comment-13960433 ] Maarten Coene commented on IVY-1463: Hi, could you also list the content of the poc-domain-module/0.0.1-SNAPSHOT directory on your maven repository? And also the content of the maven-metadata.xml (if it exists) ? Maarten > Ivy refuses to download timestamped snapshot artifacts from a Nexus Pro > repository > -- > > Key: IVY-1463 > URL: https://issues.apache.org/jira/browse/IVY-1463 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility > Environment: Windows 7 >Reporter: David M. Karr > Attachments: ivy-0.0.1-SNAPSHOT.xml > > > I've described my problem on StackOverflow, at: > http://stackoverflow.com/questions/21888490/ivy-wont-download-a-timestamped-snapshot-artifact-from-nexus-pro > . > I've followed all of the reasonable instructions I can find, but Ivy simply > doesn't download the artifact. It doesn't report errors, it just seems to > not try. It clearly "resolves" the artifact on the repo, but that's all. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (IVY-1197) OutOfMemoryError duriong ivy:publish
[
https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960367#comment-13960367
]
Maarten Coene commented on IVY-1197:
Thanks for the patch Loren, however, I don't see a real difference between your
code and the code in FileUtil.copy(instream, out, null, false) regarding
buffering the input. Could you point me where the problematic code in
FileUtil.copy is?
thanks,
Maarten
> OutOfMemoryError duriong ivy:publish
>
>
> Key: IVY-1197
> URL: https://issues.apache.org/jira/browse/IVY-1197
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0
>Reporter: Michael Rumpf
> Attachments: ASF.LICENSE.NOT.GRANTED--clipboard.txt,
> org.apache.ivy.util.url.HttpClientHandler.patch
>
>
> When publishing a large file, an OutOfMemoryError occurs.
> {code}
> [ivy:publish] published ppg to
>
> BUILD FAILED
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:152:
> The following error occurred while executing this line:
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:277:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2786)
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
> at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:168)
> at
> org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:200)
> at
> org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:140)
> at
> org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:85)
> at
> org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:219)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:282)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:261)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:170)
> at org.apache.ivy.Ivy.publish(Ivy.java:600)
> at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:299)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: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:1397)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
> at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Total time: 14 minutes 24 seconds
> Finished: FAILURE
> {code}
> The size of the file that is being uploaded is: 687712714, so around
> 650-700MB.
> The publish task is part of a Hudson Ant build where the artefacts are
> published to an Artifactory repository at the end.
> I have given the Job 1300MB for the max heap size.
> It seems as if the whole file is loaded into memory for the upload.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (IVY-1463) Ivy refuses to download timestamped snapshot artifacts from a Nexus Pro repository
[
https://issues.apache.org/jira/browse/IVY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960348#comment-13960348
]
Maarten Coene commented on IVY-1463:
Thanks.
If you take a look at that file, you'll see there is only 1 artifact with type
'bundle'.
However, your ivy:retrieve task looks like this:
{code:xml}
{code}
You limit the type to 'jar', but if you change it to
{code:xml}
{code}
the artifact should be downloaded.
Could you give it a try?
> Ivy refuses to download timestamped snapshot artifacts from a Nexus Pro
> repository
> --
>
> Key: IVY-1463
> URL: https://issues.apache.org/jira/browse/IVY-1463
> Project: Ivy
> Issue Type: Bug
> Components: Maven Compatibility
> Environment: Windows 7
>Reporter: David M. Karr
> Attachments: ivy-0.0.1-SNAPSHOT.xml
>
>
> I've described my problem on StackOverflow, at:
> http://stackoverflow.com/questions/21888490/ivy-wont-download-a-timestamped-snapshot-artifact-from-nexus-pro
> .
> I've followed all of the reasonable instructions I can find, but Ivy simply
> doesn't download the artifact. It doesn't report errors, it just seems to
> not try. It clearly "resolves" the artifact on the repo, but that's all.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (IVY-1463) Ivy refuses to download timestamped snapshot artifacts from a Nexus Pro repository
[ https://issues.apache.org/jira/browse/IVY-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13957047#comment-13957047 ] Maarten Coene commented on IVY-1463: Could you upload your \.ivy2\cache\com.att.ecom.poc\poc-domain-model\ivy-0.0.1-SNAPSHOT.xml here? > Ivy refuses to download timestamped snapshot artifacts from a Nexus Pro > repository > -- > > Key: IVY-1463 > URL: https://issues.apache.org/jira/browse/IVY-1463 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility > Environment: Windows 7 >Reporter: David M. Karr > > I've described my problem on StackOverflow, at: > http://stackoverflow.com/questions/21888490/ivy-wont-download-a-timestamped-snapshot-artifact-from-nexus-pro > . > I've followed all of the reasonable instructions I can find, but Ivy simply > doesn't download the artifact. It doesn't report errors, it just seems to > not try. It clearly "resolves" the artifact on the repo, but that's all. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (IVY-1458) Support apklib dependencies for Android projects
[
https://issues.apache.org/jira/browse/IVY-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1458.
Resolution: Not a Problem
Please remove the type attribute from your -element, that should
solve the problem.
> Support apklib dependencies for Android projects
>
>
> Key: IVY-1458
> URL: https://issues.apache.org/jira/browse/IVY-1458
> Project: Ivy
> Issue Type: Bug
>Reporter: PerfectCarl
>
> At the moment apklib dependencies are not supported.
> The following configuration:
> {code:xml}
> name="actionbarsherlock"
> org="com.actionbarsherlock"
> rev="4.4.0"
> type="apklib" />
>
> {code}
> yields the error:
> {code}
> Some projects fail to be resolved
> Impossible to resolve dependencies of
> org.androidannotations#test-otto;working@SwXXX
> unresolved dependency: com.actionbarsherlock#actionbarsherlock;4.4.0: several
> problems occurred while resolving dependency:
> com.actionbarsherlock#actionbarsherlock;4.4.0 {*=[*]}:
> java.text.ParseException: inconsistent module descriptor file found in
> 'http://repo1.maven.org/maven2/com/actionbarsherlock/actionbarsherlock/4.4.0/actionbarsherlock-4.4.0.pom':
> bad type found in
> http://repo1.maven.org/maven2/com/actionbarsherlock/actionbarsherlock/4.4.0/actionbarsherlock-4.4.0.pom:
> expected='apklib' found='null';
> java.text.ParseException: inconsistent module descriptor file found in
> 'http://repo1.maven.org/maven2/com/actionbarsherlock/actionbarsherlock/4.4.0/actionbarsherlock-4.4.0.pom':
> bad type found in
> http://repo1.maven.org/maven2/com/actionbarsherlock/actionbarsherlock/4.4.0/actionbarsherlock-4.4.0.pom:
> expected='apklib' found='null';
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (IVY-1436) Backslash in ivy.xml /ivy-module/publications/artifact/@name breaks retrieval
[
https://issues.apache.org/jira/browse/IVY-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene closed IVY-1436.
--
> Backslash in ivy.xml /ivy-module/publications/artifact/@name breaks retrieval
> -
>
> Key: IVY-1436
> URL: https://issues.apache.org/jira/browse/IVY-1436
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Jerry Maloney
> Labels: artifact, patch, retrieval, url
> Attachments: FixURLResolverUnitTests.patch, NormalizeBackslash.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I have defined a URL resolver that includes, among others, the artifact
> pattern {{ pattern="http://repo1:8081/artifactory/ext-repackaged-local/[organization]/[module]/[revision]/[type]/[artifact]-[revision].[ext]";
> />}} as well as an ivy pattern. The ivy file resolves properly, but it
> includes a published artifact with the defintion {{ name="en\PresentationUI" type="xml" ext="xml" extra:os="windows"
> conf="default"/>}}. This ivy file has been in our artifact repository for a
> long time and cannot be changed.
> My issue occurs when ivy tries to retrieve this particular artifact. It uses
> the URL
> {{http://repo1:8081/artifactory/ext-repackaged-local/com/Microsoft/ReferenceAssemblies/3.0.6920.5001/xml/en\PresentationUI-3.0.6920.5001.xml}}
> which does not resolve due to the backslash between {{en}} and
> {{PresentationUI}}.
> I propose that ivy should fix URLs like this by replacing \ with /. I already
> have a fix ready to go which I'll use in my situation, but I would like this
> change to be accepted in the project.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (IVY-1436) Backslash in ivy.xml /ivy-module/publications/artifact/@name breaks retrieval
[
https://issues.apache.org/jira/browse/IVY-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1436.
Resolution: Not A Problem
> Backslash in ivy.xml /ivy-module/publications/artifact/@name breaks retrieval
> -
>
> Key: IVY-1436
> URL: https://issues.apache.org/jira/browse/IVY-1436
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Jerry Maloney
> Labels: artifact, patch, retrieval, url
> Attachments: FixURLResolverUnitTests.patch, NormalizeBackslash.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I have defined a URL resolver that includes, among others, the artifact
> pattern {{ pattern="http://repo1:8081/artifactory/ext-repackaged-local/[organization]/[module]/[revision]/[type]/[artifact]-[revision].[ext]";
> />}} as well as an ivy pattern. The ivy file resolves properly, but it
> includes a published artifact with the defintion {{ name="en\PresentationUI" type="xml" ext="xml" extra:os="windows"
> conf="default"/>}}. This ivy file has been in our artifact repository for a
> long time and cannot be changed.
> My issue occurs when ivy tries to retrieve this particular artifact. It uses
> the URL
> {{http://repo1:8081/artifactory/ext-repackaged-local/com/Microsoft/ReferenceAssemblies/3.0.6920.5001/xml/en\PresentationUI-3.0.6920.5001.xml}}
> which does not resolve due to the backslash between {{en}} and
> {{PresentationUI}}.
> I propose that ivy should fix URLs like this by replacing \ with /. I already
> have a fix ready to go which I'll use in my situation, but I would like this
> change to be accepted in the project.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1436) Backslash in ivy.xml /ivy-module/publications/artifact/@name breaks retrieval
[
https://issues.apache.org/jira/browse/IVY-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1436:
---
Fix Version/s: (was: 2.4.0)
> Backslash in ivy.xml /ivy-module/publications/artifact/@name breaks retrieval
> -
>
> Key: IVY-1436
> URL: https://issues.apache.org/jira/browse/IVY-1436
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Jerry Maloney
> Labels: artifact, patch, retrieval, url
> Attachments: FixURLResolverUnitTests.patch, NormalizeBackslash.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I have defined a URL resolver that includes, among others, the artifact
> pattern {{ pattern="http://repo1:8081/artifactory/ext-repackaged-local/[organization]/[module]/[revision]/[type]/[artifact]-[revision].[ext]";
> />}} as well as an ivy pattern. The ivy file resolves properly, but it
> includes a published artifact with the defintion {{ name="en\PresentationUI" type="xml" ext="xml" extra:os="windows"
> conf="default"/>}}. This ivy file has been in our artifact repository for a
> long time and cannot be changed.
> My issue occurs when ivy tries to retrieve this particular artifact. It uses
> the URL
> {{http://repo1:8081/artifactory/ext-repackaged-local/com/Microsoft/ReferenceAssemblies/3.0.6920.5001/xml/en\PresentationUI-3.0.6920.5001.xml}}
> which does not resolve due to the backslash between {{en}} and
> {{PresentationUI}}.
> I propose that ivy should fix URLs like this by replacing \ with /. I already
> have a fix ready to go which I'll use in my situation, but I would like this
> change to be accepted in the project.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (IVY-1436) Backslash in ivy.xml /ivy-module/publications/artifact/@name breaks retrieval
[
https://issues.apache.org/jira/browse/IVY-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene reopened IVY-1436:
> Backslash in ivy.xml /ivy-module/publications/artifact/@name breaks retrieval
> -
>
> Key: IVY-1436
> URL: https://issues.apache.org/jira/browse/IVY-1436
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.0, 2.3.0, 2.4.0
>Reporter: Jerry Maloney
> Labels: artifact, patch, retrieval, url
> Attachments: FixURLResolverUnitTests.patch, NormalizeBackslash.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> I have defined a URL resolver that includes, among others, the artifact
> pattern {{ pattern="http://repo1:8081/artifactory/ext-repackaged-local/[organization]/[module]/[revision]/[type]/[artifact]-[revision].[ext]";
> />}} as well as an ivy pattern. The ivy file resolves properly, but it
> includes a published artifact with the defintion {{ name="en\PresentationUI" type="xml" ext="xml" extra:os="windows"
> conf="default"/>}}. This ivy file has been in our artifact repository for a
> long time and cannot be changed.
> My issue occurs when ivy tries to retrieve this particular artifact. It uses
> the URL
> {{http://repo1:8081/artifactory/ext-repackaged-local/com/Microsoft/ReferenceAssemblies/3.0.6920.5001/xml/en\PresentationUI-3.0.6920.5001.xml}}
> which does not resolve due to the backslash between {{en}} and
> {{PresentationUI}}.
> I propose that ivy should fix URLs like this by replacing \ with /. I already
> have a fix ready to go which I'll use in my situation, but I would like this
> change to be accepted in the project.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Closed] (IVY-1461) 1
[ https://issues.apache.org/jira/browse/IVY-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene closed IVY-1461. -- > 1 > - > > Key: IVY-1461 > URL: https://issues.apache.org/jira/browse/IVY-1461 > Project: Ivy > Issue Type: Improvement >Reporter: Pooyan Behnamghader >Assignee: Charles Duffy > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (IVY-1460) CLONE - SSH agent support for SSH and SFTP transports
[ https://issues.apache.org/jira/browse/IVY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reopened IVY-1460: > CLONE - SSH agent support for SSH and SFTP transports > - > > Key: IVY-1460 > URL: https://issues.apache.org/jira/browse/IVY-1460 > Project: Ivy > Issue Type: Improvement >Reporter: Pooyan Behnamghader >Assignee: Charles Duffy > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1460) CLONE - SSH agent support for SSH and SFTP transports
[ https://issues.apache.org/jira/browse/IVY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1460: --- Fix Version/s: (was: 2.4.0) > CLONE - SSH agent support for SSH and SFTP transports > - > > Key: IVY-1460 > URL: https://issues.apache.org/jira/browse/IVY-1460 > Project: Ivy > Issue Type: Improvement >Reporter: Pooyan Behnamghader >Assignee: Charles Duffy > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (IVY-1460) CLONE - SSH agent support for SSH and SFTP transports
[ https://issues.apache.org/jira/browse/IVY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1460. Resolution: Invalid > CLONE - SSH agent support for SSH and SFTP transports > - > > Key: IVY-1460 > URL: https://issues.apache.org/jira/browse/IVY-1460 > Project: Ivy > Issue Type: Improvement >Reporter: Pooyan Behnamghader >Assignee: Charles Duffy > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (IVY-1460) CLONE - SSH agent support for SSH and SFTP transports
[ https://issues.apache.org/jira/browse/IVY-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene closed IVY-1460. -- > CLONE - SSH agent support for SSH and SFTP transports > - > > Key: IVY-1460 > URL: https://issues.apache.org/jira/browse/IVY-1460 > Project: Ivy > Issue Type: Improvement >Reporter: Pooyan Behnamghader >Assignee: Charles Duffy > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1461) 1
[ https://issues.apache.org/jira/browse/IVY-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1461: --- Fix Version/s: (was: 2.4.0) > 1 > - > > Key: IVY-1461 > URL: https://issues.apache.org/jira/browse/IVY-1461 > Project: Ivy > Issue Type: Improvement >Reporter: Pooyan Behnamghader >Assignee: Charles Duffy > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (IVY-1461) 1
[ https://issues.apache.org/jira/browse/IVY-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1461. Resolution: Duplicate > 1 > - > > Key: IVY-1461 > URL: https://issues.apache.org/jira/browse/IVY-1461 > Project: Ivy > Issue Type: Improvement >Reporter: Pooyan Behnamghader >Assignee: Charles Duffy > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (IVY-1461) 1
[ https://issues.apache.org/jira/browse/IVY-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reopened IVY-1461: > 1 > - > > Key: IVY-1461 > URL: https://issues.apache.org/jira/browse/IVY-1461 > Project: Ivy > Issue Type: Improvement >Reporter: Pooyan Behnamghader >Assignee: Charles Duffy > Fix For: 2.4.0 > > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1438) ParseException when "Bundle-Description" is present in OSGI MANIFEST.MF
[
https://issues.apache.org/jira/browse/IVY-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1438:
---
Fix Version/s: (was: 2.4.0)
2.4.0-RC1
> ParseException when "Bundle-Description" is present in OSGI MANIFEST.MF
> ---
>
> Key: IVY-1438
> URL: https://issues.apache.org/jira/browse/IVY-1438
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0
>Reporter: Michael Schnell
>Assignee: Nicolas Lalevée
> Fix For: 2.4.0-RC1
>
> Attachments: javax.servlet_3.0.0.v201112011016.jar
>
>
> When a "Bundle-Description" is present in a parsed "MANIFEST.MF" file then a
> ParseException is thrown.
> *EXAMPLE* (from Eclipse 4.2.2 "plugin" Directory):
> javax.servlet_3.0.0.v201112011016.jar!/META-INF/MANIFEST.MF
> *DESCRIPTION* (from above manifest):
> Bundle-Description: glassfish javax.servlet.3.1.0.b33
> *EXCEPTION*:
> Caused by: java.text.ParseException: Expecting the end of a value or of an
> parameter name
> at
> org.apache.ivy.osgi.core.ManifestHeaderValue$ManifestHeaderParser.error(ManifestHeaderValue.java:179)
> at
> org.apache.ivy.osgi.core.ManifestHeaderValue$ManifestHeaderParser.error(ManifestHeaderValue.java:175)
> at
> org.apache.ivy.osgi.core.ManifestHeaderValue$ManifestHeaderParser.parseValueOrParameter(ManifestHeaderValue.java:218)
> at
> org.apache.ivy.osgi.core.ManifestHeaderValue$ManifestHeaderParser.parseElement(ManifestHeaderValue.java:185)
> at
> org.apache.ivy.osgi.core.ManifestHeaderValue$ManifestHeaderParser.parse(ManifestHeaderValue.java:155)
> at
> org.apache.ivy.osgi.core.ManifestHeaderValue.(ManifestHeaderValue.java:51)
> at
> org.apache.ivy.osgi.core.ManifestParser.parseManifest(ManifestParser.java:107)
> *REPRODUCE*:
> Try to create a ManifestHeaderValue like this:
> {code:java}
> new ManifestHeaderValue("glassfish javax.servlet.3.1.0.b33")
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1455) IllegalStateException w/ version overrides only when resolving for multiple confs
[
https://issues.apache.org/jira/browse/IVY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1455:
---
Fix Version/s: (was: 2.4.0)
2.4.0-RC1
> IllegalStateException w/ version overrides only when resolving for multiple
> confs
> -
>
> Key: IVY-1455
> URL: https://issues.apache.org/jira/browse/IVY-1455
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Charles Duffy
>Assignee: Charles Duffy
> Fix For: 2.4.0-RC1
>
> Attachments: IVY-1455-repro.zip
>
>
> A variant of IVY-1333 is possible with some interesting properties:
> - Mediations having an effect on resolution (presence being necessary to
> trigger the issue in question) even when no children of the descriptors to
> which they apply match their specifiers.
> - IllegalStateException only triggering when multiple confs are resolved in a
> single pass.
> See attached reproducer. Using same, the exception excerpted below is thrown:
> {code}
> [ivy:resolve] :: resolving dependencies :: reproducer#top-level;working@duffy
> [ivy:resolve] confs: [master, with-direct-dep, without-direct-dep]
> [ivy:resolve] found reproducer#phase-one;1 in testcase
> [ivy:resolve] found reproducer#phase-two;1 in testcase
> [ivy:resolve] found empty-module#empty-module;1 in testcase
> [ivy:resolve] found conflict#conflict;2 in testcase
> [ivy:resolve]
> [ivy:resolve] :: problems summary ::
> [ivy:resolve] ERRORS
> [ivy:resolve] impossible to get artifacts when data has not been loaded.
> IvyNode = conflict#conflict;1
> [ivy:resolve]
> [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> BUILD FAILED
> /home/duffy/tmp/IVY-1455-repro/build.xml:29: impossible to resolve
> dependencies:
> java.lang.IllegalStateException: impossible to get artifacts when
> data has not been loaded. IvyNode = conflict#conflict;1
> at org.apache.ivy.core.resolve.IvyNode.getArtifacts(IvyNode.java:809)
> at
> org.apache.ivy.core.resolve.IvyNode.getSelectedArtifacts(IvyNode.java:786)
> at
> org.apache.ivy.core.report.ResolveReport.setDependencies(ResolveReport.java:240)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:235)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:195)
> at org.apache.ivy.Ivy.resolve(Ivy.java:507)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1400) NullPointerException - problem while listing resources
[
https://issues.apache.org/jira/browse/IVY-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1400:
---
Fix Version/s: (was: 2.4.0)
2.4.0-RC1
> NullPointerException - problem while listing resources
> --
>
> Key: IVY-1400
> URL: https://issues.apache.org/jira/browse/IVY-1400
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Frédéric RIVIERE
>Assignee: Maarten Coene
>Priority: Minor
> Fix For: 2.4.0-RC1
>
>
> After debugging, the problem appears when using
> org.apache.ivy.util.url.HttpClientHandler (connecting jakarta commons http
> client).
> A check is missing in getURLInfo() when web server does not return
> content-type in HTTP header. Line 156,
> method.getResponseHeader("content-type") returns null so NPE occurs when
> calling getValue().
> Works fine with BasicURLHandler.
> Should be something like:
> public URLInfo getURLInfo(URL url, int timeout) {
>...
> if (checkStatusCode(url, method)) {
> HttpResponseHeader h =
> method.getResponseHeader("content-type");
> String contentType = h == null ? null : h.getValue();
> String bodyCharset =
> BasicURLHandler.getCharSetFromContentType(contentType);
> ...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1457) XmlModuleDescriptorWritter doesn't support fully extra infos elements
[
https://issues.apache.org/jira/browse/IVY-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1457:
---
Fix Version/s: (was: 2.4.0)
2.4.0-RC1
> XmlModuleDescriptorWritter doesn't support fully extra infos elements
> -
>
> Key: IVY-1457
> URL: https://issues.apache.org/jira/browse/IVY-1457
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0
>Reporter: Jean-Louis Boudart
> Fix For: 2.4.0-RC1
>
>
> Ivy supports a way to add your own elements into extends tag.
> Exemple :
> {code:xml}
> revision="0.1" status="integration" >
> module="build-std-java" revision="0.9">
> value="org.apache.easyant.example.Example"/>
> module="run-java" revision="0.9" />
>
>
> {code}
> After invoking XmlModuleDescriptorWritter.write()
> We get the following :
> {code:xml}
> module="standard-java-app"
> revision="0.1"
> status="integration"
> publication="20131231193827"
> >
>
>
>
> {code}
> We can notice a few things :
> * element is missing
> * element is missing
> * wrong identation on ending (probably due to nested elements)
> * attributes from gets wiped
> Here is the code form XmlModuleDescriptorParser.endElement() method :
> {code:java}
> else if (state == State.EXTRA_INFO) {
> getMd().addExtraInfo(qName, buffer == null ? "" :
> buffer.toString());
> buffer = null;
> state = State.INFO;
> }
> {code}
> Unfortunatly buffer doesn't contains attributes and doesn't seems to handle
> nested element.
> Here is the code writting extra infos elements from
> XmlModuleDescriptorWritter :
> {code:java}
> for (Iterator it = md.getExtraInfo().entrySet().iterator();
> it.hasNext();) {
> Map.Entry extraDescr = (Map.Entry) it.next();
> if (extraDescr.getValue() == null
> || ((String) extraDescr.getValue()).length() == 0) {
> continue;
> }
> out.print("\t\t<");
> out.print(extraDescr.getKey());
> out.print(">");
> out.print(XMLHelper.escape((String) extraDescr.getValue()));
> out.print(" out.print(extraDescr.getKey());
> out.println(">");
> }
> {code}
> Still no attributes support and all "contents" will be escaped.
> I don't know how much this feature is used by the community but fixing this
> bug could break backward compatibility.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1412) publication date provided in bad format - random failures - thread safety parsing dates
[
https://issues.apache.org/jira/browse/IVY-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1412:
---
Fix Version/s: (was: 2.4.0)
2.4.0-RC1
> publication date provided in bad format - random failures - thread safety
> parsing dates
> ---
>
> Key: IVY-1412
> URL: https://issues.apache.org/jira/browse/IVY-1412
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.3.0
> Environment: Windows
>Reporter: Martin Sillence
>Assignee: Maarten Coene
>Priority: Minor
> Fix For: 2.4.0-RC1
>
>
> The text appears to be correct and when run though test code is OK but it
> fails randomly in production.
> We are using the ant contrib concurrency foreach task.
> I think this is a threading issue:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4146524
> Can we add synchronised around this method?
> Normally rerunning the build succeeds.
> Error log is:
> [foreach] Caused by: d:\jenkins\jobs\\BuildAndPublish.xml:418:
> publication date provided in bad format. should be MMddHHmmss and not
> 20130228123237
> [foreach] at org.apache.ivy.ant.IvyTask.getPubDate(IvyTask.java:197)
> [foreach] at org.apache.ivy.ant.IvyDeliver.doExecute(IvyDeliver.java:376)
> method signature is currenty:
> protected static Date getPubDate(String date, Date def) {
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1423) Namespace revision mapping does not work bidirectionally
[ https://issues.apache.org/jira/browse/IVY-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1423: --- Fix Version/s: (was: 2.4.0) 2.4.0-RC1 > Namespace revision mapping does not work bidirectionally > > > Key: IVY-1423 > URL: https://issues.apache.org/jira/browse/IVY-1423 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Charles Duffy (Indeed.com) >Assignee: Charles Duffy > Labels: patch > Fix For: 2.4.0-RC1 > > Attachments: ivy-revision-map-fix.diff > > > Ivy's namespace src and dest operations support rev options. However, > leveraging this to remap revisions within a namespace declaration results in > errors during validation, and further errors during caching. > A demonstration of this bug (reproducer and canned output from running same) > is available at https://gist.github.com/charles-dyfis-net/5783838 > A patch which Works For Me(tm) is attached. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1421) SSH agent support for SSH and SFTP transports
[ https://issues.apache.org/jira/browse/IVY-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1421: --- Fix Version/s: (was: 2.4.0) 2.4.0-RC1 > SSH agent support for SSH and SFTP transports > - > > Key: IVY-1421 > URL: https://issues.apache.org/jira/browse/IVY-1421 > Project: Ivy > Issue Type: Improvement >Reporter: Charles Duffy (Indeed.com) >Assignee: Charles Duffy > Fix For: 2.4.0-RC1 > > Attachments: ivy-jsch-agentproxy-support-r2.diff, > ivy-jsch-agentproxy-support.diff > > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1408) Ssh Resolver doesn't work with recent Jsch versions
[
https://issues.apache.org/jira/browse/IVY-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1408:
---
Fix Version/s: (was: 2.4.0)
2.4.0-RC1
> Ssh Resolver doesn't work with recent Jsch versions
> ---
>
> Key: IVY-1408
> URL: https://issues.apache.org/jira/browse/IVY-1408
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.3.0
>Reporter: Mykhailo Delegan
>Assignee: Maarten Coene
>Priority: Minor
> Fix For: 2.4.0-RC1
>
> Attachments: IVY-1408.patch
>
>
> There is a known "issue" with the Jsch library and Java 1.7, in that it
> prompts for a kerberos username and password (which are then ignored if other
> credentials have already been supplied). This doesn't stop the Ant ssh tasks
> from working, but it does stop them from being completely automated (e.g.
> scripts invoked by a CI server like Jenkins)
> The workaround is either of two:
> # Move back to Java 1.6
> # Use old enough Jsch version (0.1.31 seems to be ok).
> Jsch author, Atsuhiko Yamanaka,
> [suggests|http://sourceforge.net/mailarchive/message.php?msg_id=29359265] to
> configure Jsch Session as following to avoid the issue:
> {code:java}
> session.setConfig("PreferredAuthentications",
> "publickey,keyboard-interactive,password");
> {code}
> The very same issue was
> [filed|https://issues.apache.org/bugzilla/show_bug.cgi?id=53437] and
> [fixed|http://svn.apache.org/viewvc?rev=1429602&view=rev] in Ant.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1405) Broken link in ivy.xml documentation
[ https://issues.apache.org/jira/browse/IVY-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1405: --- Fix Version/s: (was: 2.4.0) 2.4.0-RC1 > Broken link in ivy.xml documentation > - > > Key: IVY-1405 > URL: https://issues.apache.org/jira/browse/IVY-1405 > Project: Ivy > Issue Type: Bug > Components: Documentation >Reporter: Yanus Poluektovich >Assignee: Maarten Coene >Priority: Minor > Fix For: 2.4.0-RC1 > > > Page > http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html > Section "Artifact restriction" > There is a link named "dependency artifact restriction" to > "#dependency-artifact", but there is no such anchor on that page. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1454) OverlappingFileLockException when using artifact-lock-nio
[
https://issues.apache.org/jira/browse/IVY-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1454:
---
Fix Version/s: (was: 2.4.0)
2.4.0-RC1
> OverlappingFileLockException when using artifact-lock-nio
> -
>
> Key: IVY-1454
> URL: https://issues.apache.org/jira/browse/IVY-1454
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.4.0
> Environment: Debian Linux (Wheezy)
> Oracle Java 1.7.0+update45,
> ivy_2.4.0.alpha_20131214174343.jar downloaded from
> https://builds.apache.org/job/Ivy/446/
>Reporter: Carsten Pfeiffer
>Assignee: Charles Duffy
>Priority: Minor
> Fix For: 2.4.0-RC1
>
> Attachments: IVY-1454-r3.patch, test--IVY-1454.zip
>
>
> When trying to use {{artifact-lock-nio}} as the lock strategy, I get resolve
> errors due to {{OverlappingFileLockException}} being thrown:
> {code}
> [ivy:resolve] WARN: :: org.hamcrest#hamcrest-core;1.1:
> java.nio.channels.OverlappingFileLockException at
> sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> [ivy:resolve] WARN: :: org.glassfish#javax.ejb;3.1:
> java.nio.channels.OverlappingFileLockException at
> sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> [ivy:resolve] WARN: :: org.jboss.weld.se#weld-se-core;1.1.10.Final:
> java.nio.channels.OverlappingFileLockException at
> sun.nio.ch.SharedFileLockTable.checkList(FileLockTable.java:255)
> {code}
> The reason is probably related to our use of the {{}} and
> {{}} tasks. The documentation of the {{antcallback}} task
> is here: http://ant-contrib.sourceforge.net/tasks/tasks/antcallback_task.html
> {code}
>
>
>
>
>
> {code}
> All the testxxx targets perform a resolve before running some junit tests in
> a separate vm. These resolve calls appear to cause the
> {{OverlappingFileLockException}}.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1374) ssh connection sometimes fails
[ https://issues.apache.org/jira/browse/IVY-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1374: --- Fix Version/s: (was: 2.4.0) 2.4.0-RC1 > ssh connection sometimes fails > -- > > Key: IVY-1374 > URL: https://issues.apache.org/jira/browse/IVY-1374 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.3.0-RC1 > Environment: ubuntu 12.04, jdk7.06/32bits, jenkins, jsch 0.1.84, > "OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012" >Reporter: Simon IJskes >Assignee: Maarten Coene >Priority: Minor > Fix For: 2.4.0-RC1 > > > when the sftp resolver connects to a remote repository, it sometimes fails to > fetch the artifacts. > This is accompanied by a log entry in the /var/log/auth.log on the server > side: > Aug 30 10:36:02 zzz sshd[1371]: Received disconnect from zzz.zzz.zzz.zzz: 3: > com.jcraft.jsch.JSchException: verify: false [preauth] -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1426) Display dependency updates
[ https://issues.apache.org/jira/browse/IVY-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1426: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > Display dependency updates > -- > > Key: IVY-1426 > URL: https://issues.apache.org/jira/browse/IVY-1426 > Project: Ivy > Issue Type: New Feature >Reporter: Jean-Louis Boudart > Fix For: 2.4.0-RC1 > > > Add a new ant task to see dependency updates. > The task try to resolve all libs with a configurable revision > (latest.integration) by default and log : > * dependency updates > * new transitive dependencies > * missing transitive dependencies (in case you upgrade a dependency and one > of it's dependency disappear you rely on a new version) > The task will be a post resolve task [1], so all commons attributes would be > available including inline="true". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1392) Optional ivysettings directives
[ https://issues.apache.org/jira/browse/IVY-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1392: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > Optional ivysettings directives > - > > Key: IVY-1392 > URL: https://issues.apache.org/jira/browse/IVY-1392 > Project: Ivy > Issue Type: Improvement > Components: Core >Reporter: Yanus Poluektovich >Assignee: Maarten Coene >Priority: Minor > Fix For: 2.4.0-RC1 > > Attachments: optional-include.patch > > > To allow for VCS-friendly customization of dependency resolution process, a > feature that allows for files referenced in an directive of an > ivysettings.xml file to be missing without it triggering an error. > With such a feature, it would be possible to write a global ivysettings.xml > file that references a default setup of resolvers/repositories for a project, > commit it into a VCS and then never edit it. Instead, an "optional include" > directive will point to a file with standardized name, say, > ivysettings-local.xml. The file may be missing (which results in the > project-default configuration being used), or a developer can create such a > file and define an alternative resolution configuration for his own use. The > VCS can be configured to ignore the ivysettings-local.xml file, thus > absolving the developer of the need to ensure manually at each check-in that > the file is not committed into the VCS. > Currently, a similar feature is implemented for properties files. > Unfortunately, it is impossible to, for example, override a project-default > resolver with a user-specific one only via use of properties. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1344) Buildnumber Ant task should honour defaultBranch setting
[ https://issues.apache.org/jira/browse/IVY-1344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1344: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > Buildnumber Ant task should honour defaultBranch setting > > > Key: IVY-1344 > URL: https://issues.apache.org/jira/browse/IVY-1344 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.3.0-RC1 >Reporter: Ales Nosek >Assignee: Nicolas Lalevée >Priority: Minor > Labels: patch > Fix For: 2.3.0-RC2, 2.4.0-RC1 > > Attachments: ivybuildnumber.patch > > > During reading the Ivy source code, I stumbled on this possible issue. > Please, see the attached patch. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1367) Support Conditional Setting of a Property
[ https://issues.apache.org/jira/browse/IVY-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1367: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > Support Conditional Setting of a Property > - > > Key: IVY-1367 > URL: https://issues.apache.org/jira/browse/IVY-1367 > Project: Ivy > Issue Type: New Feature > Components: Core >Affects Versions: 2.2.0 >Reporter: J.C. Hamlin >Assignee: Nicolas Lalevée >Priority: Minor > Fix For: 2.4.0-RC1 > > > Please allow a way to make conditional use of environment variables in > ivysettings.xml. If the environment variable is set, then set the property, > otherwise, don't set the property. This can be generalized into a general > test to set a property only if another property is set. > Something like this, where the "ifset" is the new attribute of the property > element. > >override="false" ifset="env.IVY_SERVER" /> > http://ivy:8081"; override="false"/> > In ant, you do something like this, which is very similar (but more verbose): > > > > http://ivy:8081"/> > So, if a user defines an environment variable it will override the default > value provided by the system. And if the environment variable is not defined > in the environment, then the system default value can apply. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1060) ApacheURLLister.retrieveListing() fails if the encoding of the URL list is different from the default encoding
[
https://issues.apache.org/jira/browse/IVY-1060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1060:
---
Fix Version/s: (was: trunk)
2.4.0-RC1
> ApacheURLLister.retrieveListing() fails if the encoding of the URL list is
> different from the default encoding
> --
>
> Key: IVY-1060
> URL: https://issues.apache.org/jira/browse/IVY-1060
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0, 2.1.0, 2.3.0-RC1
> Environment: OS: z/OS 1.9
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build pmz3160sr3-20081108_01(SR3))
>Reporter: Robin Fernandes
>Assignee: Nicolas Lalevée
> Labels: patch
> Fix For: 2.3.0-RC2, 2.4.0-RC1
>
> Attachments: patch.ivy.URLListerEncoding.diff
>
>
> ApacheURLLister.retrieveListing() assumes that the list of URLs is encoded in
> the same encoding as the system's default encoding.
> The problematic code is:
> {code}
> BufferedReader r = new BufferedReader(new
> InputStreamReader(URLHandlerRegistry.getDefault().openStream(url)));
> String htmlText = FileUtil.readEntirely(r);
> {code}
> FileUtil.readEntirely() converts the the content of the BufferedReader r to a
> String. Because no encoding is specified in the InputStreamReader
> constructor, the default encoding is used. If the default encoding does not
> match the actual encoding of the data read from url, htmlText ends up as a
> garbage String and the URL pattern matcher fails.
> This causes an issue on z/OS, where the default encoding is EBCDIC (e.g.
> IBM-1047) but the data containing the list of URLs is typically retrieved
> from the network as ASCII (ISO-8559-1).
> A workaround could be to specify the system property
> -Dfile.encoding=ISO-8559-1 on the command line, but this is a bit of a big
> hammer. In particular, it is not suitable when Ivy is used within an
> application where we don't to assume all input is ISO-8559-1.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1359) ivy.xml extends feature complains about Windows filesystem path
[
https://issues.apache.org/jira/browse/IVY-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1359:
---
Fix Version/s: (was: trunk)
2.4.0-RC1
> ivy.xml extends feature complains about Windows filesystem path
> ---
>
> Key: IVY-1359
> URL: https://issues.apache.org/jira/browse/IVY-1359
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0-RC1
> Environment: Windows, Ant 1.7.1 (but should be the same on Ant 1.8.3)
>Reporter: Mitch Gitman
>Assignee: Nicolas Lalevée
> Fix For: 2.3.0-RC2, 2.4.0-RC1
>
> Attachments: ivy-2.3.x.patch, ivy-trunk.patch
>
>
> I'm trying to use the parent Ivy module feature through the
> /ivy-module/info/extends element:
>
> revision="1.0-SNAPSHOT"
> location="${env.MASTER_PARENT_PROJECT_DIR}/ivy.xml"
> extendType="configurations" />
>
> The property placeholder in the location attribute translates to an absolute
> filesystem path. This works in a functional sense. However, I'm seeing the
> following false-positive warning message, apparently because I'm using a
> Windows filesystem path:
> [ivy:resolve] :: problems summary ::
> [ivy:resolve] WARNINGS
> [ivy:resolve] Unable to parse included ivy file
> C:\...\master-parent/ivy.xml: unknown protocol: c
> [ivy:resolve]
> [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
>
> Here's the passage in XmlModuleDescriptorParser where this is arising:
> //check on filesystem based on location attribute (for dev ONLY)
> try {
> checkParentModuleOnFilesystem(location);
> } catch (IOException e) {
> Message.warn("Unable to parse included ivy file " + location
> + ": "
> + e.getMessage());
> }
>
> I hope people can agree that showing users a misleading warning message every
> time they do an ivy:resolve is a bug worth resolving before there's a final
> 2.3.0 release.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1252) symlinkmass feature based on symlink feature of ivy:retrieve
[ https://issues.apache.org/jira/browse/IVY-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1252: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > symlinkmass feature based on symlink feature of ivy:retrieve > > > Key: IVY-1252 > URL: https://issues.apache.org/jira/browse/IVY-1252 > Project: Ivy > Issue Type: New Feature > Components: Ant, Core, Documentation >Affects Versions: 2.2.0 > Environment: UNIX/Linux >Reporter: Gene Smith >Assignee: Nicolas Lalevée >Priority: Minor > Labels: patch > Fix For: 2.4.0-RC1 > > Attachments: apache-ivy-2.2.0-src-for-symlinkmass.tar, > ivy-docs-update-text.txt > > Original Estimate: 2h > Remaining Estimate: 2h > > I have an improvement I have made in a locally built copy of Ivy, to speed up > the making of symbolic links when retrieving dependencies. It was written > based on: > apache-ivy-2.2.0-src.tar.gz > It changes existing files, but creates no new files. I have already made and > am using the change in our local build system, and want to contribute back so > that others can use it. > > The documentation for this feature would be added to: > http://ant.apache.org/ivy/history/latest-milestone/use/retrieve.html > in the main table: > Attribute > symlinkmass > Description > true to create symbolic links in mass, false to copy the artifacts. > symlinkmass overrides "symlink" if both are set to "true". > symlinkmass will create the same symbolic links "symlink" does, > but with a single process call to "sh" with batched "ln" commands > passed in as standard input. > (works on UNIX/Linux, on other systems you may need to script it) > Far large lists of resolved jars, this can be dramatically faster. > The destination of the symbolic links depends on the value of the > useOrigin attribute > The events "StartRetrieveArtifactEvent" and EndRetrieveEvent, > are NOT fired by this activity, because it is not clear when they > should be called. > Required > No. Defaults to false > > Non trivial code changes are made in: > apache-ivy-2.2.0/src/java/org/apache/ivy/core/retrieve/RetrieveEngine.java > branching in the code based on the "symlinkmass" boolean > in existing retrieval loop (where fetching of files would > normally occur) to collect destination and source paths > and after the loop to do the mass fetch > import added for java.util.HashMap > A non trivial method is added to handle linking of files based on a Map of > destinations and sources. Existing methods are untouched. > apache-ivy-2.2.0/src/java/org/apache/ivy/util/FileUtil.java > a method to do the symlinking based of a Map of the destinations to > sources > imports added for java.util.Iterator, java.util.LinkedList, > java.util.Map, java.util.regex.Pattern > Trivial additions are made to pass the control parameter "symlinkmass" > > apache-ivy-2.2.0/src/java/org/apache/ivy/core/retrieve/RetrieveOptions.java > apache-ivy-2.2.0/src/java/org/apache/ivy/ant/IvyRetrieve.java > apache-ivy-2.2.0/src/java/org/apache/ivy/Main.java > A unit test is added in > apache-ivy-2.2.0/test/java/org/apache/ivy/core/retrieve/RetrieveTest.java > basically a duplicate of the unit test for "symlink" with a few > internal code comments > ... > Notes on why we want this: > The build system I maintain (Ant + Ivy, with Linux scripts for Developer > support) was using the "symlink" feature for ivy:retrieve, because over a > complete build of our code modules (about 25 separate and growing) the > sub-builds make a total of about 3000 dependency links and the file space > savings made it complete worth it. The build system is not about speed. It > is about modularity, and we use Ivy to link the modules in a dependency tree > so that we can swap them out as we . We like Ivy very much for that. Thank > you all. > But, while speed is a secondary consideration, it is not unimportant... and > this improvement cuts about 8 minutes off an 18 minute build. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1364) buildlist task chokes on absolute path to parent Ivy module
[ https://issues.apache.org/jira/browse/IVY-1364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1364: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > buildlist task chokes on absolute path to parent Ivy module > --- > > Key: IVY-1364 > URL: https://issues.apache.org/jira/browse/IVY-1364 > Project: Ivy > Issue Type: Bug > Components: Ant, Core >Affects Versions: 2.2.0, 2.3.0-RC1 > Environment: Ant 1.7.1 (should be reproducible on Ant 1.8.3) >Reporter: Mitch Gitman >Assignee: Nicolas Lalevée > Labels: patch, testcase > Fix For: 2.3.0-RC2, 2.4.0-RC1 > > Attachments: BuildlistAndExtendsIntegrationTest.zip, > IVY-1364-2.3.x.patch, IVY-1364-trunk.patch, ivy-2.3.x.patch, ivy-trunk.patch > > > The ivy:buildlist Ant task is erroring when it encounters an absolute path to > a parent Ivy module specified in the /ivy-module/info/extends element's > location attribute. This problem is not unique to Ivy 2.3.0-rc1; I've seen it > in Ivy 2.2.0. > I can verify that the parent ivy.xml file is there at the specified path. If > I specify a relative path to the parent ivy.xml, buildlist works. > In my test case, which I explain shortly, an absolute path for the extends > attribute produces this error: > ...\testAbsolutePathToParent\multimodule-build\build.xml:28: impossible to > parse ivy file for ...\testAbsolutePathToParent\croatia\build.xml: > ivyfile=...\testAbsolutePathToParent\croatia\ivy.xml > exception=java.text.ParseException: Problem occurred while parsing ivy file: > null in file:/.../testAbsolutePathToParent/croatia/ivy.xml > at org.apache.ivy.ant.IvyBuildList.doExecute(IvyBuildList.java:215) > at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277) > ... > Caused by: java.text.ParseException: Problem occurred while parsing ivy file: > null in file:/.../testAbsolutePathToParent/croatia/ivy.xml > at > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parse(XmlModuleDescriptorParser.java:301) > at > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser.parseDescriptor(XmlModuleDescriptorParser.java:116) > at > org.apache.ivy.plugins.parser.ModuleDescriptorParserRegistry.parseDescriptor(ModuleDescriptorParserRegistry.java:88) > at > org.apache.ivy.plugins.parser.AbstractModuleDescriptorParser.parseDescriptor(AbstractModuleDescriptorParser.java:48) > at org.apache.ivy.ant.IvyBuildList.doExecute(IvyBuildList.java:207) > ... 35 more > Caused by: org.xml.sax.SAXException: Problem occurred while parsing ivy file: > null > ... > --- Nested Exception --- > java.text.ParseException: Problem occurred while parsing ivy file: null in > file:/.../testAbsolutePathToParent/croatia/ivy.xml > at > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parse(XmlModuleDescriptorParser.java:301) > at > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser.parseDescriptor(XmlModuleDescriptorParser.java:116) > at > org.apache.ivy.plugins.parser.ModuleDescriptorParserRegistry.parseDescriptor(ModuleDescriptorParserRegistry.java:88) > ... > Caused by: org.xml.sax.SAXException: Problem occurred while parsing ivy file: > null > java.lang.NullPointerException > at > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.startElement(XmlModuleDescriptorParser.java:386) > at > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:506) > ... > Caused by: java.lang.NullPointerException > at > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parseOtherIvyFile(XmlModuleDescriptorParser.java:659) > at > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.extendsStarted(XmlModuleDescriptorParser.java:443) > at > org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.startElement(XmlModuleDescriptorParser.java:327) > ... 57 more > This is what occurs when the haltOnError attribute is set to "true" on > ivy:buildlist. If I set haltOnError="false" in my test case, the exception > goes away, but I see the following build order: > 1. croatia > 2. germany > 3. ireland > 4. bootstrap-parent > 5. master-parent > What's wrong about this build order is that germany depends on ireland and > croatia depends on master-parent, in addition to extending it, and yet > germany comes before ireland and croatia comes before master-parent. > The roughly correct build order, as exhibited with a relative path to the > parent, is: > 1. bootstrap-parent > 2. master-parent > 3. croatia > 4. ireland > 5. germany > So, in addition to being incorrect, this behavior is just plain inconsistent. > TEST CASE INSTRUCTIONS: >
[jira] [Updated] (IVY-1441) Embedded Ivy fails to parse ivy-settings.xml file if it contains element
[
https://issues.apache.org/jira/browse/IVY-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1441:
---
Fix Version/s: (was: trunk)
2.4.0-RC1
> Embedded Ivy fails to parse ivy-settings.xml file if it contains element
> --
>
> Key: IVY-1441
> URL: https://issues.apache.org/jira/browse/IVY-1441
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Gregory Amerson
>Assignee: Nicolas Lalevée
> Fix For: 2.4.0-RC1
>
> Attachments: ivy-error.txt
>
>
> I've got a Eclipse java project where I have a ivy.xml and ivy-settings.xml
> added and I'm configuring a Ivy container that I'm pointing to the
> ivy-settings.xml file. The problem is that inside the ivy-settings.xml there
> is an element like this:
> password="${pgp.passphrase}" />
> When the IvyDE plugin loads the embedded Ivy runtime from the OSGi bundle and
> have it parse the ivy-settings.xml file it will throw NoClassDefFound when it
> hits the element. See attached log file for error.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1431) Also copy original metadata artifact (e.g. POM) on ivy:install
[ https://issues.apache.org/jira/browse/IVY-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1431: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > Also copy original metadata artifact (e.g. POM) on ivy:install > -- > > Key: IVY-1431 > URL: https://issues.apache.org/jira/browse/IVY-1431 > Project: Ivy > Issue Type: Improvement >Reporter: Erwin Tratar >Assignee: Nicolas Lalevée >Priority: Minor > Labels: patch > Fix For: 2.4.0-RC1 > > Attachments: ivy-1431.patch, ivy-install-pom.patch > > > Suppose you provide some module, which you are developing with Ivy and that > has external dependencies (or even worse: non publically available > dependencies). Then you might want to publish the module plus all > dependencies to a filesystem repository, which then can be redistributed and > which is usable for offline builds. > So far, no problem. But if you do not want to or even can't force your > consumers to use Ivy, then while you can create this "offline repository" in > Maven layout, it still is not usable with Maven because the POMs of all your > dependencies are missing. While Ivy remembers them (*.orig Files), they are > not used. > The attached patch will copy the cached original metadata in the install > operation if it's type ends in ".original". Also, the restoring of the > OriginArtifact from the Cache is modified to actually restore the > OriginArtifact's orignal Artifact correctly. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1288) Exposing some parent metadata (organisation, module, revision, branch) as properties.
[ https://issues.apache.org/jira/browse/IVY-1288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1288: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > Exposing some parent metadata (organisation, module, revision, branch) as > properties. > - > > Key: IVY-1288 > URL: https://issues.apache.org/jira/browse/IVY-1288 > Project: Ivy > Issue Type: New Feature > Components: Core >Reporter: Jean-Louis Boudart >Assignee: Nicolas Lalevée > Labels: patch > Fix For: 2.4.0-RC1 > > Attachments: IVY-1288-alternative.patch, IVY-1288.patch > > > It can be helpful to expose some parent metadata as properties. As module > inheritance support multiple parent we should have something like : > * ivy.parents.count : number of parents module > * ivy.parent[index].organisation : set to the organisation name found in the > parent ivyfile which was used for resolve > * ivy.parent[index].module : set to the module name found in the parent > ivyfile which was used for resolve > * ivy.parent[index].revision : set to the revision name found in the parent > ivyfile which was used for resolve > * ivy.parent[index].branch : set to the branch name found in the parent > ivyfile which was used for resolve > Where index represent the index of extends module. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (IVY-1343) NullPointerExeption in AbstractOSGiResolver
[
https://issues.apache.org/jira/browse/IVY-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1343:
---
Fix Version/s: (was: trunk)
2.4.0-RC1
> NullPointerExeption in AbstractOSGiResolver
> ---
>
> Key: IVY-1343
> URL: https://issues.apache.org/jira/browse/IVY-1343
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0-RC1
> Environment: Ubuntu 2.6.32-25-generic-pae,
> java version "1.6.0_26"
> Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
> Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
> Apache Ant version 1.8.0 compiled on April 9 2010
>Reporter: Thomas Kurpick
>Assignee: Nicolas Lalevée
>Priority: Critical
> Labels: patch
> Fix For: 2.3.0-RC2, 2.4.0-RC1
>
> Attachments: UpdateSiteAndIbiblioResolverTest.java, patch.txt
>
>
> A NullPointerException is thrown, if I try to resolve a dependency after I
> cleared the cache.
> Steps to reproduce:
> 1. create a ivysettings.xml with a chain including a ibiblio and an
> updatesite as resolver.
> 2. create a dependency to a artifact that can be found with the ibiblio
> resolver.
> 3. call ivy retrieve
> actual result:
> - no dependency is resolved and retrieved and a NullPointerException is
> thrown
> expected result:
> - dependency is resolved and retrieved from ibiblio
> See also the attached patch and test case.
> ---
> problem occurred while resolving dependency: org.mod4j.com.ibm#icu;4.0.1
> {compile=[*, !sources, !javadoc]} with p2-repos:
> java.lang.NullPointerException
> at
> org.apache.ivy.osgi.repo.AbstractOSGiResolver.findIvyFileRef(AbstractOSGiResolver.java:132)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:228)
> at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
> at org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:169)
> at org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:292)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:695)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:780)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:703)
> at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:575)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:233)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:194)
> at org.apache.ivy.Ivy.resolve(Ivy.java:503)
> at org.apache.ivy.Main.run(Main.java:270)
> at org.apache.ivy.Main.main(Main.java:179)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1353) It appears that the ignore circular dependency strategy is clobbering the warn strategy
[
https://issues.apache.org/jira/browse/IVY-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1353:
---
Fix Version/s: (was: trunk)
2.4.0-RC1
> It appears that the ignore circular dependency strategy is clobbering the
> warn strategy
> ---
>
> Key: IVY-1353
> URL: https://issues.apache.org/jira/browse/IVY-1353
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0-RC1
>Reporter: Carl Quinn
>Assignee: Nicolas Lalevée
>Priority: Critical
> Labels: patch
> Fix For: 2.3.0-RC2, 2.4.0-RC1
>
>
> In org.apache.ivy.plugins.circular the IgnoreCircularDependencyStrategy class
> has this constructor:
> {code}
> private IgnoreCircularDependencyStrategy() {
> super("warn");
> }
> {code}
> Thus is claiming to be the warn strategy and then clobbers the real warn
> strategy when it is registered in
> IvySettings.configureDefaultCircularDependencyStrategies()
> I think the fix is to just change the above string to "ignore", so:
> {code}
> private IgnoreCircularDependencyStrategy() {
> super("ignore");
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (IVY-1424) NIO FileLocker releases locks while still within tryLock() call
[ https://issues.apache.org/jira/browse/IVY-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1424: --- Fix Version/s: (was: trunk) 2.4.0-RC1 > NIO FileLocker releases locks while still within tryLock() call > --- > > Key: IVY-1424 > URL: https://issues.apache.org/jira/browse/IVY-1424 > Project: Ivy > Issue Type: Bug >Reporter: Charles Duffy (Indeed.com) >Assignee: Maarten Coene > Labels: patch > Fix For: 2.4.0-RC1 > > Attachments: ivy-nio-locker-as-option.diff, ivy-nio-locker-fix.diff > > > The notes about NIOFileLocker being deprecated due to unreliability have an > obvious cause -- locks it grabs have already been released before the tryLock > method has even exited due to the finally block closing the file descriptor > on which the lock is held! > (flock() or fcntl()-based locks, into one of which categories those created > by NIO fall on modern Unixlike operating systems, are implicitly closed > whenever the file handle on which they're held exits. This is highly > desirable behavior, because it means that a lock is implicitly cleared on > unclean shutdown of any sort -- power failure, SIGKILL to the JVM, etc; this > behavior is also perhaps the primary reason to prefer NIO locks to the > approach taken by CreateFileLocker). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (IVY-1424) NIO FileLocker releases locks while still within tryLock() call
[ https://issues.apache.org/jira/browse/IVY-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1424. Resolution: Fixed Fix Version/s: trunk Sorry for the late response. I've fixed this in SVN trunk based on your patch. Thanks a lot! Maarten > NIO FileLocker releases locks while still within tryLock() call > --- > > Key: IVY-1424 > URL: https://issues.apache.org/jira/browse/IVY-1424 > Project: Ivy > Issue Type: Bug >Reporter: Charles Duffy (Indeed.com) >Assignee: Maarten Coene > Labels: patch > Fix For: trunk > > Attachments: ivy-nio-locker-as-option.diff, ivy-nio-locker-fix.diff > > > The notes about NIOFileLocker being deprecated due to unreliability have an > obvious cause -- locks it grabs have already been released before the tryLock > method has even exited due to the finally block closing the file descriptor > on which the lock is held! > (flock() or fcntl()-based locks, into one of which categories those created > by NIO fall on modern Unixlike operating systems, are implicitly closed > whenever the file handle on which they're held exits. This is highly > desirable behavior, because it means that a lock is implicitly cleared on > unclean shutdown of any sort -- power failure, SIGKILL to the JVM, etc; this > behavior is also perhaps the primary reason to prefer NIO locks to the > approach taken by CreateFileLocker). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (IVY-1421) SSH agent support for SSH and SFTP transports
[ https://issues.apache.org/jira/browse/IVY-1421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-1421: -- Assignee: Maarten Coene > SSH agent support for SSH and SFTP transports > - > > Key: IVY-1421 > URL: https://issues.apache.org/jira/browse/IVY-1421 > Project: Ivy > Issue Type: Improvement >Reporter: Charles Duffy (Indeed.com) >Assignee: Maarten Coene > Attachments: ivy-jsch-agentproxy-support.diff, > ivy-jsch-agentproxy-support-r2.diff > > > At present, Ivy is unable to leverage agent support to access SSH keys > unlocked and stored in memory. For sites using encrypted RSA keys, requiring > additional user intervention when those keys are already decrypted and stored > in non-pageable memory is unfortunate. > This support is available using companion libraries from the author of Jsch; > I have a patch adding it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (IVY-735) Timeout should be able to be specified
[ https://issues.apache.org/jira/browse/IVY-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-735: - Assignee: Maarten Coene > Timeout should be able to be specified > -- > > Key: IVY-735 > URL: https://issues.apache.org/jira/browse/IVY-735 > Project: Ivy > Issue Type: Improvement > Components: Core >Affects Versions: 2.0.0-beta-1 >Reporter: Nat >Assignee: Maarten Coene > > It's currently not possible to provide timeout for resolver. For example, > yesterday ibiblio is really slow. I waited almost forever just to know that > there is something wrong with ibiblio. It would be nice if I can specify > timeout so that i can fail over to some other resolvers in my chain resolver. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (IVY-1221) ivy won't resolve updated maven SNAPSHOT artifacts with classifiers from local repo
[
https://issues.apache.org/jira/browse/IVY-1221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene reassigned IVY-1221:
--
Assignee: Maarten Coene
> ivy won't resolve updated maven SNAPSHOT artifacts with classifiers from
> local repo
> ---
>
> Key: IVY-1221
> URL: https://issues.apache.org/jira/browse/IVY-1221
> Project: Ivy
> Issue Type: Bug
> Components: Maven Compatibility
>Affects Versions: 2.2.0-RC1
> Environment: Mac OS X 10.6, Ant 1.7.1, Maven 2.2.1
>Reporter: Nick Bonatsakis
>Assignee: Maarten Coene
> Labels: patch
> Attachments: fix3.patch
>
>
> The situation I'm running into is as follows: I have a maven project that
> produces two artifacts foo-SNAPSHOT.jar and foo-SNAPSHOT-tests.jar. When I
> resolve these via ivy, they are both pulled properly initially, however with
> the following ivysettings ibiblio, only the foo-SNAPSHOTS.jar is getting
> updated on resolve after re-installing via maven.
> m2compatible="true"
> usepoms="true"
> changingPattern=".*-SNAPSHOT.*"
> changingMatcher="regexp"
> checkmodified="true"
> root="${localm2repo.url}"/>
> I started out trying the pattern ".*-SNAPSHOT" which I would have expected to
> pick up the tests jar, but tried this in the hopes of getting it to work,
> which of course it did not. This doesn't seem to be a retrieve issue either,
> the modified date of the foo-SNAPSHOT.jar in the local ivy cache is being
> updated while foo-SNAPSHOT-test.jar is not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (IVY-1423) Namespace revision mapping does not work bidirectionally
[ https://issues.apache.org/jira/browse/IVY-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-1423: -- Assignee: Maarten Coene > Namespace revision mapping does not work bidirectionally > > > Key: IVY-1423 > URL: https://issues.apache.org/jira/browse/IVY-1423 > Project: Ivy > Issue Type: Bug > Components: Core >Reporter: Charles Duffy (Indeed.com) >Assignee: Maarten Coene > Labels: patch > Attachments: ivy-revision-map-fix.diff > > > Ivy's namespace src and dest operations support rev options. However, > leveraging this to remap revisions within a namespace declaration results in > errors during validation, and further errors during caching. > A demonstration of this bug (reproducer and canned output from running same) > is available at https://gist.github.com/charles-dyfis-net/5783838 > A patch which Works For Me(tm) is attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (IVY-1424) NIO FileLocker releases locks while still within tryLock() call
[ https://issues.apache.org/jira/browse/IVY-1424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-1424: -- Assignee: Maarten Coene > NIO FileLocker releases locks while still within tryLock() call > --- > > Key: IVY-1424 > URL: https://issues.apache.org/jira/browse/IVY-1424 > Project: Ivy > Issue Type: Bug >Reporter: Charles Duffy (Indeed.com) >Assignee: Maarten Coene > Labels: patch > Attachments: ivy-nio-locker-as-option.diff, ivy-nio-locker-fix.diff > > > The notes about NIOFileLocker being deprecated due to unreliability have an > obvious cause -- locks it grabs have already been released before the tryLock > method has even exited due to the finally block closing the file descriptor > on which the lock is held! > (flock() or fcntl()-based locks, into one of which categories those created > by NIO fall on modern Unixlike operating systems, are implicitly closed > whenever the file handle on which they're held exits. This is highly > desirable behavior, because it means that a lock is implicitly cleared on > unclean shutdown of any sort -- power failure, SIGKILL to the JVM, etc; this > behavior is also perhaps the primary reason to prefer NIO locks to the > approach taken by CreateFileLocker). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1197) OutOfMemoryError duriong ivy:publish
[
https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623491#comment-13623491
]
Maarten Coene commented on IVY-1197:
Martin,
what stack trace are you talking about? The OOM error you posted earlier is not
fixed. You will still get this error if you don't add commons-httpcient to
Ivy's classpath. This is a bug in JDK1.4 and it will be solved if you decide to
upgrade the minimal JDK supported by Ivy. However, with commons-httpclient you
should not get this OOM! And with that extra modification we did, the upload
speed should have improved.
Could you verify that Ivy did use commons-httpclient to publish your big
artifact?
Maarten
> OutOfMemoryError duriong ivy:publish
>
>
> Key: IVY-1197
> URL: https://issues.apache.org/jira/browse/IVY-1197
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0
>Reporter: Michael Rumpf
> Attachments: ASF.LICENSE.NOT.GRANTED--clipboard.txt
>
>
> When publishing a large file, an OutOfMemoryError occurs.
> {code}
> [ivy:publish] published ppg to
>
> BUILD FAILED
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:152:
> The following error occurred while executing this line:
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:277:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2786)
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
> at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:168)
> at
> org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:200)
> at
> org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:140)
> at
> org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:85)
> at
> org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:219)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:282)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:261)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:170)
> at org.apache.ivy.Ivy.publish(Ivy.java:600)
> at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:299)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: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:1397)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
> at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Total time: 14 minutes 24 seconds
> Finished: FAILURE
> {code}
> The size of the file that is being uploaded is: 687712714, so around
> 650-700MB.
> The publish task is part of a Hudson Ant build where the artefacts are
> published to an Artifactory repository at the end.
> I have given the Job 1300MB for the max heap size.
> It seems as if the whole file is loaded into memory for the upload.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1408) Ssh Resolver doesn't work with recent Jsch versions
[
https://issues.apache.org/jira/browse/IVY-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13596408#comment-13596408
]
Maarten Coene commented on IVY-1408:
Mykhailo,
I did already modify your patch to make it work with older versions of jsch :-)
btw, you can find CI builds of Ivy here: https://builds.apache.org/job/Ivy/
> Ssh Resolver doesn't work with recent Jsch versions
> ---
>
> Key: IVY-1408
> URL: https://issues.apache.org/jira/browse/IVY-1408
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.3.0
>Reporter: Mykhailo Delegan
>Assignee: Maarten Coene
>Priority: Minor
> Fix For: 2.4.0
>
> Attachments: IVY-1408.patch
>
>
> There is a known "issue" with the Jsch library and Java 1.7, in that it
> prompts for a kerberos username and password (which are then ignored if other
> credentials have already been supplied). This doesn't stop the Ant ssh tasks
> from working, but it does stop them from being completely automated (e.g.
> scripts invoked by a CI server like Jenkins)
> The workaround is either of two:
> # Move back to Java 1.6
> # Use old enough Jsch version (0.1.31 seems to be ok).
> Jsch author, Atsuhiko Yamanaka,
> [suggests|http://sourceforge.net/mailarchive/message.php?msg_id=29359265] to
> configure Jsch Session as following to avoid the issue:
> {code:java}
> session.setConfig("PreferredAuthentications",
> "publickey,keyboard-interactive,password");
> {code}
> The very same issue was
> [filed|https://issues.apache.org/bugzilla/show_bug.cgi?id=53437] and
> [fixed|http://svn.apache.org/viewvc?rev=1429602&view=rev] in Ant.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1197) OutOfMemoryError duriong ivy:publish
[
https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13593946#comment-13593946
]
Maarten Coene commented on IVY-1197:
Martin,
thanks for the interesting links. We now set the
'http.protocol.expect-continue=true' header when using HttpClient.
Could you give it a try? You can download snapshot builds here:
https://builds.apache.org/view/A-F/view/Ant/job/Ivy/
thanks,
Maarten
> OutOfMemoryError duriong ivy:publish
>
>
> Key: IVY-1197
> URL: https://issues.apache.org/jira/browse/IVY-1197
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0
>Reporter: Michael Rumpf
> Attachments: ASF.LICENSE.NOT.GRANTED--clipboard.txt
>
>
> When publishing a large file, an OutOfMemoryError occurs.
> {code}
> [ivy:publish] published ppg to
>
> BUILD FAILED
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:152:
> The following error occurred while executing this line:
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:277:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2786)
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
> at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:168)
> at
> org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:200)
> at
> org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:140)
> at
> org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:85)
> at
> org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:219)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:282)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:261)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:170)
> at org.apache.ivy.Ivy.publish(Ivy.java:600)
> at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:299)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: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:1397)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
> at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Total time: 14 minutes 24 seconds
> Finished: FAILURE
> {code}
> The size of the file that is being uploaded is: 687712714, so around
> 650-700MB.
> The publish task is part of a Hudson Ant build where the artefacts are
> published to an Artifactory repository at the end.
> I have given the Job 1300MB for the max heap size.
> It seems as if the whole file is loaded into memory for the upload.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (IVY-1141) dependencies failed using branch attribute (and extra attrubutes)
[
https://issues.apache.org/jira/browse/IVY-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene reassigned IVY-1141:
--
Assignee: Maarten Coene
> dependencies failed using branch attribute (and extra attrubutes)
> -
>
> Key: IVY-1141
> URL: https://issues.apache.org/jira/browse/IVY-1141
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.1.0
> Environment: windows
>Reporter: Daniel Schwager
>Assignee: Maarten Coene
> Attachments: branch-fix.diff
>
>
> *** Investigation
> i tried to use the branch attribute inside my projekt DEV like this:
>
> branch="mybranch1" rev="latest.integration"
> conf="compile,tests->default"/>
> .
> If I now try to resolve my dependencies, it failed
> because ivy 2.1.0 try to resolve the latest version (5.6) of testng/testng
> which has NO branch-keyword inside it's ivy.xml. The ivy.xml
> of version testng/testng/4.6 contains the following:
>
> organisation="testng" module="testng"
> branch="mybranch1" revision="4.6.1.2"
> status="release"
> publication="2006022700">
> .
> It looks like the resolver skip this 4.6.1.2 version (which is the only one
> containing the
> branch attribute "mybranch1") and try to download the 5.6 (containing NO
> branch attribute !).
> I go the following error message:
> [ivy:configure] :: Ivy 2.1.0 - 20090925235825 :: http://ant.apache.org/ivy/ ::
> ...
> -
> [ivy:resolve] :: problems summary ::
> [ivy:resolve] WARNINGS
> [ivy:resolve] ::
> [ivy:resolve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:resolve] ::
> [ivy:resolve] :: testng#testng#mybranch1;latest.integration:
> several problems occured while resolving dependency:
> testng#testng#mybranch1;latest.integration {compile=[default],
> tests=[default]}:
> [ivy:resolve] java.text.ParseException: inconsistent module
> descriptor file found in 'I:\testng\testng\5.6\ivy.xml': bad branch name:
> expected='mybranch1' found='null';
> [ivy:resolve] java.text.ParseException: inconsistent module
> descriptor file found in
> 'http://ivyrepos.dtnet.de/testng/testng/5.6/ivy.xml': bad branch name:
> expected='mybranch1' found='null';
> [ivy:resolve] ::
> [ivy:resolve]
> [ivy:resolve] ERRORS
> [ivy:resolve] shared-filesystem: bad branch name found in
> I:\testng\testng\5.6\ivy.xml: expected='mybranch1 found='null'
> [ivy:resolve] shared-web: bad branch name found in
> http://ivyrepos.dtnet.de/testng/testng/5.6/ivy.xml: expected='mybranch1
> found='null'
> [ivy:resolve]
> [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> *** Make it reproducable
> I create a VERY small sample project (build.xml & ivy.xml)
> using a sample ivyrepos on our server.
> Could somebody look closer to the problem by downloading the project from
> http://www.opensource-online.org/fileadmin/swd/ivy/ivy-test.zip
> To run, yust unzip and start "ant -f build.xml" and you can see the failure:
> [ivy:resolve] ::
> [ivy:resolve] :: UNRESOLVED DEPENDENCIES ::
> [ivy:resolve] ::
> [ivy:resolve] :: testng#testng#mybranch1;latest.integration:
> java.text.ParseException: inconsistent module descriptor file found in 'http:/
> www.opensource-online.org/fileadmin/swd/ivy/testng/testng/5.6/ivy.xml': bad
> branch name: expected='mybranch1' found='';
> [ivy:resolve] ::
> [ivy:resolve]
> [ivy:resolve] ERRORS
> [ivy:resolve] default: bad branch name found in
> http://www.opensource-online.org/fileadmin/swd/ivy/testng/testng/5.6/ivy.xml:
> expected='myb
> anch1 found=''
> [ivy:resolve]
> [ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
> *** Same problem using extra attributes instead auf branch attribute
> if tried a workaround not using the branch-keyword but defining a own extra
> atrribute like this:
> http://softwaredemo.de/ivy/extra";>
> ...
>rev="latest.integration"
> conf="compile,tests->default"/>
> But this tells me a similar result - also a failure.
> regards
> Danny
> P.S.: refer also to
> http://old.nabble.com/dependencies-failed-usi
[jira] [Resolved] (IVY-1374) ssh connection sometimes fails
[ https://issues.apache.org/jira/browse/IVY-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1374. Resolution: Fixed Fix Version/s: 2.4.0 Assignee: Maarten Coene Duplicate of IVY-1408? Could you try again with trunk version of Ivy? > ssh connection sometimes fails > -- > > Key: IVY-1374 > URL: https://issues.apache.org/jira/browse/IVY-1374 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.3.0-RC1 > Environment: ubuntu 12.04, jdk7.06/32bits, jenkins, jsch 0.1.84, > "OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012" >Reporter: Simon IJskes >Assignee: Maarten Coene >Priority: Minor > Fix For: 2.4.0 > > > when the sftp resolver connects to a remote repository, it sometimes fails to > fetch the artifacts. > This is accompanied by a log entry in the /var/log/auth.log on the server > side: > Aug 30 10:36:02 zzz sshd[1371]: Received disconnect from zzz.zzz.zzz.zzz: 3: > com.jcraft.jsch.JSchException: verify: false [preauth] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IVY-1408) Ssh Resolver doesn't work with recent Jsch versions
[
https://issues.apache.org/jira/browse/IVY-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1408:
---
Fix Version/s: 2.4.0
> Ssh Resolver doesn't work with recent Jsch versions
> ---
>
> Key: IVY-1408
> URL: https://issues.apache.org/jira/browse/IVY-1408
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.3.0
>Reporter: Mykhailo Delegan
>Assignee: Maarten Coene
>Priority: Minor
> Fix For: 2.4.0
>
> Attachments: IVY-1408.patch
>
>
> There is a known "issue" with the Jsch library and Java 1.7, in that it
> prompts for a kerberos username and password (which are then ignored if other
> credentials have already been supplied). This doesn't stop the Ant ssh tasks
> from working, but it does stop them from being completely automated (e.g.
> scripts invoked by a CI server like Jenkins)
> The workaround is either of two:
> # Move back to Java 1.6
> # Use old enough Jsch version (0.1.31 seems to be ok).
> Jsch author, Atsuhiko Yamanaka,
> [suggests|http://sourceforge.net/mailarchive/message.php?msg_id=29359265] to
> configure Jsch Session as following to avoid the issue:
> {code:java}
> session.setConfig("PreferredAuthentications",
> "publickey,keyboard-interactive,password");
> {code}
> The very same issue was
> [filed|https://issues.apache.org/bugzilla/show_bug.cgi?id=53437] and
> [fixed|http://svn.apache.org/viewvc?rev=1429602&view=rev] in Ant.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1408) Ssh Resolver doesn't work with recent Jsch versions
[
https://issues.apache.org/jira/browse/IVY-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1408.
Resolution: Fixed
Assignee: Maarten Coene
Applied your patch in SVN trunk (but I didn't upgrade the jsch library though).
Thanks for the contribution!
> Ssh Resolver doesn't work with recent Jsch versions
> ---
>
> Key: IVY-1408
> URL: https://issues.apache.org/jira/browse/IVY-1408
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.3.0
>Reporter: Mykhailo Delegan
>Assignee: Maarten Coene
>Priority: Minor
> Attachments: IVY-1408.patch
>
>
> There is a known "issue" with the Jsch library and Java 1.7, in that it
> prompts for a kerberos username and password (which are then ignored if other
> credentials have already been supplied). This doesn't stop the Ant ssh tasks
> from working, but it does stop them from being completely automated (e.g.
> scripts invoked by a CI server like Jenkins)
> The workaround is either of two:
> # Move back to Java 1.6
> # Use old enough Jsch version (0.1.31 seems to be ok).
> Jsch author, Atsuhiko Yamanaka,
> [suggests|http://sourceforge.net/mailarchive/message.php?msg_id=29359265] to
> configure Jsch Session as following to avoid the issue:
> {code:java}
> session.setConfig("PreferredAuthentications",
> "publickey,keyboard-interactive,password");
> {code}
> The very same issue was
> [filed|https://issues.apache.org/bugzilla/show_bug.cgi?id=53437] and
> [fixed|http://svn.apache.org/viewvc?rev=1429602&view=rev] in Ant.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1197) OutOfMemoryError duriong ivy:publish
[
https://issues.apache.org/jira/browse/IVY-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590034#comment-13590034
]
Maarten Coene commented on IVY-1197:
Martin,
if you add httpclient-3.x.jar to Ivy's classpath the problem should be solved.
The OOM only occurs when Ivy uses the standard Java APIs.
Regarding the slow upload speed when using httpclient, could you provide more
info?
(for instance the debug logging of httpclient)
Maarten
> OutOfMemoryError duriong ivy:publish
>
>
> Key: IVY-1197
> URL: https://issues.apache.org/jira/browse/IVY-1197
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0
>Reporter: Michael Rumpf
> Attachments: ASF.LICENSE.NOT.GRANTED--clipboard.txt
>
>
> When publishing a large file, an OutOfMemoryError occurs.
> {code}
> [ivy:publish] published ppg to
>
> BUILD FAILED
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:152:
> The following error occurred while executing this line:
> /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:277:
> java.lang.OutOfMemoryError: Java heap space
> at java.util.Arrays.copyOf(Arrays.java:2786)
> at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
> at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:168)
> at
> org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:200)
> at
> org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
> at org.apache.ivy.util.FileUtil.copy(FileUtil.java:140)
> at
> org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:85)
> at
> org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:219)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:282)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:261)
> at
> org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:170)
> at org.apache.ivy.Ivy.publish(Ivy.java:600)
> at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:299)
> at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java: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:1397)
> at
> org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
> at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
> at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
> at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
> at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> Total time: 14 minutes 24 seconds
> Finished: FAILURE
> {code}
> The size of the file that is being uploaded is: 687712714, so around
> 650-700MB.
> The publish task is part of a Hudson Ant build where the artefacts are
> published to an Artifactory repository at the end.
> I have given the Job 1300MB for the max heap size.
> It seems as if the whole file is loaded into memory for the upload.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1409) Uploading large files during publish fails with broken pipe error
[ https://issues.apache.org/jira/browse/IVY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590028#comment-13590028 ] Maarten Coene commented on IVY-1409: Ivy only works with httpclient 3.x, not with httpclient 4.x... This broken pipe looks like an httpclient issue to me. Could you try to enable the httpclient debug logging to see more details about what httpclient is doing? > Uploading large files during publish fails with broken pipe error > - > > Key: IVY-1409 > URL: https://issues.apache.org/jira/browse/IVY-1409 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.2.0, 2.3.0 > Environment: ubuntu 12.0.4 with java 7 and ant 1.8 >Reporter: Chandra Srinivasan >Priority: Critical > Labels: brokenpipe, ioexception, outofmemory, publish > > This is a duplicate of bug 1197. > I have tried using ivy 2.2 and the recently released 2.3 to publish files > larger than 100mb. The Ivy repository we are using is Artifactory. I was able > to successfully upload large files to Artifactory via their web UI as well as > using curl from commandline. So obviously the error is happning on the Ivy > side. See details below. > 1) I started out with the default httpclient that is shipped with Ivy/java > and I got Out of memory error as shown below. > ant -f ivy/build.xml publish-shared > Buildfile: /media/data/workspace/Intercept_Installer-RB-1.35/ivy/build.xml > require-artifact-dir: > resolve: > [ivy:resolve] :: Apache Ivy 2.3.0 - 20130110142753 :: > http://ant.apache.org/ivy/ :: > [ivy:resolve] :: loading settings :: file = > /media/data/workspace/Intercept_Installer-RB-1.35/ivy/ivysettings.xml > [ivy:resolve] :: resolving dependencies :: > org.coastal#Intercept_Installer#RB-1.35;1.35 > [ivy:resolve] confs: [default] > [ivy:resolve] :: resolution report :: resolve 71ms :: artifacts dl 0ms > - > | |modules|| artifacts | > | conf | number| search|dwnlded|evicted|| number|dwnlded| > - > | default | 0 | 0 | 0 | 0 || 0 | 0 | > - > [ivy:retrieve] :: retrieving :: org.coastal#Intercept_Installer > [ivy:retrieve]confs: [default] > [ivy:retrieve]0 artifacts copied, 0 already retrieved (0kB/4ms) > ivy-new-version: > publish-shared: > [ivy:publish] :: delivering :: org.coastal#Intercept_Installer#trunk;1.35 :: > 1.35.2 :: release :: Wed Feb 27 12:51:39 PST 2013 > [ivy:publish] delivering ivy file to > /media/data/workspace/Intercept_Installer-RB-1.35/dist/ivy.xml > [ivy:publish] :: publishing :: org.coastal#Intercept_Installer > BUILD FAILED > /media/data/workspace/Intercept_Installer-RB-1.35/ivy/build.xml:88: > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:2271) > at java.io.ByteArrayOutputStream.grow(ByteArrayOutputStream.java:113) > at > java.io.ByteArrayOutputStream.ensureCapacity(ByteArrayOutputStream.java:93) > at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:140) > at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:78) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:183) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:162) > at > org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:256) > at > org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82) > at org.apache.ivy.util.FileUtil.copy(FileUtil.java:150) > at > org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84) > at > org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130) > at > org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:234) > at > org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:216) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:275) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:254) > at > org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:166) > at org.apache.ivy.Ivy.publish(Ivy.java:615) > at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:312) > at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277) > at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) > at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Sou
[jira] [Moved] (IVYDE-339) Ivy IDE update site still fetches 2.3.0.cr2 jar (instead of 2.3.0 final)
[ https://issues.apache.org/jira/browse/IVYDE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene moved IVY-1403 to IVYDE-339: -- Component/s: (was: Ant) Affects Version/s: (was: 2.3.0) Key: IVYDE-339 (was: IVY-1403) Project: IvyDE (was: Ivy) > Ivy IDE update site still fetches 2.3.0.cr2 jar (instead of 2.3.0 final) > > > Key: IVYDE-339 > URL: https://issues.apache.org/jira/browse/IVYDE-339 > Project: IvyDE > Issue Type: Improvement >Reporter: Dejan Stojadinovic >Priority: Minor > Labels: eclipse, ivyde > Attachments: IvyDE_snapshot.png > > > Ivy IDE update site (http://www.apache.org/dist/ant/ivyde/updatesite/) still > fetches 2.3.0.cr2 jar (instead of 2.3.0 final). > See attached > [snapshot|https://issues.apache.org/jira/secure/attachment/12569314/IvyDE_snapshot.png], > please. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1405) Broken link in ivy.xml documentation
[ https://issues.apache.org/jira/browse/IVY-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1405. Resolution: Fixed Fix Version/s: 2.4.0 Assignee: Maarten Coene Fixed in SVN trunk. Thanks for reporting! > Broken link in ivy.xml documentation > - > > Key: IVY-1405 > URL: https://issues.apache.org/jira/browse/IVY-1405 > Project: Ivy > Issue Type: Bug > Components: Documentation >Reporter: Yanus Poluektovich >Assignee: Maarten Coene >Priority: Minor > Fix For: 2.4.0 > > > Page > http://ant.apache.org/ivy/history/latest-milestone/ivyfile/dependency.html > Section "Artifact restriction" > There is a link named "dependency artifact restriction" to > "#dependency-artifact", but there is no such anchor on that page. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Moved] (IVYDE-338) Wrong size of an icon in "about eclipse platform"
[ https://issues.apache.org/jira/browse/IVYDE-338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene moved IVY-1406 to IVYDE-338: -- Component/s: (was: Core) Fix Version/s: (was: unspecified) Affects Version/s: (was: trunk) Key: IVYDE-338 (was: IVY-1406) Project: IvyDE (was: Ivy) > Wrong size of an icon in "about eclipse platform" > - > > Key: IVYDE-338 > URL: https://issues.apache.org/jira/browse/IVYDE-338 > Project: IvyDE > Issue Type: Improvement > Environment: kepler 4.3. ; win 8 pro >Reporter: john amlc > Original Estimate: 1h > Remaining Estimate: 1h > > Hi, > Why is there a different icon size in "about eclipse platform". Look on any > other project and there we go. Every icon has the same size. > http://imgur.com/Gflxthg > I mean it doesn't look that good, in general. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1412) publication date provided in bad format - random failures - thread safety parsing dates
[
https://issues.apache.org/jira/browse/IVY-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1412.
Resolution: Fixed
Fix Version/s: 2.4.0
Fixed in SVN trunk!
Thanks for reporting.
> publication date provided in bad format - random failures - thread safety
> parsing dates
> ---
>
> Key: IVY-1412
> URL: https://issues.apache.org/jira/browse/IVY-1412
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.3.0
> Environment: Windows
>Reporter: Martin Sillence
>Assignee: Maarten Coene
>Priority: Minor
> Fix For: 2.4.0
>
>
> The text appears to be correct and when run though test code is OK but it
> fails randomly in production.
> We are using the ant contrib concurrency foreach task.
> I think this is a threading issue:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4146524
> Can we add synchronised around this method?
> Normally rerunning the build succeeds.
> Error log is:
> [foreach] Caused by: d:\jenkins\jobs\\BuildAndPublish.xml:418:
> publication date provided in bad format. should be MMddHHmmss and not
> 20130228123237
> [foreach] at org.apache.ivy.ant.IvyTask.getPubDate(IvyTask.java:197)
> [foreach] at org.apache.ivy.ant.IvyDeliver.doExecute(IvyDeliver.java:376)
> method signature is currenty:
> protected static Date getPubDate(String date, Date def) {
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IVY-1412) publication date provided in bad format - random failures - thread safety parsing dates
[
https://issues.apache.org/jira/browse/IVY-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1412:
---
Assignee: Maarten Coene
Remaining Estimate: (was: 1h)
Original Estimate: (was: 1h)
> publication date provided in bad format - random failures - thread safety
> parsing dates
> ---
>
> Key: IVY-1412
> URL: https://issues.apache.org/jira/browse/IVY-1412
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.3.0
> Environment: Windows
>Reporter: Martin Sillence
>Assignee: Maarten Coene
>Priority: Minor
>
> The text appears to be correct and when run though test code is OK but it
> fails randomly in production.
> We are using the ant contrib concurrency foreach task.
> I think this is a threading issue:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4146524
> Can we add synchronised around this method?
> Normally rerunning the build succeeds.
> Error log is:
> [foreach] Caused by: d:\jenkins\jobs\\BuildAndPublish.xml:418:
> publication date provided in bad format. should be MMddHHmmss and not
> 20130228123237
> [foreach] at org.apache.ivy.ant.IvyTask.getPubDate(IvyTask.java:197)
> [foreach] at org.apache.ivy.ant.IvyDeliver.doExecute(IvyDeliver.java:376)
> method signature is currenty:
> protected static Date getPubDate(String date, Date def) {
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1400) NullPointerException - problem while listing resources
[
https://issues.apache.org/jira/browse/IVY-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13569645#comment-13569645
]
Maarten Coene commented on IVY-1400:
Thanks! You can find snapshot builds here:
https://builds.apache.org/view/A-F/view/Ant/job/Ivy/
> NullPointerException - problem while listing resources
> --
>
> Key: IVY-1400
> URL: https://issues.apache.org/jira/browse/IVY-1400
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Frédéric RIVIERE
>Assignee: Maarten Coene
>Priority: Minor
> Fix For: 2.4.0
>
>
> After debugging, the problem appears when using
> org.apache.ivy.util.url.HttpClientHandler (connecting jakarta commons http
> client).
> A check is missing in getURLInfo() when web server does not return
> content-type in HTTP header. Line 156,
> method.getResponseHeader("content-type") returns null so NPE occurs when
> calling getValue().
> Works fine with BasicURLHandler.
> Should be something like:
> public URLInfo getURLInfo(URL url, int timeout) {
>...
> if (checkStatusCode(url, method)) {
> HttpResponseHeader h =
> method.getResponseHeader("content-type");
> String contentType = h == null ? null : h.getValue();
> String bodyCharset =
> BasicURLHandler.getCharSetFromContentType(contentType);
> ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IVY-1391) IvyPublish fails when using extend tags with no explicit location attribute
[
https://issues.apache.org/jira/browse/IVY-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1391:
---
Fix Version/s: (was: trunk)
2.3.0
> IvyPublish fails when using extend tags with no explicit location attribute
> ---
>
> Key: IVY-1391
> URL: https://issues.apache.org/jira/browse/IVY-1391
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0-RC2
>Reporter: Jean-Louis Boudart
>Priority: Blocker
> Fix For: 2.3.0
>
>
> IvyPublish fails to resolve parent when using extends tag with no explicit
> location attribute.
> It fails with the following error :
> {code}
> Caused by: java.text.ParseException: Unable to parse included ivy file for
> apache#extends-parent;latest.integration
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IVY-1363) ivy:buildlist task confused by extends feature using two parents
[ https://issues.apache.org/jira/browse/IVY-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1363: --- Fix Version/s: (was: trunk) > ivy:buildlist task confused by extends feature using two parents > > > Key: IVY-1363 > URL: https://issues.apache.org/jira/browse/IVY-1363 > Project: Ivy > Issue Type: Bug > Components: Ant, Core >Affects Versions: 2.3.0-RC1 > Environment: Ant 1.7.1 (but should be the same with Ant 1.8.3) >Reporter: Mitch Gitman >Assignee: Nicolas Lalevée > Labels: patch, testcase > Fix For: 2.3.0-RC2 > > Attachments: BuildlistAndExtendsIntegrationTest.zip, > IVY-1347-1363-2.3.x.patch, IVY-1347-1363.patch, IVY-1347-1363-trunk.patch, > IVY-1359-1363-1364-2.3.x.patch, ivy-2.3.x.patch, ivy-trunk.patch > > > I'm finding that the ivy:buildlist Ant task is erroring when it encounters > more than one parent Ivy module that's pulled in through the > /ivy-module/info/extends element. This problem is new to Ivy 2.3.0-rc1; I did > not encounter it with Ivy 2.2.0. There is no relationship or interaction > between the two different parent Ivy modules, i.e. no nesting of parents. > In my test case, which I explain shortly, when I point the ivy:buildlist Ant > task at a project stack that includes a mix of both parents and their > children, I see this error: > ...\multimodule-build\build.xml:28: impossible to parse ivy file for > ...\testTwoParents\germany\build.xml: > ivyfile=...\testTwoParents\germany\ivy.xml > exception=java.text.ParseException: Problem occurred while parsing ivy file: > inconsistent module descriptor file found in > 'file:/.../testTwoParents/master-parent/ivy.xml': bad module name: > expected='bootstrap-parent' found='master-parent'; in > file:/.../testTwoParents/germany/ivy.xml > What's happening is, the germany module extends bootstrap-parent, but somehow > the relative path to master-parent/ivy.xml is supplanting the relative path > to bootstrap-parent/ivy.xml. It appears buildlist doesn't know how to deal > with more than one parent. > This is what occurs when the haltOnError attribute is set to "true" on > ivy:buildlist. If I set haltOnError="false" in my test case, the exception > goes away, but I see the following build order: > 1. germany > 2. ireland > 3. bootstrap-parent > 4. master-parent > 5. croatia > What's wrong about this build order is that germany depends on ireland and > ireland depends on bootstrap-parent, so the order of the first three entries > is reversed. If I removed the dependency of ireland on bootstrap-parent, the > order would be the same. This misordering is clearly related to the presence > of more than one parent because comparable tests using (A) the extends > feature with a single parent and (B) no extends feature at all get the order > right. Plus, I see this unexpected output when haltOnError="false": > [ivy:buildlist] => adding it at the beginning of the path > [ivy:buildlist] => adding it at the beginning of the path > TEST CASE INSTRUCTIONS: > I've attached a ZIP containing three standalone test cases, each consisting > of a suite of Ant projects that together comprise a multimodule build whose > build order is to be determined by the ivy:buildlist task: > * testNoParents: The extends feature is not used. > * testOneParent: The extends feature is used to pull in content from a single > parent Ivy module. > * testTwoParents: The extends feature is used where one Ivy module pulls in > content from one parent and two other Ivy modules pull in content from a > different parent. > The testNoParents and testOneParent tests are the control groups. The > testTwoParents test is where things fail. > When running Ant from one of these test cases, you need to specify the > location of the Ivy 2.3.0-rc1 installation using one of the following: > * an IVY_DIR environment variable > * an env.IVY_DIR user property, i.e. -Denv.IVY_DIR=... > * an ivy.dir user property, i.e. -Divy.dir=... > To run the build in any of these suites, go to the multimodule-build > directory, and execute "ant" or "ant init"—while specifying the Ivy > installation location. You can also run "ant cleancache" to clear out the Ivy > cache. However, you shouldn't need to do this regularly because each of these > test cases uses its own dedicated Ivy cache. > NOTE: This issue is broached in the email thread "extends & buildlist on > 2.3.0-rc1 … it gets worse" on the ivy-user and ant-dev mailing lists. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IVY-1388) *.lck files created by "artifact-lock" lock strategy are not cleaned up if ivy quits abruptly
[ https://issues.apache.org/jira/browse/IVY-1388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-1388: --- Fix Version/s: (was: trunk) > *.lck files created by "artifact-lock" lock strategy are not cleaned up if > ivy quits abruptly > - > > Key: IVY-1388 > URL: https://issues.apache.org/jira/browse/IVY-1388 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.2.0, 2.3.0-RC1, trunk >Reporter: Wei Chen >Assignee: Nicolas Lalevée > Fix For: 2.3.0 > > Attachments: FileBasedLockStrategy.java.patch, patch1.patch > > Original Estimate: 0.5m > Remaining Estimate: 0.5m > > We have a few build processes running in parallel, all of which share the > same ivy cache. In order not to run into any parallel downloading problems, > we enabled artifact-lock lock strategy. An annoying problem with the > artifact-lock strategy is that the *.lck files which are created as a lock > are not cleaned up if the build exits abruptly. For example, while ivy is > downloading a big jar, if you Ctrl-C to quit that build process. Those lock > files will remain in the metadatas folder. The same happens too if ivy > encounters some error and fails the build. > Those uncleaned lock files will cause problem when you start the build again. > The build process will hang while ivy waiting those "locks" to be released, > which will never happen automatically. So eventually the build will fail with > an ivy error "impossible to acquire lock for xxxyyy". What makes it worse > is that ivy doesn't fail-fast on the default 2 miuntes lock timeout, it seems > trying it a few times. In worst scenarios, we have seen the build hangs for > 12 minutes and then timeout'd and failed. > We believe this can be fixed by setting deleteOnExit() for the > FileBasedLockStrategy.java class. We have implemented the fix and it works > well. > Patch is provided, could anyone quickly apply this one line change? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1400) NullPointerException - problem while listing resources
[
https://issues.apache.org/jira/browse/IVY-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1400.
Resolution: Fixed
Fix Version/s: 2.4.0
Thanks for the report!
I've committed a fix in SVN trunk. Could you give it a try?
> NullPointerException - problem while listing resources
> --
>
> Key: IVY-1400
> URL: https://issues.apache.org/jira/browse/IVY-1400
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Frédéric RIVIERE
>Assignee: Maarten Coene
>Priority: Minor
> Fix For: 2.4.0
>
>
> After debugging, the problem appears when using
> org.apache.ivy.util.url.HttpClientHandler (connecting jakarta commons http
> client).
> A check is missing in getURLInfo() when web server does not return
> content-type in HTTP header. Line 156,
> method.getResponseHeader("content-type") returns null so NPE occurs when
> calling getValue().
> Works fine with BasicURLHandler.
> Should be something like:
> public URLInfo getURLInfo(URL url, int timeout) {
>...
> if (checkStatusCode(url, method)) {
> HttpResponseHeader h =
> method.getResponseHeader("content-type");
> String contentType = h == null ? null : h.getValue();
> String bodyCharset =
> BasicURLHandler.getCharSetFromContentType(contentType);
> ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IVY-1400) NullPointerException - problem while listing resources
[
https://issues.apache.org/jira/browse/IVY-1400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1400:
---
Assignee: Maarten Coene
Remaining Estimate: (was: 1h)
Original Estimate: (was: 1h)
> NullPointerException - problem while listing resources
> --
>
> Key: IVY-1400
> URL: https://issues.apache.org/jira/browse/IVY-1400
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.3.0
>Reporter: Frédéric RIVIERE
>Assignee: Maarten Coene
>Priority: Minor
>
> After debugging, the problem appears when using
> org.apache.ivy.util.url.HttpClientHandler (connecting jakarta commons http
> client).
> A check is missing in getURLInfo() when web server does not return
> content-type in HTTP header. Line 156,
> method.getResponseHeader("content-type") returns null so NPE occurs when
> calling getValue().
> Works fine with BasicURLHandler.
> Should be something like:
> public URLInfo getURLInfo(URL url, int timeout) {
>...
> if (checkStatusCode(url, method)) {
> HttpResponseHeader h =
> method.getResponseHeader("content-type");
> String contentType = h == null ? null : h.getValue();
> String bodyCharset =
> BasicURLHandler.getCharSetFromContentType(contentType);
> ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1396) Ivy generating wrong revision in URL for sample Maven artifact
[ https://issues.apache.org/jira/browse/IVY-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1396. Resolution: Fixed Fix Version/s: 2.3.0 Assignee: Maarten Coene Fixed in both trunk and 2.3.x-branch. Thanks for reporting this issue! > Ivy generating wrong revision in URL for sample Maven artifact > -- > > Key: IVY-1396 > URL: https://issues.apache.org/jira/browse/IVY-1396 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.3.0-RC2 >Reporter: Nick Spacek >Assignee: Maarten Coene >Priority: Minor > Fix For: 2.3.0 > > Attachments: build.xml, ivysettings.xml, ivy.xml, pom.xml, rc1.log, > rc2.log > > > I'm having some troubles with Ivy resolving the wrong latest.integration for > a Maven artifact. It is reading the Maven metadata (apparently)and > determining that there is a 0.0.3-SNAPSHOT version. Strangely, it then > attempts to retrieve a POM that is using both the 0.0.3-SNAPSHOT version from > the metadata and a 0.0.1-SNAPSHOT version that it could have only discovered > using the metadata for that particular version, as you will see below. As far > as I can tell, the Maven metadata is fine. > I've put together a sample. A simple, empty Maven artifact, and an Ivy build > that resolves it. > I deployed three version of Maven artifact at 0.0.1-SNAPSHOT. Each time I > asked Ivy to resolve, it was successful. When I updated the version to > 0.0.2-SNAPSHOT, it began mixing the URLs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1395) Netbeans ivy plugin
[ https://issues.apache.org/jira/browse/IVY-1395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1395. Resolution: Fixed Assignee: Maarten Coene Done, the link should be online now. Thanks! > Netbeans ivy plugin > --- > > Key: IVY-1395 > URL: https://issues.apache.org/jira/browse/IVY-1395 > Project: Ivy > Issue Type: Task > Components: Documentation >Affects Versions: 2.2.0 > Environment: IDE >Reporter: Raymond Munian >Assignee: Maarten Coene >Priority: Minor > Labels: documentation > > Please update the links to include > http://code.google.com/p/ivy-nb-shared-libraries/ > This plugin provides ivy support when using the Netbeans IDE. The ivybeans > plugin seems to no longer be maintained. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1396) Ivy generating wrong revision in URL for sample Maven artifact
[ https://issues.apache.org/jira/browse/IVY-1396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534378#comment-13534378 ] Maarten Coene commented on IVY-1396: Could you try 2.3.0-RC1 to see if you have the same problem? We changed something to the SNAPSHOT resolving in 2.3.0-RC2 and it would be very helpfull to find out if it was already broking in 2.3.0-RC1 or not. > Ivy generating wrong revision in URL for sample Maven artifact > -- > > Key: IVY-1396 > URL: https://issues.apache.org/jira/browse/IVY-1396 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.3.0-RC2 >Reporter: Nick Spacek >Priority: Minor > Attachments: build.xml, ivysettings.xml, ivy.xml, pom.xml > > > I'm having some troubles with Ivy resolving the wrong latest.integration for > a Maven artifact. It is reading the Maven metadata (apparently)and > determining that there is a 0.0.3-SNAPSHOT version. Strangely, it then > attempts to retrieve a POM that is using both the 0.0.3-SNAPSHOT version from > the metadata and a 0.0.1-SNAPSHOT version that it could have only discovered > using the metadata for that particular version, as you will see below. As far > as I can tell, the Maven metadata is fine. > I've put together a sample. A simple, empty Maven artifact, and an Ivy build > that resolves it. > I deployed three version of Maven artifact at 0.0.1-SNAPSHOT. Each time I > asked Ivy to resolve, it was successful. When I updated the version to > 0.0.2-SNAPSHOT, it began mixing the URLs. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1385) incoherence between "m:classifier" and "source/javadoc-artefacts naming" during ivy:install from ibiblio
[ https://issues.apache.org/jira/browse/IVY-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1385. Resolution: Not A Problem You can solve it by adding the [classifier] token to the patterns of your target repository resolver. > incoherence between "m:classifier" and "source/javadoc-artefacts naming" > during ivy:install from ibiblio > - > > Key: IVY-1385 > URL: https://issues.apache.org/jira/browse/IVY-1385 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.2.0 > Environment: Java-1.6.0_35, Ant-1.8.3, Ivy-2.2.0, > IvyDE-2.2.0.beta1-201203282058-RELEASE >Reporter: Emmanuel FOUCHE > > When ivy:install-ing the module org.apache.ant#ant#1.8.3, the module is > fetched from "repo1.maven.org" > The following files are downloaded: > http://repo1.maven.org/maven2/org/apache/ant/ant/1.8.3/ant-1.8.3.pom > http://repo1.maven.org/maven2/org/apache/ant/ant/1.8.3/ant-1.8.3.jar > http://repo1.maven.org/maven2/org/apache/ant/ant/1.8.3/ant-1.8.3-sources.jar > http://repo1.maven.org/maven2/org/apache/ant/ant/1.8.3/ant-1.8.3-javadoc.jar > The following files are created in target repository > [ivy:install] published ant to > D:\[...]\ivysettings/_repository/20120516-180541/org.apache.ant/ant/1.8.3/jars/ant.jar > [ivy:install] published ant to > D:\[...]\ivysettings/_repository/20120516-180541/org.apache.ant/ant/1.8.3/javadocs/ant.jar > [ivy:install] published ant to > D:\[...]\ivysettings/_repository/20120516-180541/org.apache.ant/ant/1.8.3/sources/ant.jar > [ivy:install] published ivy to > D:\[...]\ivysettings/_repository/20120516-180541/org.apache.ant/ant/1.8.3/ivys/ivy.xml > Noticed all jars have been renamed to "ant.jar" but the ivy file contains > artifacts declaration including "m:classifier" > > m:classifier="sources"/> > m:classifier="javadoc"/> > The problem also occurs when using IVY from command line ANT. > The artefact definition using m:classifier="sources" make IVY look for the > file named ant-sources.jar while attempting to resolve source-typed artefact. > Full descrition w/ logfile and testcase setup procedure here: > http://old.nabble.com/Resolving-source-artefact-altered-by-m%3Aclassifier-td33890292.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IVY-1393) Ant task exec arg value does not quote properly for MSWindows
[
https://issues.apache.org/jira/browse/IVY-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-1393:
---
Labels: (was: features newbie)
Remaining Estimate: (was: 504h)
Original Estimate: (was: 504h)
> Ant task exec arg value does not quote properly for MSWindows
> -
>
> Key: IVY-1393
> URL: https://issues.apache.org/jira/browse/IVY-1393
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Environment: MSWindows
>Reporter: Vincent Belaïche
>
> I want to pass to some application the following string:\\
> {noformat}
>
> {noformat}
> So I use the following:\\
> {noformat}
>
>
>
> {noformat}
> However, the application gets this instead:\\
> {noformat}
>
> {noformat}
> Double quotes were stripped by MSWindows because they were not properly
> escaped in the command line by Ant.
> I wrote a piece of code to do escaping of double quotes properly, and I will
> try to attach it to the issue later on if I can.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1393) Ant task exec arg value does not quote properly for MSWindows
[
https://issues.apache.org/jira/browse/IVY-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1393.
Resolution: Invalid
Yes, you submitted it to the wrong project.
You can find the Apache Ant issuetracker here:
https://issues.apache.org/bugzilla/enter_bug.cgi?product=Ant
> Ant task exec arg value does not quote properly for MSWindows
> -
>
> Key: IVY-1393
> URL: https://issues.apache.org/jira/browse/IVY-1393
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Environment: MSWindows
>Reporter: Vincent Belaïche
> Labels: features, newbie
> Original Estimate: 504h
> Remaining Estimate: 504h
>
> I want to pass to some application the following string:\\
> {noformat}
>
> {noformat}
> So I use the following:\\
> {noformat}
>
>
>
> {noformat}
> However, the application gets this instead:\\
> {noformat}
>
> {noformat}
> Double quotes were stripped by MSWindows because they were not properly
> escaped in the command line by Ant.
> I wrote a piece of code to do escaping of double quotes properly, and I will
> try to attach it to the issue later on if I can.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1392) Optional ivysettings directives
[ https://issues.apache.org/jira/browse/IVY-1392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1392. Resolution: Fixed Fix Version/s: trunk Assignee: Maarten Coene Patch applied. Thanks for your contribution! > Optional ivysettings directives > - > > Key: IVY-1392 > URL: https://issues.apache.org/jira/browse/IVY-1392 > Project: Ivy > Issue Type: Improvement > Components: Core >Reporter: Yanus Poluektovich >Assignee: Maarten Coene >Priority: Minor > Fix For: trunk > > Attachments: optional-include.patch > > > To allow for VCS-friendly customization of dependency resolution process, a > feature that allows for files referenced in an directive of an > ivysettings.xml file to be missing without it triggering an error. > With such a feature, it would be possible to write a global ivysettings.xml > file that references a default setup of resolvers/repositories for a project, > commit it into a VCS and then never edit it. Instead, an "optional include" > directive will point to a file with standardized name, say, > ivysettings-local.xml. The file may be missing (which results in the > project-default configuration being used), or a developer can create such a > file and define an alternative resolution configuration for his own use. The > VCS can be configured to ignore the ivysettings-local.xml file, thus > absolving the developer of the need to ensure manually at each check-in that > the file is not committed into the VCS. > Currently, a similar feature is implemented for properties files. > Unfortunately, it is impossible to, for example, override a project-default > resolver with a user-specific one only via use of properties. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
