[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] [Commented] (IVY-1284) Ivy XML files fail with "Content is not allowed in prolog" when using Polipo proxy cache
[ https://issues.apache.org/jira/browse/IVY-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030916#comment-13030916 ] Maarten Coene commented on IVY-1284: Since you are using maven repositories, Ivy will look for a POM file instead of an IVY file. I guess it goes wrong there, could you take a look in your ivy-cache and open the "commons-collections-3.1.xml.original" file to see it is a valid maven POM file? > Ivy XML files fail with "Content is not allowed in prolog" when using Polipo > proxy cache > > > Key: IVY-1284 > URL: https://issues.apache.org/jira/browse/IVY-1284 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.2.0 > Environment: MacOS 10.6.7, sbt 0.7.5, jdk1.6.0_24 >Reporter: Will Sargent >Priority: Minor > Fix For: 2.2.0 > > > This is an interesting issue, and one that I'm not 100% is a result of the > proxy cache, but: > 1. Set up Polipo (http://www.pps.jussieu.fr/~jch/software/polipo/) out of the > box using Macports (sudo port install polipo) > 2. Set up the System Preferences to use the HTTP proxy to go through Polipo. > 3. Delete the ~/.ivy2 directory > 4. Go to the SBT project you have set up, and type "sbt update" (or I'm > assuming any Ivy related network task) > Instead of getting the file you expect, you get the following: > Getting org.scala-tools.sbt sbt_2.7.7 0.7.4 ... > [Fatal Error] ivy-0.1.31.xml.original:2:1: Content is not allowed in prolog. > org.xml.sax.SAXParseException: Content is not allowed in prolog. > at > com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:249) > at > com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:284) > at javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:153) > at org.apache.ivy.util.XMLHelper.parseToDom(XMLHelper.java:196) > at org.apache.ivy.plugins.parser.m2.PomReader.(PomReader.java:95) > at > org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:118) > at > org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:108) > at > org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:659) > at > org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68) > at > org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:676) > at > org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:993) > at > org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:546) > at > org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:266) > at > org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:503) > 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:287) > at > org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:696) > at > org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781) > at > org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704) > at > org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781) > at > org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704) > at > org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:576) > at > org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:237) > at xsbt.boot.Update.resolve(Update.scala:159) > at xsbt.boot.Update.update(Update.scala:116) > at xsbt.boot.Update.update(Update.scala:110) > at xsbt.boot.Update.xsbt$boot$Update$$lockedApply(Update.scala:73) > at xsbt.boot.Update$$anon$2.call(Update.scala:67) > at xsbt.boot.Update$$anon$2.call(Update.scala:67) > at xsbt.boot.Locks$GlobalLock.withChannel$1(Locks.scala:63) > at > xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:67) > at > xsbt.boot.Locks$GlobalLock$$anonfun$withFileLock$1.apply(Locks.scala:67) > at xsbt.boot.Using$.withResource(Using.scala:11) > at xsbt.boot.Using$.apply(Using.scala:10) > at xsbt.boot.Locks$GlobalLock.withFileLock(Locks.scala:67) > at xsbt.boot.Locks$GlobalLoc
[jira] [Commented] (IVY-1291) Keep older versions of ivy binaries for download
[ https://issues.apache.org/jira/browse/IVY-1291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13031636#comment-13031636 ] Maarten Coene commented on IVY-1291: Old versions of Ivy are available here: http://archive.apache.org/dist/ant/ivy/ Perhaps we should add this link on the download page. > Keep older versions of ivy binaries for download > > > Key: IVY-1291 > URL: https://issues.apache.org/jira/browse/IVY-1291 > Project: Ivy > Issue Type: Wish >Reporter: Martin von Gagern >Priority: Minor > > I've included code in my build files to automatically download ivy if it > isn't already available on the target system. For this I had to hard-code the > ivy version into the download URL, it was 2.1.0 back then. Now 2.2.0 is > around, and what is worse, the 2.1.0 downloads are no longer available from > http://www.apache.org/dist/ant/ivy/ > Of course I could mirror ivy versions on my own web server. But I guess I > might not be the only one who would benefit from having older versions > available indefinitely. So the apache hosts would seem the ideal place to > keep older versions as well. It is somewhat strange that the online > documentation for older versions is readily available, but their downloads > are not. Usually it is the other way round. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1292) The tag version-matchers is missing attribute in documentation
[ https://issues.apache.org/jira/browse/IVY-1292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1292. Resolution: Fixed Fix Version/s: trunk Assignee: Maarten Coene I've applied your patch in SVN trunk. Thanks for the contribution! > The tag version-matchers is missing attribute in documentation > -- > > Key: IVY-1292 > URL: https://issues.apache.org/jira/browse/IVY-1292 > Project: Ivy > Issue Type: Bug > Components: Documentation >Affects Versions: 2.2.0 >Reporter: Per Arnold Blaasmo >Assignee: Maarten Coene >Priority: Minor > Fix For: trunk > > Attachments: version-matcher.patch > > > I was trying to add a and discovered that it overrides the > default matchers unless I added attribute usedefaults=true > I found this attribute by looking trough the code. > This attibute is not mentioned in the documentation. I think it is important > that it is described, and that perhaps there also should be an example with > it. > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1294) honor restriction of artifacts for pom file creating in makepom task
[ https://issues.apache.org/jira/browse/IVY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037262#comment-13037262 ] Maarten Coene commented on IVY-1294: Thanks for the patch Jens, but could you please attach it again and check the option "Grant license to ASF" on the "attach files" screen, otherwise I cannot include it in the codebase. > honor restriction of artifacts for pom file creating in makepom task > > > Key: IVY-1294 > URL: https://issues.apache.org/jira/browse/IVY-1294 > Project: Ivy > Issue Type: Improvement > Components: Ant >Affects Versions: 2.2.0 >Reporter: Jens Rohloff >Priority: Minor > Attachments: PomModuleDescriptorWriter.java.patch > > > I'm using maven repository for managing our artifacts and seems to prefer the > use of pom files. > Using the makepom task works great but the PomModuleDescriptorWriter.class > doesn't parse the exclude elements of the dependencies and I'm ending up with > lots of unwanted dependencies for our ant build. > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1294) honor restriction of artifacts for pom file creating in makepom task
[ https://issues.apache.org/jira/browse/IVY-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1294. Resolution: Fixed Fix Version/s: trunk Assignee: Maarten Coene I've applied your patch into SVN trunk. Thanks a lot for the contribution! > honor restriction of artifacts for pom file creating in makepom task > > > Key: IVY-1294 > URL: https://issues.apache.org/jira/browse/IVY-1294 > Project: Ivy > Issue Type: Improvement > Components: Ant >Affects Versions: 2.2.0 >Reporter: Jens Rohloff >Assignee: Maarten Coene >Priority: Minor > Fix For: trunk > > Attachments: PomModuleDescriptorWriter.java.patch > > > I'm using maven repository for managing our artifacts and seems to prefer the > use of pom files. > Using the makepom task works great but the PomModuleDescriptorWriter.class > doesn't parse the exclude elements of the dependencies and I'm ending up with > lots of unwanted dependencies for our ant build. > -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1295) Install task fails to escape markup in ivy.xml description tags
[ https://issues.apache.org/jira/browse/IVY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1295. Resolution: Duplicate Fix Version/s: trunk Assignee: Maarten Coene This should already be fixed in trunk, could you give it a try to see if it also fixes your problem? > Install task fails to escape markup in ivy.xml description tags > --- > > Key: IVY-1295 > URL: https://issues.apache.org/jira/browse/IVY-1295 > Project: Ivy > Issue Type: Bug > Components: Ant, Core >Affects Versions: 2.2.0 >Reporter: William Hoyle >Assignee: Maarten Coene >Priority: Critical > Fix For: trunk > > Attachments: test-install.zip > > > XmlModuleDescriptorUpdater is not escaping markup characters like &, < etc. > XmlModuleDescriptorUpdater.UpdaterHandler is ignoring startCDATA() and > startEntity() notifications and characters() simply writes out strings > unescaped. > This can lead to broken xml in installed modules descriptors. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1297) ${ivy.module} variable not resolved while executing ivy:deliver task, for non jar-type artefacts
[
https://issues.apache.org/jira/browse/IVY-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1297.
Resolution: Not A Problem
Assignee: Maarten Coene
I think it's caused by a typo in your ivy file: the javadoc artifact
declaration contains the '${ivy-module}' variable; this should be
'${ivy.module}' instead.
> ${ivy.module} variable not resolved while executing ivy:deliver task, for non
> jar-type artefacts
>
>
> Key: IVY-1297
> URL: https://issues.apache.org/jira/browse/IVY-1297
> Project: Ivy
> Issue Type: Bug
> Components: Ant, Core
>Affects Versions: 2.2.0
> Environment: WinXPsp3 / JDK-Sun-1.6.0_24 / ANT-1.8.2
>Reporter: Emmanuel FOUCHE
>Assignee: Maarten Coene
>Priority: Minor
>
> **
> Ivy file of the module is
> **
>
>
>
>
>description="documentation"/>
>
>description="run"/>
>description="test"/>
>
>
>ext="jar"/>
>ext="jar"/>
>conf="javadoc" ext="zip"/>
>
>
> conf="main-compile->core"/>
> conf="runtime->log4j"/>
> conf="test-compile,test->default"/>
> rev="3.2.1" conf="main-compile->default"/>
>
>
> **
> Ant target calling deliver
> **
>
>
>
>
> --> becomes build/lib/ivy.xml
>
> --> "trunk"
> deliverpattern="${ivy.deliver.ivy.pattern}"
> pubrevision="${ivy.deliver.revision}"
> />
>
> **
> Delivered Ivy file
> **
>
> revision="trunk" status="integration" publication="20110601151114"/>
>
>
>description="documentation"/>
>
>
>
>conf="main-compile" ext="jar"/>
>conf="test-compile" ext="jar"/>
>conf="javadoc" ext="zip"/>
>
>
> conf="main-compile->core"/>
> conf="test-compile->default"/>
> rev="3.2.1" conf="main-compile->default"/>
>
>
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1308) makepom does not export exclusions
[ https://issues.apache.org/jira/browse/IVY-1308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1308. Resolution: Duplicate Assignee: Maarten Coene Closing as duplicate of IVY-1294, which has already been fixed in trunk. > makepom does not export exclusions > -- > > Key: IVY-1308 > URL: https://issues.apache.org/jira/browse/IVY-1308 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.2.0 >Reporter: Douglas Palmer >Assignee: Maarten Coene > > Running makepom on: > > > > Should give: > > org.codehaus.groovy > groovy-all > 1.5.4 > true > > > xpp3 > xpp3_min > > > > But the actual result is missing the exclusion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1307) Ivy does not create subdirectories when publishing to a 'url' repository
[
https://issues.apache.org/jira/browse/IVY-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1307.
Resolution: Duplicate
Assignee: Maarten Coene
Duplicate of IVY-1193.
> Ivy does not create subdirectories when publishing to a 'url' repository
>
>
> Key: IVY-1307
> URL: https://issues.apache.org/jira/browse/IVY-1307
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0, 2.1.0, 2.2.0
>Reporter: Martin Renner
>Assignee: Maarten Coene
>
> It is not possible to publish artifacts using a 'url' resolver with an 'http'
> url. Ivy does not create the necessary subdirectories and thus fails with an
> error.
> If you want to publish _org=somemodule_, _module=artifact_, _revision=1.0_ to
> an HTTP repository with a layout like
> {{/ivy/\[organisation\]/\[module\]/\[revision\]/\[type\]s/\[artifact\].\[ext\]}},
> Ivy is sending one single {{PUT}} request:
> {noformat}PUT /ivy/somemodule/artifact/1.0/jars/artifact.jar{noformat}
> Ivy does not check for or create the subdirectories "{{somemodule}}",
> "{{artifact}}", "{{1.0}}" and "{{jars}}". This makes it impossible to use an
> 'url' resolver to publish artifacts.
> For completeness: The server is Apache 2.2 with WebDAV enabled. So Ivy should
> send "{{MKCOL}}" commands to create intermediate directories.
> There is also a (older)
> [thread|http://old.nabble.com/publishing-via-http-to28114003.html#a28114003]
> on the mailing list for this issue. They come to the conclusion, that an ugly
> hack is needed on the server (using a perl script). IMHO this is not an
> option.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1229) makepom ignores the artifact type in generated dependencies
[
https://issues.apache.org/jira/browse/IVY-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1229.
Resolution: Fixed
Fix Version/s: trunk
Assignee: Maarten Coene
I've applied your in SVN trunk.
Thank you for the contribution!
> makepom ignores the artifact type in generated dependencies
> ---
>
> Key: IVY-1229
> URL: https://issues.apache.org/jira/browse/IVY-1229
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0, 2.2.0-RC1
>Reporter: Andreas Mandel
>Assignee: Maarten Coene
> Fix For: trunk
>
> Attachments: ivy-1229.patch
>
>
> The ant task makepom greates a pom.xml that does not hold the information
> given with the type attribute in the ivy.xml.
> {code:xml|title=ivy.xml}
>...
>
>
>
>...
> {code}
> gets
> {code:xml|title=pom.xml}
>...
>
> docbook
> docbook-xsl
> 1.73.2
> true
>
>...
> {code}
> I would expect:
> {code:xml|title=pom.xml}
>...
>
> docbook
> docbook-xsl
> 1.73.2
> zip
> true
>
>...
> {code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1233) Infinite loop in latest-compatible conflict manager
[
https://issues.apache.org/jira/browse/IVY-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1233.
Resolution: Fixed
Fix Version/s: trunk
Assignee: Maarten Coene
I've applied the patch to SVN trunk which should fix this problem with
latest-compatible conflictmanager when using dynamic revisions.
Thanks for the contribution!
> Infinite loop in latest-compatible conflict manager
> ---
>
> Key: IVY-1233
> URL: https://issues.apache.org/jira/browse/IVY-1233
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.0-RC1
>Reporter: Archie Cobbs
>Assignee: Maarten Coene
> Fix For: trunk
>
> Attachments: ivy-1233-test.patch, ivy-1233.patch, ivybug.zip
>
>
> Attempting to resolve org="com.gargoylesoftware" name="htmlunit" rev="2.7"
> from the Ivy RoundUp repository with the latest-compatible conflict manager
> configured leads to an infinite loop:
> {noformat}
> $ ant
> Buildfile: build.xml
> clean:
> bug:
> [ivy:resolve] :: Ivy 2.2.0-rc1 - 20100629224905 :: http://ant.apache.org/ivy/
> ::
> [ivy:resolve] :: loading settings :: file = /Users/archie/IVYBUG/settings.xml
> [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to
> evict org.apache.xerces#xerces;2.7+ in favor of
> org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for
> default]
> [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to
> evict org.apache.xerces#xerces;2.7+ in favor of
> org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for
> default]
> [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to
> evict org.apache.xerces#xerces;2.7+ in favor of
> org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for
> default]
> [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to
> evict org.apache.xerces#xerces;2.7+ in favor of
> org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for
> default]
> [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to
> evict org.apache.xerces#xerces;2.7+ in favor of
> org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for
> default]
> [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to
> evict org.apache.xerces#xerces;2.7+ in favor of
> org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for
> default]
> [ivy:resolve] BLACKLISTING [org.apache.xerces#xerces;2.7+ blacklisted to
> evict org.apache.xerces#xerces;2.7+ in favor of
> org.apache.xerces#xerces;2.9.1 in com.gargoylesoftware#htmlunit;2.7 for
> default]
> ...
> {noformat}
> See attached test case. To run it, unpack ZIP file, cd into IVYBUG, copy
> {{ant-2.2.0-rc1.jar}} in the current directory and then run "ant".
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1342) IVY:retrieve
[ https://issues.apache.org/jira/browse/IVY-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259974#comment-13259974 ] Maarten Coene commented on IVY-1342: I don't see a reason why it fails. Any chance I could get a login on your server to do some more debugging myself? > IVY:retrieve > > > Key: IVY-1342 > URL: https://issues.apache.org/jira/browse/IVY-1342 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.0 > Environment: Solaris10 and windows SVN repository on CollabNet > Teamforge >Reporter: Sandeep Borgaonkar >Assignee: Maarten Coene > Attachments: errorHttpclient.txt, ivy.logs, ivysettings.xml, > ivysettings.xml, ivysettings.xml, logs.txt > > > While retrieving artefacts thought IVY I'm getting internal server error. > when I access the link directly via browser the artefact is present. > please find below error > CLIENT ERROR: > Authorization Required > url=https://scm-coconet.capgemini.com/svn/repos/fsa_irr2_prod/Resource/branches/release2/artifactHTTP > response status: 401=Authorization Required > url=https://scm-coconet.capgemini.com/svn/repos/fsa_irr2_prod/Resource/branches/release2/ > also below might be helpful > 26-Mar-2012 19:49:16 > org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme > [ivy:retrieve] INFO: Basic authentication scheme selected > [ivy:retrieve] WARN: SERVER ERROR: Internal Server Error > url=https://scm-coconet.capgemini.com/svn/repos/fsa_irr2_prod/Resource/branches/release2/artifact/bea/dsp/jar/dsp-1.0.jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1342) IVY:retrieve
[ https://issues.apache.org/jira/browse/IVY-1342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259987#comment-13259987 ] Maarten Coene commented on IVY-1342: No, I'm afraid there isn't at the moment ... :( > IVY:retrieve > > > Key: IVY-1342 > URL: https://issues.apache.org/jira/browse/IVY-1342 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.0 > Environment: Solaris10 and windows SVN repository on CollabNet > Teamforge >Reporter: Sandeep Borgaonkar >Assignee: Maarten Coene > Attachments: errorHttpclient.txt, ivy.logs, ivysettings.xml, > ivysettings.xml, ivysettings.xml, logs.txt > > > While retrieving artefacts thought IVY I'm getting internal server error. > when I access the link directly via browser the artefact is present. > please find below error > CLIENT ERROR: > Authorization Required > url=https://scm-coconet.capgemini.com/svn/repos/fsa_irr2_prod/Resource/branches/release2/artifactHTTP > response status: 401=Authorization Required > url=https://scm-coconet.capgemini.com/svn/repos/fsa_irr2_prod/Resource/branches/release2/ > also below might be helpful > 26-Mar-2012 19:49:16 > org.apache.commons.httpclient.auth.AuthChallengeProcessor selectAuthScheme > [ivy:retrieve] INFO: Basic authentication scheme selected > [ivy:retrieve] WARN: SERVER ERROR: Internal Server Error > url=https://scm-coconet.capgemini.com/svn/repos/fsa_irr2_prod/Resource/branches/release2/artifact/bea/dsp/jar/dsp-1.0.jar -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1346) Unnecessary warning when parent ivy.xml is located using resolvers rather than a location attribute on the extends element
[
https://issues.apache.org/jira/browse/IVY-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264430#comment-13264430
]
Maarten Coene commented on IVY-1346:
I cannot reproduce this warning.
What JDK version do you use?
> Unnecessary warning when parent ivy.xml is located using resolvers rather
> than a location attribute on the extends element
> --
>
> Key: IVY-1346
> URL: https://issues.apache.org/jira/browse/IVY-1346
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.2.0, 2.3.0-RC1
>Reporter: Matt Hurne
>Priority: Minor
> Attachments: IVY-1346.patch
>
>
> When using an {{}} element without a {{location}} attribute an
> unnecessary warning is output stating that {{../ivy.xml}} could not be parsed
> (unless there is in fact a file {{../ivy.xml}} relative to the {{ivy.xml}}
> that contains the {{}}).
> For example:
> {noformat}
> ...
>
>
>
> ...
> {noformat}
> {noformat}
> [ivy:resolve] Unable to parse included ivy file ../ivy.xml:
> D:\project\component\ivy.xml
> (The system cannot find the file specified) in
> file:/D:/project/component/ivy.xml
> {noformat}
> {{XmlModuleDescriptorParser.extendsStarted()}} is the source of the warning.
> If no {{location}} was specified on the {{}} it uses a default
> location of {{../ivy.xml}}. It then attempts to find and use the
> {{../ivy.xml}} location, and only falls back to resolving the parent
> descriptor if {{../ivy.xml}} doesn't exist or if its {{ModuleId}} is not what
> is expected.
> The behavior is sensible and I do not suggest that it be changed. However,
> it would be nice if the warning that {{../ivy.xml}} could not be parsed were
> suppressed when that file is being used as a default. The warning would
> still be appropriate if {{location="../ivy.xml"}} were explicitly included in
> the {{}} element.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1347) StackOverflowError when using with no location specified
[
https://issues.apache.org/jira/browse/IVY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264431#comment-13264431
]
Maarten Coene commented on IVY-1347:
I cannot reproduce this problem.
Could you check if there is no ivy.xml in the parent directory that introduces
such a loop?
> StackOverflowError when using with no location specified
> --
>
> Key: IVY-1347
> URL: https://issues.apache.org/jira/browse/IVY-1347
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0-RC1
>Reporter: Matt Hurne
>Priority: Critical
>
> When using {{}} without specifying a {{location}}, we end up with a
> {{StackOverflowError}}. For example:
> {noformat}
> ...
>
>
>
> ...
> {noformat}
> {noformat}
> [ivy:buildlist] :: Apache Ivy 2.3.0-rc1 - 20120416000235 ::
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: file = D:\foo\ivysettings.xml
> BUILD FAILED
> java.lang.StackOverflowError
> at java.net.URL.set(URL.java:683)
> at java.net.URLStreamHandler.setURL(URLStreamHandler.java:521)
> at java.net.URLStreamHandler.setURL(URLStreamHandler.java:571)
> at sun.net.www.protocol.jar.Handler.parseURL(Handler.java:76)
> at java.net.URL.(URL.java:596)
> at java.net.URL.(URL.java:464)
> at
> sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:674)
> at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:759)
> at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:735)
> at sun.misc.URLClassPath.findResource(URLClassPath.java:146)
> at java.net.URLClassLoader$2.run(URLClassLoader.java:385)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findResource(URLClassLoader.java:382)
> at java.lang.ClassLoader.getResource(ClassLoader.java:1003)
> at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1193)
> at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:96)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.xml.parsers.SecuritySupport.getResourceAsStream(SecuritySupport.java:89)
> at
> javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:250)
> at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223)
> at
> javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128)
> at org.apache.ivy.util.XMLHelper.newSAXParser(XMLHelper.java:57)
> at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:120)
> at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:96)
> at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:86)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parse(XmlModuleDescriptorParser.java:276)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser.parseDescriptor(XmlModuleDescriptorParser.java:116)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.findResourceUsingPattern(RepositoryResolver.java:109)
> at
> org.apache.ivy.plugins.resolver.AbstractPatternsBasedResolver.findResourceUsingPatterns(AbstractPatternsBasedResolver.java:96)
> at
> org.apache.ivy.plugins.resolver.AbstractPatternsBasedResolver.findIvyFileRef(AbstractPatternsBasedResolver.java:66)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:228)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.resolveParentFromModuleInheritanceRepository(XmlModuleDescriptorParser.java:684)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.extendsStarted(XmlModuleDescriptorParser.java:438)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.startElement(XmlModuleDescriptorParser.java:327)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
> at org.apache.xerces.parsers.AbstractSAXParser.par
[jira] [Commented] (IVY-1346) Unnecessary warning when parent ivy.xml is located using resolvers rather than a location attribute on the extends element
[
https://issues.apache.org/jira/browse/IVY-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13278601#comment-13278601
]
Maarten Coene commented on IVY-1346:
Sorry, I didn't had the time to look into this issue yet.
But it will get fixed before the final 2.3.0 release.
> Unnecessary warning when parent ivy.xml is located using resolvers rather
> than a location attribute on the extends element
> --
>
> Key: IVY-1346
> URL: https://issues.apache.org/jira/browse/IVY-1346
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.2.0, 2.3.0-RC1
>Reporter: Matt Hurne
>Priority: Minor
> Attachments: IVY-1346.patch, IVY-1346.zip
>
>
> When using an {{}} element without a {{location}} attribute an
> unnecessary warning is output stating that {{../ivy.xml}} could not be parsed
> (unless there is in fact a file {{../ivy.xml}} relative to the {{ivy.xml}}
> that contains the {{}}).
> For example:
> {noformat}
> ...
>
>
>
> ...
> {noformat}
> {noformat}
> [ivy:resolve] Unable to parse included ivy file ../ivy.xml:
> D:\project\component\ivy.xml
> (The system cannot find the file specified) in
> file:/D:/project/component/ivy.xml
> {noformat}
> {{XmlModuleDescriptorParser.extendsStarted()}} is the source of the warning.
> If no {{location}} was specified on the {{}} it uses a default
> location of {{../ivy.xml}}. It then attempts to find and use the
> {{../ivy.xml}} location, and only falls back to resolving the parent
> descriptor if {{../ivy.xml}} doesn't exist or if its {{ModuleId}} is not what
> is expected.
> The behavior is sensible and I do not suggest that it be changed. However,
> it would be nice if the warning that {{../ivy.xml}} could not be parsed were
> suppressed when that file is being used as a default. The warning would
> still be appropriate if {{location="../ivy.xml"}} were explicitly included in
> the {{}} element.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1368) Ivy 2.3.0rc1 breaks artifactory ivy support
[ https://issues.apache.org/jira/browse/IVY-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1368. Resolution: Fixed Fix Version/s: 2.3.0 Assignee: Maarten Coene This has already been fixed in trunk some time ago. I've now merged this fix into the 2.3.x branch as well. > Ivy 2.3.0rc1 breaks artifactory ivy support > --- > > Key: IVY-1368 > URL: https://issues.apache.org/jira/browse/IVY-1368 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.3.0-RC1 >Reporter: Radim Kolar >Assignee: Maarten Coene > Fix For: 2.3.0 > > > ivy 2.3.0rc1 do not works with artifactory hudson plugin. Looks like some > method was renamed/removed. > /usr/local/jboss/.jenkins/jobs/Solr/workspace/lucene/common-build.xml:608: > The following error occurred while executing this line: > java.lang.NoSuchMethodError: > org.apache.ivy.ant.IvyAntSettings.getDefaultInstance(Lorg/apache/tools/ant/Task;)Lorg/apache/ivy/ant/IvyAntSettings; > at > org.jfrog.build.extractor.listener.ArtifactoryBuildListener.taskStarted(ArtifactoryBuildListener.java:84) > at org.apache.tools.ant.Project.fireTaskStarted(Project.java:2184) > at org.apache.tools.ant.Task.perform(Task.java:344) > at org.apache.tools.ant.Target.execute(Target.java:392) > at org.apache.tools.ant.Target.performTasks(Target.java:413) > at > org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) > at > org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) > at org.apache.tools.ant.Project.executeTargets(Project.java:1251) > at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) > at > org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1371) Incorrect artifact resolution when using nested elements
[ https://issues.apache.org/jira/browse/IVY-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437095#comment-13437095 ] Maarten Coene commented on IVY-1371: ok, it seems a bug. You can also workaround it by providing a 'mapped' attribute: You will have to use this 'mapped' attribute anyway, because if Ivy worked as documented on this, it would give the 'mapped' attribute a default value of 'transitive', so Ivy would try to resolve the 'transitive' configuration of 'spring-core' which doesn't exist. > Incorrect artifact resolution when using nested elements > --- > > Key: IVY-1371 > URL: https://issues.apache.org/jira/browse/IVY-1371 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.2.0, 2.3.0-RC1 >Reporter: Danny Yates > Attachments: build.xml, ivy.xml > > > Please see attached build.xml and ivy.xml > When resolving the 'transitive' conf, Ivy pulls down Mina, which is not in > that conf, and it additionally pulls down Mina's transitive dependencies even > though the conf that Mina is in has transitivity turned off. > If you use the alternative "inline" syntax for conf mapping, this bug doesn't > happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1371) Incorrect artifact resolution when using nested elements
[ https://issues.apache.org/jira/browse/IVY-1371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437404#comment-13437404 ] Maarten Coene commented on IVY-1371: The documentation says that if no mapped attribute is specified, it will be mapped to the same configuration as specified with the name attribute. This doesn't seem to work, so this is a bug. A quick look at the parser shows me that in some cases (like yours), the element is completely ignored and your dependency will receive the '%->default' configuration, which could explain your observation. I think we can fix this bug in the 2.3.0 release. Beside this bug, you are requesting a new feature: if the mapped attribute isn't specified, the value of the defaultconfmapping attribute should be considered. This is a new feature request, which will probably not make it into the 2.3.0 release since we are already in the stage of release candidates which means we don't add new features anymore. In addition, this change of default value could break existing ivy files, so we have to think about this in more detail, although I agree that using the defaultconfmapping as default seems like a good idea. > Incorrect artifact resolution when using nested elements > --- > > Key: IVY-1371 > URL: https://issues.apache.org/jira/browse/IVY-1371 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.2.0, 2.3.0-RC1 >Reporter: Danny Yates > Attachments: build.xml, ivy.xml > > > Please see attached build.xml and ivy.xml > When resolving the 'transitive' conf, Ivy pulls down Mina, which is not in > that conf, and it additionally pulls down Mina's transitive dependencies even > though the conf that Mina is in has transitivity turned off. > If you use the alternative "inline" syntax for conf mapping, this bug doesn't > happen. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1347) StackOverflowError when using with no location specified
[
https://issues.apache.org/jira/browse/IVY-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1347.
Resolution: Fixed
Fix Version/s: trunk
Assignee: Maarten Coene
Fixed in trunk, could you please give it a try?
> StackOverflowError when using with no location specified
> --
>
> Key: IVY-1347
> URL: https://issues.apache.org/jira/browse/IVY-1347
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0-RC1
>Reporter: Matt Hurne
>Assignee: Maarten Coene
>Priority: Critical
> Labels: testcase
> Fix For: trunk
>
> Attachments: IVY-1347.zip
>
>
> When using {{}} without specifying a {{location}}, we end up with a
> {{StackOverflowError}}. For example:
> {noformat}
> ...
>
>
>
> ...
> {noformat}
> {noformat}
> [ivy:buildlist] :: Apache Ivy 2.3.0-rc1 - 20120416000235 ::
> http://ant.apache.org/ivy/ ::
> [ivy:buildlist] :: loading settings :: file = D:\foo\ivysettings.xml
> BUILD FAILED
> java.lang.StackOverflowError
> at java.net.URL.set(URL.java:683)
> at java.net.URLStreamHandler.setURL(URLStreamHandler.java:521)
> at java.net.URLStreamHandler.setURL(URLStreamHandler.java:571)
> at sun.net.www.protocol.jar.Handler.parseURL(Handler.java:76)
> at java.net.URL.(URL.java:596)
> at java.net.URL.(URL.java:464)
> at
> sun.misc.URLClassPath$JarLoader.checkResource(URLClassPath.java:674)
> at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:759)
> at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:735)
> at sun.misc.URLClassPath.findResource(URLClassPath.java:146)
> at java.net.URLClassLoader$2.run(URLClassLoader.java:385)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findResource(URLClassLoader.java:382)
> at java.lang.ClassLoader.getResource(ClassLoader.java:1003)
> at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1193)
> at javax.xml.parsers.SecuritySupport$4.run(SecuritySupport.java:96)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.xml.parsers.SecuritySupport.getResourceAsStream(SecuritySupport.java:89)
> at
> javax.xml.parsers.FactoryFinder.findJarServiceProvider(FactoryFinder.java:250)
> at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:223)
> at
> javax.xml.parsers.SAXParserFactory.newInstance(SAXParserFactory.java:128)
> at org.apache.ivy.util.XMLHelper.newSAXParser(XMLHelper.java:57)
> at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:120)
> at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:96)
> at org.apache.ivy.util.XMLHelper.parse(XMLHelper.java:86)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.parse(XmlModuleDescriptorParser.java:276)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser.parseDescriptor(XmlModuleDescriptorParser.java:116)
> at
> org.apache.ivy.plugins.resolver.RepositoryResolver.findResourceUsingPattern(RepositoryResolver.java:109)
> at
> org.apache.ivy.plugins.resolver.AbstractPatternsBasedResolver.findResourceUsingPatterns(AbstractPatternsBasedResolver.java:96)
> at
> org.apache.ivy.plugins.resolver.AbstractPatternsBasedResolver.findIvyFileRef(AbstractPatternsBasedResolver.java:66)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:228)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.resolveParentFromModuleInheritanceRepository(XmlModuleDescriptorParser.java:684)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.extendsStarted(XmlModuleDescriptorParser.java:438)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.startElement(XmlModuleDescriptorParser.java:327)
> at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown
> Source)
> at
> org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanStartElement(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown
> Source)
> at
> org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown
> Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
> at org.apache.xerces.parsers.XML
[jira] [Resolved] (IVY-1346) Unnecessary warning when parent ivy.xml is located using resolvers rather than a location attribute on the extends element
[
https://issues.apache.org/jira/browse/IVY-1346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1346.
Resolution: Fixed
Fix Version/s: trunk
Assignee: Maarten Coene
I think this is fixed in trunk, but since I couldn't reproduce the problem,
could you please give it a try to see if the warning has disappeared?
> Unnecessary warning when parent ivy.xml is located using resolvers rather
> than a location attribute on the extends element
> --
>
> Key: IVY-1346
> URL: https://issues.apache.org/jira/browse/IVY-1346
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.2.0, 2.3.0-RC1
>Reporter: Matt Hurne
>Assignee: Maarten Coene
>Priority: Minor
> Labels: patch
> Fix For: trunk
>
> Attachments: IVY-1346.patch, IVY-1346.zip
>
>
> When using an {{}} element without a {{location}} attribute an
> unnecessary warning is output stating that {{../ivy.xml}} could not be parsed
> (unless there is in fact a file {{../ivy.xml}} relative to the {{ivy.xml}}
> that contains the {{}}).
> For example:
> {noformat}
> ...
>
>
>
> ...
> {noformat}
> {noformat}
> [ivy:resolve] Unable to parse included ivy file ../ivy.xml:
> D:\project\component\ivy.xml
> (The system cannot find the file specified) in
> file:/D:/project/component/ivy.xml
> {noformat}
> {{XmlModuleDescriptorParser.extendsStarted()}} is the source of the warning.
> If no {{location}} was specified on the {{}} it uses a default
> location of {{../ivy.xml}}. It then attempts to find and use the
> {{../ivy.xml}} location, and only falls back to resolving the parent
> descriptor if {{../ivy.xml}} doesn't exist or if its {{ModuleId}} is not what
> is expected.
> The behavior is sensible and I do not suggest that it be changed. However,
> it would be nice if the warning that {{../ivy.xml}} could not be parsed were
> suppressed when that file is being used as a default. The warning would
> still be appropriate if {{location="../ivy.xml"}} were explicitly included in
> the {{}} element.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1362) Memory leak and infinite loop in ModuleId.java
[
https://issues.apache.org/jira/browse/IVY-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1362.
Resolution: Fixed
Fix Version/s: 2.3.0
Assignee: Maarten Coene
Fixed in the next release. Thanks for reporting.
> Memory leak and infinite loop in ModuleId.java
> --
>
> Key: IVY-1362
> URL: https://issues.apache.org/jira/browse/IVY-1362
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.0
> Environment: Eclipse / IvyDE
>Reporter: Marcell Hegedus
>Assignee: Maarten Coene
> Fix For: 2.3.0
>
>
> ModuleId tries save memory by interning objects. This ModuleId cache is not
> synchronized and when it is mutated from concurrent threads it is possible
> that the WeakHashMap will contain a loop. As described in the blog post: ["A
> Beautiful Race
> Condition"|http://mailinator.blogspot.hu/2009/06/beautiful-race-condition.html]
> The same issue and a memory leak was fixed in IVY-791.
> {code:title=Stacktrace of a hanging thread}
> java.lang.Thread.State: RUNNABLE
> at java.util.WeakHashMap.get(Unknown Source)
> at org.apache.ivy.core.module.id.ModuleId.intern(ModuleId.java:63)
> at org.apache.ivy.core.module.id.ModuleId.newInstance(ModuleId.java:48)
> at
> org.apache.ivy.core.module.id.ModuleRevisionId.newInstance(ModuleRevisionId.java:100)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorBuilder.addDependency(PomModuleDescriptorBuilder.java:285)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:262)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:108)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:659)
> at
> org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:676)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:993)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:546)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:266)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:503)
> at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
> at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
> 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:287)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:696)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:769)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:769)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:576)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:237)
> at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyResolveJobThread.resolve(IvyResolveJobThread.java:224)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyResolveJobThread.run(IvyResolveJobThread.java:127)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA,
[jira] [Commented] (IVY-899) POM packaging not always mapped to main artifact file extension correctly
[ https://issues.apache.org/jira/browse/IVY-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437529#comment-13437529 ] Maarten Coene commented on IVY-899: --- Mapping for 'orbit' and 'pear' has been added. Patches for a more general solution are always welcome :-) > POM packaging not always mapped to main artifact file extension correctly > - > > Key: IVY-899 > URL: https://issues.apache.org/jira/browse/IVY-899 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.0.0-beta-2 >Reporter: Tom Widmer > > POM files contain a packaging element that Ivy attempts to map to an > extension for the main artifact of the module in question. In 2.0.0beta2, it > maps as follows: > ejb->jar > bundle->jar only for org.apache.felix#maven-bundle-plugin > [other]->[other] > That mapping is not sufficient to cover common POM files. For a start: > 1. maven-plugin is a standard packaging type, which should map to the > extension jar. > - e.g. Ivy erroneously searches for > org.apache.axis2#axis2-ant-plugin;1.4.1!axis2-ant-plugin.maven-plugin > rather than: > org.apache.axis2#axis2-ant-plugin;1.4.1!axis2-ant-plugin.jar > 2. bundle seems to be used by various things, and is a jar in the cases I've > seen: > org.apache.geronimo.specs#geronimo-activation_1.1_spec;1.0.1!geronimo-activation_1.1_spec.bundle > should be > org.apache.geronimo.specs#geronimo-activation_1.1_spec;1.0.1!geronimo-activation_1.1_spec.jar > Also, apparently POMs can have custom packaging which might need to map to > some other arbitrary file extension, or possibly potentially to multiple > files? > The ideal solution is to provide customisable mapping of POM packaging to > file extensions that can be specified somewhere in the Ivy settings (it is > somewhat similar to namespaces). > An interim solution is to change the mapping as follows: > ejb->jar > ejb[N]->jar?? e.g. ejb3->jar > maven-plugin->jar > bundle->jar if and only if .bundle does not exist but .jar does (it may not > be easy to check for file existence in the relevant code - I'd be happy to > always map bundle to jar, but others might not be - might be fine for an > interim solution though?). > [other]->[other] > The interim solution could perhaps be done for 2.0 (it is only a few minutes > work I think), though the properly customisable solution might take longer > than that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IVY-1362) Memory leak and infinite loop in ModuleId.java
[
https://issues.apache.org/jira/browse/IVY-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437595#comment-13437595
]
Maarten Coene commented on IVY-1362:
Thanks for verifying, it did my homework again and hopefully it is ok now?
> Memory leak and infinite loop in ModuleId.java
> --
>
> Key: IVY-1362
> URL: https://issues.apache.org/jira/browse/IVY-1362
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.0
> Environment: Eclipse / IvyDE
>Reporter: Marcell Hegedus
>Assignee: Maarten Coene
> Fix For: 2.3.0
>
>
> ModuleId tries save memory by interning objects. This ModuleId cache is not
> synchronized and when it is mutated from concurrent threads it is possible
> that the WeakHashMap will contain a loop. As described in the blog post: ["A
> Beautiful Race
> Condition"|http://mailinator.blogspot.hu/2009/06/beautiful-race-condition.html]
> The same issue and a memory leak was fixed in IVY-791.
> {code:title=Stacktrace of a hanging thread}
> java.lang.Thread.State: RUNNABLE
> at java.util.WeakHashMap.get(Unknown Source)
> at org.apache.ivy.core.module.id.ModuleId.intern(ModuleId.java:63)
> at org.apache.ivy.core.module.id.ModuleId.newInstance(ModuleId.java:48)
> at
> org.apache.ivy.core.module.id.ModuleRevisionId.newInstance(ModuleRevisionId.java:100)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorBuilder.addDependency(PomModuleDescriptorBuilder.java:285)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:262)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:108)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:659)
> at
> org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:676)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:993)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:546)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:266)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:503)
> at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
> at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
> 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:287)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:696)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:769)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:769)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:576)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:237)
> at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyResolveJobThread.resolve(IvyResolveJobThread.java:224)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyResolveJobThread.run(IvyResolveJobThread.java:127)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, se
[jira] [Comment Edited] (IVY-1362) Memory leak and infinite loop in ModuleId.java
[
https://issues.apache.org/jira/browse/IVY-1362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13437595#comment-13437595
]
Maarten Coene edited comment on IVY-1362 at 8/20/12 9:04 AM:
-
Thanks for verifying, I did my homework again and hopefully it is ok now?
was (Author: maartenc):
Thanks for verifying, it did my homework again and hopefully it is ok now?
> Memory leak and infinite loop in ModuleId.java
> --
>
> Key: IVY-1362
> URL: https://issues.apache.org/jira/browse/IVY-1362
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.0
> Environment: Eclipse / IvyDE
>Reporter: Marcell Hegedus
>Assignee: Maarten Coene
> Fix For: 2.3.0
>
>
> ModuleId tries save memory by interning objects. This ModuleId cache is not
> synchronized and when it is mutated from concurrent threads it is possible
> that the WeakHashMap will contain a loop. As described in the blog post: ["A
> Beautiful Race
> Condition"|http://mailinator.blogspot.hu/2009/06/beautiful-race-condition.html]
> The same issue and a memory leak was fixed in IVY-791.
> {code:title=Stacktrace of a hanging thread}
> java.lang.Thread.State: RUNNABLE
> at java.util.WeakHashMap.get(Unknown Source)
> at org.apache.ivy.core.module.id.ModuleId.intern(ModuleId.java:63)
> at org.apache.ivy.core.module.id.ModuleId.newInstance(ModuleId.java:48)
> at
> org.apache.ivy.core.module.id.ModuleRevisionId.newInstance(ModuleRevisionId.java:100)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorBuilder.addDependency(PomModuleDescriptorBuilder.java:285)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:262)
> at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:108)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:659)
> at
> org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:676)
> at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:993)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:546)
> at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:266)
> at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:503)
> at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
> at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:104)
> 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:287)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:696)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:769)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:769)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:781)
> at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:704)
> at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:576)
> at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:237)
> at org.apache.ivy.Ivy.resolve(Ivy.java:512)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyResolveJobThread.resolve(IvyResolveJobThread.java:224)
> at
> org.apache.ivyde.eclipse.cpcontainer.IvyResolveJobThread.run(IvyResolveJobThread.java:127)
> {code}
--
This message is automatically generated by JIRA.
If you th
[jira] [Resolved] (IVY-1357) hk2-jar can't be resolved
[ https://issues.apache.org/jira/browse/IVY-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-1357. Resolution: Fixed Fix Version/s: 2.3.0 Assignee: Maarten Coene Will be fixed in next release, thanks for reporting! > hk2-jar can't be resolved > - > > Key: IVY-1357 > URL: https://issues.apache.org/jira/browse/IVY-1357 > Project: Ivy > Issue Type: Bug > Components: Core, Maven Compatibility >Affects Versions: 2.2.0 >Reporter: Daniel Schaarschmidt >Assignee: Maarten Coene > Fix For: 2.3.0 > > > I'm trying to resolve the following dependency which works fine with Maven: > > But with Ivy I get the following error: > [FAILED ] org.glassfish.ha#ha-api;3.1.8!ha-api.hk2-jar: > The correct file extension is "jar", not "hk2-jar" which Ivy obviously is > looking for. > In this setting the affected transitive dependencies are: > > > > > > > > A similar problem description can be found here: > https://groups.google.com/forum/#!topic/simple-build-tool/AYLw15EJcvg > Their solution: force hk2-jars to be treated like standard jars. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1360) NPE when using the updatesite resolver
[
https://issues.apache.org/jira/browse/IVY-1360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1360.
Resolution: Duplicate
Fix Version/s: 2.3.0
Assignee: Maarten Coene
Seems like a duplicate of IVY-1343, which has already been fixed.
> NPE when using the updatesite resolver
> --
>
> Key: IVY-1360
> URL: https://issues.apache.org/jira/browse/IVY-1360
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0-RC1
> Environment: Command line build with Apache Ant(TM) version 1.8.2
> compiled on December 20 2010
>Reporter: Christopher Frost
>Assignee: Maarten Coene
> Fix For: 2.3.0
>
>
> The error is shown below, nothing else is output from the build. I've been
> playing around with the new OSGi support trying to get one of the Eclipse
> Virgo projects to build with it. This is a very simple build, no module
> definitions in the ivysettings file and I'm using the new updatesite resolver.
> url="http://download.eclipse.org/tools/orbit/downloads/drops/${orbit.repo}/repository";
> requirementStrategy="first" />
> I can't remember what I did to cause this error, really sorry. Just didn't
> want to leave an NPE. Many thanks for the new resolvers though, proper
> treatment of ambiguity is much appreciated.
> [ivy:resolve] ::
> bundle#org.eclipse.virgo.bundlor.ant;1.1.0.M05:
> java.lang.NullPointerException at
> org.apache.ivy.osgi.repo.AbstractOSGiResolver.findIvyFileRef(AbstractOSGiResolver.java:132)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (IVY-1373) SimpleDateFormat not thread safe
[
https://issues.apache.org/jira/browse/IVY-1373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-1373.
Resolution: Fixed
Fix Version/s: 2.3.0
Assignee: Maarten Coene
Will be fixed in the next release.
Thanks for reporting!
> SimpleDateFormat not thread safe
>
>
> Key: IVY-1373
> URL: https://issues.apache.org/jira/browse/IVY-1373
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.3.0-RC1
>Reporter: Wolfgang Frank
>Assignee: Maarten Coene
> Fix For: 2.3.0
>
>
> Class {{org.apache.ivy.Ivy}} defines
> {noformat}public static final SimpleDateFormat DATE_FORMAT = new
> SimpleDateFormat("MMddHHmmss");{noformat}
> SimpleDateFormat is not thread safe. Errors might occur like
> {noformat}
> Caused by: java.lang.NumberFormatException: multiple points
> at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1101)
> at java.lang.Double.parseDouble(Double.java:540)
> at java.text.DigitList.getDouble(DigitList.java:168)
> at java.text.DecimalFormat.parse(DecimalFormat.java:1321)
> at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1791)
> at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1455)
> at java.text.DateFormat.parse(DateFormat.java:355)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.infoStarted(XmlModuleDescriptorParser.java:935)
> at
> org.apache.ivy.plugins.parser.xml.XmlModuleDescriptorParser$Parser.startElement(XmlModuleDescriptorParser.java:297)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (IVY-955) maven pom parser is not handling pom properties (e.g $(project.parent.version} )
[
https://issues.apache.org/jira/browse/IVY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene reassigned IVY-955:
-
Assignee: Maarten Coene
> maven pom parser is not handling pom properties (e.g
> $(project.parent.version} )
>
>
> Key: IVY-955
> URL: https://issues.apache.org/jira/browse/IVY-955
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.0-RC1
> Environment: All
>Reporter: Gopalakrishnan
>Assignee: Maarten Coene
>
> Maven pom parser is NOT substituting pom properties with actual values after
> parsing.
> For e.g when I add a maven artifact with the following pom as dependency in
> ivy.xml,
>
> com.example
> aparent
> 1.0.0
>
> com.example
> myartifact
> jar
> Example
> Example.
>
>
> com.example
> a2
> ${project.parent.version}
> compile
>
>
> ivy fails to resolve a2 dependency. Ivy seems to be looking for artifact
> com.example.a2-${project.parent.version} instead of searching for
> com.example.a2-1.0.0 i.e substitute the property with actual value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-955) maven pom parser is not handling pom property ${project.parent.version}
[
https://issues.apache.org/jira/browse/IVY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-955:
--
Fix Version/s: 2.0-RC2
Summary: maven pom parser is not handling pom property
${project.parent.version} (was: maven pom parser is not handling pom
properties (e.g $(project.parent.version} ))
> maven pom parser is not handling pom property ${project.parent.version}
> ---
>
> Key: IVY-955
> URL: https://issues.apache.org/jira/browse/IVY-955
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.0-RC1
> Environment: All
>Reporter: Gopalakrishnan
>Assignee: Maarten Coene
> Fix For: 2.0-RC2
>
>
> Maven pom parser is NOT substituting pom properties with actual values after
> parsing.
> For e.g when I add a maven artifact with the following pom as dependency in
> ivy.xml,
>
> com.example
> aparent
> 1.0.0
>
> com.example
> myartifact
> jar
> Example
> Example.
>
>
> com.example
> a2
> ${project.parent.version}
> compile
>
>
> ivy fails to resolve a2 dependency. Ivy seems to be looking for artifact
> com.example.a2-${project.parent.version} instead of searching for
> com.example.a2-1.0.0 i.e substitute the property with actual value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-955) maven pom parser is not handling pom property ${project.parent.version}
[
https://issues.apache.org/jira/browse/IVY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-955.
---
Resolution: Fixed
I've committed a fix into SVN (2.0.0-rc2 branch).
Thanks for reporting!
> maven pom parser is not handling pom property ${project.parent.version}
> ---
>
> Key: IVY-955
> URL: https://issues.apache.org/jira/browse/IVY-955
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.0-RC1
> Environment: All
>Reporter: Gopalakrishnan
>Assignee: Maarten Coene
> Fix For: 2.0-RC2
>
>
> Maven pom parser is NOT substituting pom properties with actual values after
> parsing.
> For e.g when I add a maven artifact with the following pom as dependency in
> ivy.xml,
>
> com.example
> aparent
> 1.0.0
>
> com.example
> myartifact
> jar
> Example
> Example.
>
>
> com.example
> a2
> ${project.parent.version}
> compile
>
>
> ivy fails to resolve a2 dependency. Ivy seems to be looking for artifact
> com.example.a2-${project.parent.version} instead of searching for
> com.example.a2-1.0.0 i.e substitute the property with actual value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-955) maven pom parser is not handling pom properties (e.g $(project.parent.version} )
[
https://issues.apache.org/jira/browse/IVY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642249#action_12642249
]
Maarten Coene commented on IVY-955:
---
The problem still exist on latest trunk, so IVY-914 was another issue.
> maven pom parser is not handling pom properties (e.g
> $(project.parent.version} )
>
>
> Key: IVY-955
> URL: https://issues.apache.org/jira/browse/IVY-955
> Project: Ivy
> Issue Type: Improvement
> Components: Maven Compatibility
>Affects Versions: 2.0-RC1
> Environment: All
>Reporter: Gopalakrishnan
>Assignee: Maarten Coene
>
> Maven pom parser is NOT substituting pom properties with actual values after
> parsing.
> For e.g when I add a maven artifact with the following pom as dependency in
> ivy.xml,
>
> com.example
> aparent
> 1.0.0
>
> com.example
> myartifact
> jar
> Example
> Example.
>
>
> com.example
> a2
> ${project.parent.version}
> compile
>
>
> ivy fails to resolve a2 dependency. Ivy seems to be looking for artifact
> com.example.a2-${project.parent.version} instead of searching for
> com.example.a2-1.0.0 i.e substitute the property with actual value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-955) maven pom parser is not handling pom property ${project.parent.version}
[
https://issues.apache.org/jira/browse/IVY-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-955:
--
Issue Type: Bug (was: Improvement)
> maven pom parser is not handling pom property ${project.parent.version}
> ---
>
> Key: IVY-955
> URL: https://issues.apache.org/jira/browse/IVY-955
> Project: Ivy
> Issue Type: Bug
> Components: Maven Compatibility
>Affects Versions: 2.0-RC1
> Environment: All
>Reporter: Gopalakrishnan
>Assignee: Maarten Coene
> Fix For: 2.0-RC2
>
>
> Maven pom parser is NOT substituting pom properties with actual values after
> parsing.
> For e.g when I add a maven artifact with the following pom as dependency in
> ivy.xml,
>
> com.example
> aparent
> 1.0.0
>
> com.example
> myartifact
> jar
> Example
> Example.
>
>
> com.example
> a2
> ${project.parent.version}
> compile
>
>
> ivy fails to resolve a2 dependency. Ivy seems to be looking for artifact
> com.example.a2-${project.parent.version} instead of searching for
> com.example.a2-1.0.0 i.e substitute the property with actual value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-956) Latest Compatible Conflict Manager + Extra Attributes in Dependencies' IVY files == inifinite loop
[
https://issues.apache.org/jira/browse/IVY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642337#action_12642337
]
Maarten Coene commented on IVY-956:
---
The problem is even worse in current SVN trunk: both your tests gets into an
infinite loop.
I've tried to commit a fix into SVN trunk, could you please give it a try and
post your feedback quickly so I can add it to RC2 tomorrow.
> Latest Compatible Conflict Manager + Extra Attributes in Dependencies' IVY
> files == inifinite loop
> --
>
> Key: IVY-956
> URL: https://issues.apache.org/jira/browse/IVY-956
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0-RC1
> Environment: Windows XP
> Java 6
>Reporter: Scott Hebert
> Attachments: extra-att-multipledependencies.zip
>
>
> When using the Latest Compatible Conflict Manager with the resolution of
> modules/revisions that contain extra attributes, you get into an infinite
> loop.
> The dependencies on my repository contains this in their element:
> {code:xml}
> status="Development" publication="20081016173017" buddies=""
> approver="Somebody">
> {code}
> If the ivy.xml that I would like to resolve contains this:
> {code:xml}
>
>force="true" conf="BuildTimeDependencies->*" policydependency="true">
>
>transitive="false" force="true" conf="BuildTimeDependencies->*">
>
>
> {code}
> then the ResolveEngine gets into an infinite loop with this being displayed
> over and over again:
> {noformat}
> [ivy:resolve] found CAE-VSK#VSK-FC#MAIN;0.54.1.0 in attribs
> [ivy:resolve] [0.54.1.0] CAE-VSK#VSK-FC#MAIN;[0.50.0.0,0.55.0.0]
> [ivy:resolve] BLACKLISTING [CAE-VSK#VSK-FC#MAIN;0.54.1.0 blacklisted to evict
> CAE-VSK#VSK-FC#MAIN;0.54.1.0 in favor of CAE-VSK#VSK-FC#MAIN;0.53.0.1 in
> CAE#TESTA#MAIN;[EMAIL PROTECTED] for BuildTimeDependencies]
> {noformat}
> I'm going to attach 2 tests -- one that operates on a repository that
> contains revs with NO attribs and one that operates on a repository that
> contains revs WITH attribs.
> Thanks,
> Scott
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-958) inline resolve ignores the transitive attribute
inline resolve ignores the transitive attribute --- Key: IVY-958 URL: https://issues.apache.org/jira/browse/IVY-958 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 2.0-RC1 Reporter: Maarten Coene Assignee: Maarten Coene Fix For: 2.0-RC2 If you do an inline resolve (post-resolve-task), the transitive attribute is ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-958) inline resolve ignores the transitive attribute
[ https://issues.apache.org/jira/browse/IVY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-958. --- Resolution: Fixed > inline resolve ignores the transitive attribute > --- > > Key: IVY-958 > URL: https://issues.apache.org/jira/browse/IVY-958 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0-RC1 >Reporter: Maarten Coene >Assignee: Maarten Coene > Fix For: 2.0-RC2 > > > If you do an inline resolve (post-resolve-task), the transitive attribute is > ignored. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-956) Latest Compatible Conflict Manager + Extra Attributes in Dependencies' IVY files == inifinite loop
[
https://issues.apache.org/jira/browse/IVY-956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12643671#action_12643671
]
Maarten Coene commented on IVY-956:
---
No sorry, I had been too busy with creating the RC2 release.
But I think it would be best that Xavier takes a look at this, because I must
admit I don't know that peace of Ivy good enough to see how to fix it.
> Latest Compatible Conflict Manager + Extra Attributes in Dependencies' IVY
> files == inifinite loop
> --
>
> Key: IVY-956
> URL: https://issues.apache.org/jira/browse/IVY-956
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0-RC1
> Environment: Windows XP
> Java 6
>Reporter: Scott Hebert
> Attachments: extra-att-multipledependencies.zip
>
>
> When using the Latest Compatible Conflict Manager with the resolution of
> modules/revisions that contain extra attributes, you get into an infinite
> loop.
> The dependencies on my repository contains this in their element:
> {code:xml}
> status="Development" publication="20081016173017" buddies=""
> approver="Somebody">
> {code}
> If the ivy.xml that I would like to resolve contains this:
> {code:xml}
>
>force="true" conf="BuildTimeDependencies->*" policydependency="true">
>
>transitive="false" force="true" conf="BuildTimeDependencies->*">
>
>
> {code}
> then the ResolveEngine gets into an infinite loop with this being displayed
> over and over again:
> {noformat}
> [ivy:resolve] found CAE-VSK#VSK-FC#MAIN;0.54.1.0 in attribs
> [ivy:resolve] [0.54.1.0] CAE-VSK#VSK-FC#MAIN;[0.50.0.0,0.55.0.0]
> [ivy:resolve] BLACKLISTING [CAE-VSK#VSK-FC#MAIN;0.54.1.0 blacklisted to evict
> CAE-VSK#VSK-FC#MAIN;0.54.1.0 in favor of CAE-VSK#VSK-FC#MAIN;0.53.0.1 in
> CAE#TESTA#MAIN;[EMAIL PROTECTED] for BuildTimeDependencies]
> {noformat}
> I'm going to attach 2 tests -- one that operates on a repository that
> contains revs with NO attribs and one that operates on a repository that
> contains revs WITH attribs.
> Thanks,
> Scott
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-960) Log levels aren't respected in certain cases using the standalone functionality
[ https://issues.apache.org/jira/browse/IVY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-960: -- Fix Version/s: (was: 2.0.x) unspecified > Log levels aren't respected in certain cases using the standalone > functionality > --- > > Key: IVY-960 > URL: https://issues.apache.org/jira/browse/IVY-960 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1 > Environment: Windows XP > java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode) >Reporter: Patrick Woodworth > Fix For: unspecified > > Attachments: ivypushcntxt.patch > > > When using Ivy in standalone mode and passing the -dependency option, it is > impossible to suppress a "loading settings" banner from being the first line > of output, regardless of whether the -warn or -error flags have been passed. > For some reason this is not a problem when using the -ivy option instead of > -dependency. The attached patch solves the problem in my environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-960) Log levels aren't respected in certain cases using the standalone functionality
[ https://issues.apache.org/jira/browse/IVY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-960. --- Resolution: Fixed Fix Version/s: (was: unspecified) trunk Assignee: Maarten Coene I've applied your patch into SVN trunk. Thank you for the contribution! > Log levels aren't respected in certain cases using the standalone > functionality > --- > > Key: IVY-960 > URL: https://issues.apache.org/jira/browse/IVY-960 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1 > Environment: Windows XP > java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode) >Reporter: Patrick Woodworth >Assignee: Maarten Coene > Fix For: trunk > > Attachments: ivypushcntxt.patch > > > When using Ivy in standalone mode and passing the -dependency option, it is > impossible to suppress a "loading settings" banner from being the first line > of output, regardless of whether the -warn or -error flags have been passed. > For some reason this is not a problem when using the -ivy option instead of > -dependency. The attached patch solves the problem in my environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-959) Listing of URL's under a given URL does not handle fully specified URL's
[ https://issues.apache.org/jira/browse/IVY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-959. --- Resolution: Fixed Fix Version/s: trunk Thanks for your contribution! I've applied your patch into SVN trunk with an extra check that the fully-specified-URL must point to a sub-location of the base URL. Could you please give it a try to check if it works for your situation and post your findings here? > Listing of URL's under a given URL does not handle fully specified URL's > > > Key: IVY-959 > URL: https://issues.apache.org/jira/browse/IVY-959 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1 >Reporter: Randy Nott >Assignee: Maarten Coene > Fix For: trunk > > Attachments: ApacheURLLister.patch > > > Listing of URL's under a given URL does not handle fully specified URL's thus > failing resolution of dynamic versions with certain repositories. The > following example is a directory listing returned by the Sonatype Nexus > repository manager: > > > Index of > /nexus/content/repositories/releases/myorganization/mymodule/ > > > Index of > /nexus/content/repositories/releases/myorganization/mymodule/ > > > Name > Last Modified > Size > Description > > > >href="http://example.com/nexus/content/repositories/releases/myorganization/";>Parent > Directory > > > > > >href="http://example.com/nexus/content/repositories/releases/myorganization/mymodule/1.0/";>1.0/ > > > Tue Oct 28 00:41:33 PDT 2008 > > > - > > > > > > The current implementation fails as it only supports the URL as a path (no > protocol or server/port). > A patch to add support for full URL's is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-959) Listing of URL's under a given URL does not handle fully specified URL's
[ https://issues.apache.org/jira/browse/IVY-959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-959: -- Assignee: Maarten Coene Remaining Estimate: (was: 0.5h) Original Estimate: (was: 0.5h) > Listing of URL's under a given URL does not handle fully specified URL's > > > Key: IVY-959 > URL: https://issues.apache.org/jira/browse/IVY-959 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1 >Reporter: Randy Nott >Assignee: Maarten Coene > Fix For: trunk > > Attachments: ApacheURLLister.patch > > > Listing of URL's under a given URL does not handle fully specified URL's thus > failing resolution of dynamic versions with certain repositories. The > following example is a directory listing returned by the Sonatype Nexus > repository manager: > > > Index of > /nexus/content/repositories/releases/myorganization/mymodule/ > > > Index of > /nexus/content/repositories/releases/myorganization/mymodule/ > > > Name > Last Modified > Size > Description > > > >href="http://example.com/nexus/content/repositories/releases/myorganization/";>Parent > Directory > > > > > >href="http://example.com/nexus/content/repositories/releases/myorganization/mymodule/1.0/";>1.0/ > > > Tue Oct 28 00:41:33 PDT 2008 > > > - > > > > > > The current implementation fails as it only supports the URL as a path (no > protocol or server/port). > A patch to add support for full URL's is attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-961) NPE in LogReportOutputter
[
https://issues.apache.org/jira/browse/IVY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644091#action_12644091
]
Maarten Coene commented on IVY-961:
---
I couldn't reproduce your problem. I didn't get a NPE when setting it to "true".
Could you give more information, like ivy.xml, settings.xml, console log, ...
> NPE in LogReportOutputter
> -
>
> Key: IVY-961
> URL: https://issues.apache.org/jira/browse/IVY-961
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0-RC1
>Reporter: Hans Dockter
>
> If the variable {{}} is
> set to true, the LogReportOutputter throws an NPE in line 70.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-962) Files with non-latin symbols fail to download
[
https://issues.apache.org/jira/browse/IVY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644119#action_12644119
]
Maarten Coene commented on IVY-962:
---
Can you put such an ivy.xml and corresponding artifact on a public HTTP server
somewhere?
It would make it easier to reproduce/fix it...
> Files with non-latin symbols fail to download
> -
>
> Key: IVY-962
> URL: https://issues.apache.org/jira/browse/IVY-962
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: Yegor Yarko
> Attachments: .ivy.zip, ivy.xml, output.txt
>
>
> When I try to download a file with russian characters via Ivy (via Ant
> tasks), Ivy fails to download it
> Server's ivy.xml part:
> {code:xml}
>
> {code}
> Console output
> {noformat}
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: FAILED DOWNLOADS::
> [ivy:retrieve] WARN::: ^ see resolution messages for details ^ ::
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: org#bt413;8!Ёєёёъшщ.txt
> [ivy:retrieve] WARN:::
> {noformat}
> Please find the client's ivy.xml, Ivy cache and output in the attachments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-963) not all attirubtes of publish task are documented
not all attirubtes of publish task are documented - Key: IVY-963 URL: https://issues.apache.org/jira/browse/IVY-963 Project: Ivy Issue Type: Improvement Components: Documentation Affects Versions: 2.0-RC1 Reporter: Maarten Coene The publish task has the following attributes: "organisation", "module" and "revision" which aren't mentioned in the documentation. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-962) Files with non-latin symbols fail to download
[
https://issues.apache.org/jira/browse/IVY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1261#action_1261
]
Maarten Coene commented on IVY-962:
---
Are you sure the artifact with the russian characters in it's name is
available? If I try to access it with my browser at following URL:
http://teamcity.jetbrains.com/tmp/IVY-962/bt413/8/%d1%80%d1%83%d1%81%d1%81%d0%ba%d0%b8%d0%b9.txt
(which is the "URL-encoded" form of the artifact I think), I'm getting a HTTP
404 error.
> Files with non-latin symbols fail to download
> -
>
> Key: IVY-962
> URL: https://issues.apache.org/jira/browse/IVY-962
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: Yegor Yarko
> Attachments: .ivy.zip, ivy.xml, output.txt, testOnPublicServer.zip
>
>
> When I try to download a file with russian characters via Ivy (via Ant
> tasks), Ivy fails to download it
> Server's ivy.xml part:
> {code:xml}
>
> {code}
> Console output
> {noformat}
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: FAILED DOWNLOADS::
> [ivy:retrieve] WARN::: ^ see resolution messages for details ^ ::
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: org#bt413;8!Ёєёёъшщ.txt
> [ivy:retrieve] WARN:::
> {noformat}
> Please find the client's ivy.xml, Ivy cache and output in the attachments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-962) Files with non-latin symbols fail to download
[
https://issues.apache.org/jira/browse/IVY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644709#action_12644709
]
Maarten Coene commented on IVY-962:
---
Thank you for the update.
Can you confirm that with the settings above Ivy-2.0-RC1 fails to download the
artifact?
> Files with non-latin symbols fail to download
> -
>
> Key: IVY-962
> URL: https://issues.apache.org/jira/browse/IVY-962
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: Yegor Yarko
> Attachments: .ivy.zip, ivy.xml, output.txt, testOnPublicServer.zip,
> русский.txt
>
>
> When I try to download a file with russian characters via Ivy (via Ant
> tasks), Ivy fails to download it
> Server's ivy.xml part:
> {code:xml}
>
> {code}
> Console output
> {noformat}
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: FAILED DOWNLOADS::
> [ivy:retrieve] WARN::: ^ see resolution messages for details ^ ::
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: org#bt413;8!Ёєёёъшщ.txt
> [ivy:retrieve] WARN:::
> {noformat}
> Please find the client's ivy.xml, Ivy cache and output in the attachments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-962) Files with non-latin symbols fail to download
[
https://issues.apache.org/jira/browse/IVY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644811#action_12644811
]
Maarten Coene commented on IVY-962:
---
I've tried with current SVN trunk version and it seems to download the artifact
without a problem...
I didn't try with RC1, but I don't think it handles such artifacts differently.
Could you please verify your setup and check if your artifact is accessible
using a browser?
http://yavm-xp-srv:8111/tc/httpAuth/repository/download/bt413/8/русский.txt
> Files with non-latin symbols fail to download
> -
>
> Key: IVY-962
> URL: https://issues.apache.org/jira/browse/IVY-962
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: Yegor Yarko
> Attachments: .ivy.zip, ivy.xml, output.txt, testOnPublicServer.zip,
> русский.txt
>
>
> When I try to download a file with russian characters via Ivy (via Ant
> tasks), Ivy fails to download it
> Server's ivy.xml part:
> {code:xml}
>
> {code}
> Console output
> {noformat}
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: FAILED DOWNLOADS::
> [ivy:retrieve] WARN::: ^ see resolution messages for details ^ ::
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: org#bt413;8!Ёєёёъшщ.txt
> [ivy:retrieve] WARN:::
> {noformat}
> Please find the client's ivy.xml, Ivy cache and output in the attachments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-961) NPE in LogReportOutputter
[
https://issues.apache.org/jira/browse/IVY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-961.
---
Resolution: Fixed
Fix Version/s: trunk
Assignee: Maarten Coene
I've committed a fix into SVN trunk.
Could you give it a try to see if your problem has been solved?
> NPE in LogReportOutputter
> -
>
> Key: IVY-961
> URL: https://issues.apache.org/jira/browse/IVY-961
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0-RC1
>Reporter: Hans Dockter
>Assignee: Maarten Coene
> Fix For: trunk
>
> Attachments: npe.zip
>
>
> If the variable {{}} is
> set to true, the LogReportOutputter throws an NPE in line 70.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-962) Files with non-latin symbols fail to download
[
https://issues.apache.org/jira/browse/IVY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12644910#action_12644910
]
Maarten Coene commented on IVY-962:
---
I've committed a fix to SVN trunk that probably solves your problem.
Could you give it a try and post your findings here?
> Files with non-latin symbols fail to download
> -
>
> Key: IVY-962
> URL: https://issues.apache.org/jira/browse/IVY-962
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: Yegor Yarko
> Attachments: .ivy.zip, ivy.xml, output.txt, testOnPublicServer.zip,
> русский.txt
>
>
> When I try to download a file with russian characters via Ivy (via Ant
> tasks), Ivy fails to download it
> Server's ivy.xml part:
> {code:xml}
>
> {code}
> Console output
> {noformat}
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: FAILED DOWNLOADS::
> [ivy:retrieve] WARN::: ^ see resolution messages for details ^ ::
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: org#bt413;8!Ёєёёъшщ.txt
> [ivy:retrieve] WARN:::
> {noformat}
> Please find the client's ivy.xml, Ivy cache and output in the attachments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-962) Files with non-latin symbols fail to download
[
https://issues.apache.org/jira/browse/IVY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene reassigned IVY-962:
-
Assignee: Maarten Coene
> Files with non-latin symbols fail to download
> -
>
> Key: IVY-962
> URL: https://issues.apache.org/jira/browse/IVY-962
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: Yegor Yarko
>Assignee: Maarten Coene
> Attachments: .ivy.zip, ivy.xml, output.txt, testOnPublicServer.zip,
> русский.txt
>
>
> When I try to download a file with russian characters via Ivy (via Ant
> tasks), Ivy fails to download it
> Server's ivy.xml part:
> {code:xml}
>
> {code}
> Console output
> {noformat}
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: FAILED DOWNLOADS::
> [ivy:retrieve] WARN::: ^ see resolution messages for details ^ ::
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: org#bt413;8!Ёєёёъшщ.txt
> [ivy:retrieve] WARN:::
> {noformat}
> Please find the client's ivy.xml, Ivy cache and output in the attachments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-966) Problem resolving latest jar from multiple repositories containing same jar with different versions
[
https://issues.apache.org/jira/browse/IVY-966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645606#action_12645606
]
Maarten Coene commented on IVY-966:
---
What happens if you use "latest-time" as default latest-strategy?
You can specify this in your settings.xml:
{noformat}
{noformat}
> Problem resolving latest jar from multiple repositories containing same jar
> with different versions
> ---
>
> Key: IVY-966
> URL: https://issues.apache.org/jira/browse/IVY-966
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0-RC2
> Environment: Windows XP SP2, JDK 1.6.0.05
>Reporter: Juliano DeCarvalho
> Attachments: build.xml, ivy.xml, ivysettings.xml
>
>
> This problem may be related to my configuration, but if it is, I'm not sure
> how to fix it.
> My project has a dependency on a jar that I build with another project. This
> jar can be found in two different maven repositories, one local and one
> shared. The jars have different modification dates but the same revision
> (SNAPSHOT) in either repository. I need Ivy to find the latest of the two
> jars. Both repositories are located on my local filesystem, for testing
> purposes.
> Ivy does not seem to return the latest of the two jars. It seems to randomly
> select one, from what I can see. I have debugged into the code and I think I
> found the problem, but not the cause or a solution.
> I have attached my configuration. please note that there may be a typo or
> two since I had to change some things for the sake of anonymity.
> Here are the sequence of events which occur to cause this problem:
> * Code enters AbstractResolver.checkLatest(ResolvedModuleRevision,
> ResolveData), passing in the local artifact
> * Code returns artifact as latest since its the first one found
> * Code enters the checkLatest method again with the second (and newer by
> modification date) artifact
> * Code calls isAfter(newModuleFound, previousModuleFound, data.getDate())
> ** newModuleFound is the second artifact, newer by date
> ** previousModuleFound is the first artifact, which is older
> ** data.getDate() is null
> * isAfter() creates an array [ newModuleFound, previousModuleFound ] and
> passes that to LatestRevisionStrategy.findLatest()
> * findLatest() iterates over the array backwards
> ** findLatest() states that it iterates backwards because, and I quote:
> "the latest revision comes last, use a ListIterator to iterate the sorted
> list in the reverse direction.". Now, this is incorrect in my case since the
> array passed in clearly has the newer module found (the jar with the newer
> modification date) in slot 0
> * findLatest() returns the older revision artifact because the assumptions it
> makes about the array are wrong
> I hope that makes sense. If there's anything else that you need to replicate
> this problem, please let me know.
> Thank you,
> - Juliano DeCarvalho
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-742) Support ivy.xml parent mechanism
[ https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12645609#action_12645609 ] Maarten Coene commented on IVY-742: --- Thank you a lot for this contribution! I have a question: what will happen when we publish/deliver such an ivy.xml file? Will we publish/deliver it with the extends element in it, or will we publish/deliver the merged result? > Support ivy.xml parent mechanism > > > Key: IVY-742 > URL: https://issues.apache.org/jira/browse/IVY-742 > Project: Ivy > Issue Type: New Feature > Components: Core > Environment: Any >Reporter: Neil Lott > Attachments: extendsIvyFile-ivy-r709181.patch > > > Here's the email that details this feature: > On Thu, Feb 21, 2008 at 11:22 PM, Neil Lott <[EMAIL PROTECTED]> > wrote: > Let's say I have multiple modules each with their own ivy.xml > > > > > > > > conf="interface" ext="jar"/> > > >conf="interface->server"/> > > > and I want them all to share an inherited configuration found in a > file: included-configurations.xml > > > > > > > so in the inherited configurations file I'd also like to include a > dependency that goes along with that configuration. > Is something like this possible? > No, this is not possible in Ivy, but you can use text or xml processing > tools to recompose your Ivy file before asking Ivy to resolve the > dependencies of your module. > Alternatively, since what you ask is close to maven 2 parent mechanism, I > think it could be a nice addition to Ivy feature set. So feel free to open > an issue, and even provide a patch :-) > Xavier > Thanks, > Neil > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-962) Files with non-latin symbols fail to download
[
https://issues.apache.org/jira/browse/IVY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646371#action_12646371
]
Maarten Coene commented on IVY-962:
---
Hi Yegor, do you have any new on this?
Is your problem fixed with current SVN trunk?
Maarten
> Files with non-latin symbols fail to download
> -
>
> Key: IVY-962
> URL: https://issues.apache.org/jira/browse/IVY-962
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: Yegor Yarko
>Assignee: Maarten Coene
> Attachments: .ivy.zip, ivy.xml, output.txt, testOnPublicServer.zip,
> русский.txt
>
>
> When I try to download a file with russian characters via Ivy (via Ant
> tasks), Ivy fails to download it
> Server's ivy.xml part:
> {code:xml}
>
> {code}
> Console output
> {noformat}
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: FAILED DOWNLOADS::
> [ivy:retrieve] WARN::: ^ see resolution messages for details ^ ::
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: org#bt413;8!Ёєёёъшщ.txt
> [ivy:retrieve] WARN:::
> {noformat}
> Please find the client's ivy.xml, Ivy cache and output in the attachments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-742) Support ivy.xml parent mechanism
[ https://issues.apache.org/jira/browse/IVY-742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646384#action_12646384 ] Maarten Coene commented on IVY-742: --- Maybe we should support both and make the default behiour to let Ivy publish the merged result, which is the safest solution. IMO, publishing a non-merged result is dangerous and can lead to unwanted dependency-changes when the parent module gets updated. But maybe in some usecases it can be usefull to not publish the merged result if you know what you are doing and what the side-effects of an update of the parent-module are... > Support ivy.xml parent mechanism > > > Key: IVY-742 > URL: https://issues.apache.org/jira/browse/IVY-742 > Project: Ivy > Issue Type: New Feature > Components: Core > Environment: Any >Reporter: Neil Lott > Attachments: extendsIvyFile-ivy-r709181.patch > > > Here's the email that details this feature: > On Thu, Feb 21, 2008 at 11:22 PM, Neil Lott <[EMAIL PROTECTED]> > wrote: > Let's say I have multiple modules each with their own ivy.xml > > > > > > > > conf="interface" ext="jar"/> > > >conf="interface->server"/> > > > and I want them all to share an inherited configuration found in a > file: included-configurations.xml > > > > > > > so in the inherited configurations file I'd also like to include a > dependency that goes along with that configuration. > Is something like this possible? > No, this is not possible in Ivy, but you can use text or xml processing > tools to recompose your Ivy file before asking Ivy to resolve the > dependencies of your module. > Alternatively, since what you ask is close to maven 2 parent mechanism, I > think it could be a nice addition to Ivy feature set. So feel free to open > an issue, and even provide a patch :-) > Xavier > Thanks, > Neil > -- > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-125) attribute value completion on "org" using ibiblio repository (m2comp)
[ https://issues.apache.org/jira/browse/IVYDE-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646389#action_12646389 ] Maarten Coene commented on IVYDE-125: - I think this is more an improvement for Ivy instead of IvyDE. See also IVY-866 > attribute value completion on "org" using ibiblio repository (m2comp) > - > > Key: IVYDE-125 > URL: https://issues.apache.org/jira/browse/IVYDE-125 > Project: IvyDE > Issue Type: Improvement > Components: ivy editor >Affects Versions: 2.0.0.alpha1 >Reporter: Nick Airey > > use standard settings.xml with an ibiblio resolver: eg: > > go to an ivy file with an external dependency, eg: > conf="compile->default"/> > do CTRL-Space with cursor on say "org.hi" does not work. It seems to only > check local repositories, according to the ivy console. > Note that completion does work on "name" and "rev". The actual repository > being used is "http://repo1.maven.org/maven2"; (as expected) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-967) Improve ivy schema
[ https://issues.apache.org/jira/browse/IVY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647382#action_12647382 ] Maarten Coene commented on IVY-967: --- Alexander, I don't fully understand what you are trying to explain. the ivy.xsd already allows you to define extra attrbitues in your element. Do you have a problem with it? > Improve ivy schema > -- > > Key: IVY-967 > URL: https://issues.apache.org/jira/browse/IVY-967 > Project: Ivy > Issue Type: Improvement > Components: Core >Affects Versions: 2.0-RC2 >Reporter: Alexander Foreman > Fix For: 2.0.x > > > Overcome the temporary workaround where XML schema validation of Ivy files > has been turned-off so Ivy extension attributes can be defined. > http://ant.apache.org/ivy/extra";> > e:jniPath="//ms/dist/msjava/PROJ/tools_jni/2.2//lib"/> > Ivy lets you add custom meta-data where the meta-data property name is an xml > value, not a validated part of the xml structure > Improve Ivy xsd to handle the curent appraoch > o See info on xsd anyAttribute > o http://ant.apache.org/ivy/extra"/> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-967) Improve ivy schema
[ https://issues.apache.org/jira/browse/IVY-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-967: -- Fix Version/s: (was: 2.0.x) > Improve ivy schema > -- > > Key: IVY-967 > URL: https://issues.apache.org/jira/browse/IVY-967 > Project: Ivy > Issue Type: Improvement > Components: Core >Affects Versions: 2.0-RC2 >Reporter: Alexander Foreman > > Overcome the temporary workaround where XML schema validation of Ivy files > has been turned-off so Ivy extension attributes can be defined. > http://ant.apache.org/ivy/extra";> > e:jniPath="//ms/dist/msjava/PROJ/tools_jni/2.2//lib"/> > Ivy lets you add custom meta-data where the meta-data property name is an xml > value, not a validated part of the xml structure > Improve Ivy xsd to handle the curent appraoch > o See info on xsd anyAttribute > o http://ant.apache.org/ivy/extra"/> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-969) Add links to more IDE integration plugins
Add links to more IDE integration plugins - Key: IVY-969 URL: https://issues.apache.org/jira/browse/IVY-969 Project: Ivy Issue Type: Improvement Components: Documentation Reporter: Maarten Coene Add links to: - IvyIDEA (IntelliJ IDEA plugin) : http://code.google.com/p/ivyidea/ - IvyBeans (Netbeans plugin) : http://code.google.com/p/ivybeans/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-970) wrong result when ivy.xml changed (md5? sha1?)
[ https://issues.apache.org/jira/browse/IVY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648362#action_12648362 ] Maarten Coene commented on IVY-970: --- could you give more info about what you did exactly and what ivy:buildnumber returns and what the correct result should be? > wrong result when ivy.xml changed (md5? sha1?) > > > Key: IVY-970 > URL: https://issues.apache.org/jira/browse/IVY-970 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.0-RC2 >Reporter: Michael Kebe > > After publishing an artifact to the repository. Ivy uploads an ivy.xml and > generates related .md5 .sha1 files. > With a cleaned ivy cache the buildnumber task gives the wrong result when the > ivy.xml in the repository is changed without changing the hash files. > This is ok, as there is at least a warning. But currently there is nothing. > The ivy:buildnumber task runs without a message and returns the "possibly" > wrong next revision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-969) Add links to more IDE integration plugins
[ https://issues.apache.org/jira/browse/IVY-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-969. --- Resolution: Fixed Fix Version/s: 2.0 Assignee: Maarten Coene Updated the documentation in SVN. The website will be updated when we make a new release. > Add links to more IDE integration plugins > - > > Key: IVY-969 > URL: https://issues.apache.org/jira/browse/IVY-969 > Project: Ivy > Issue Type: Improvement > Components: Documentation >Reporter: Maarten Coene >Assignee: Maarten Coene > Fix For: 2.0 > > > Add links to: > - IvyIDEA (IntelliJ IDEA plugin) : http://code.google.com/p/ivyidea/ > - IvyBeans (Netbeans plugin) : http://code.google.com/p/ivybeans/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-965) Support useOrigin for artifacts with a set url attribute
[
https://issues.apache.org/jira/browse/IVY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-965.
---
Resolution: Fixed
Fix Version/s: trunk
Assignee: Maarten Coene
Thanks for the patch, I've applied it into SVN trunk.
Could you provide us your full name so we can you proper credits for your
contribution?
thanks,
Maarten
> Support useOrigin for artifacts with a set url attribute
>
>
> Key: IVY-965
> URL: https://issues.apache.org/jira/browse/IVY-965
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: alex322
>Assignee: Maarten Coene
> Fix For: trunk
>
>
> Currently artifacts with a specified url are always considered remote because
> the code instantiates URLResource.
> This change would allow using FileResource when the url is "file://*".
> {noformat}
> --- BasicResolver.java.originalMon Oct 20 16:47:15 2008
> +++ BasicResolver.java Mon Nov 03 15:38:48 2008
> @@ -64,6 +64,8 @@
> import org.apache.ivy.plugins.repository.ArtifactResourceResolver;
> import org.apache.ivy.plugins.repository.Resource;
> import org.apache.ivy.plugins.repository.ResourceDownloader;
> +import org.apache.ivy.plugins.repository.file.FileRepository;
> +import org.apache.ivy.plugins.repository.file.FileResource;
> import org.apache.ivy.plugins.repository.url.URLRepository;
> import org.apache.ivy.plugins.repository.url.URLResource;
> import org.apache.ivy.plugins.resolver.util.MDResolvedResource;
> @@ -918,7 +920,14 @@
> URL url = artifact.getUrl();
> Message.verbose("\tusing url for " + artifact + ": " + url);
> logArtifactAttempt(artifact, url.toExternalForm());
> -ret = new ResolvedResource(new URLResource(url),
> artifact.getModuleRevisionId()
> +Resource resource;
> +if ("file".equals(url.getProtocol())) {
> + resource = new FileResource(new FileRepository(), new
> File(url.getPath()));
> +}
> +else {
> + resource = new URLResource(url);
> +}
> + ret = new ResolvedResource(resource,
> artifact.getModuleRevisionId()
> .getRevision());
> }
> return ret;
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (IVY-965) Support useOrigin for artifacts with a set url attribute
[
https://issues.apache.org/jira/browse/IVY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12648393#action_12648393
]
maartenc edited comment on IVY-965 at 11/17/08 2:43 PM:
-
Thanks for the patch, I've applied it into SVN trunk.
Could you provide us your full name so we can give you proper credits for your
contribution?
thanks,
Maarten
was (Author: maartenc):
Thanks for the patch, I've applied it into SVN trunk.
Could you provide us your full name so we can you proper credits for your
contribution?
thanks,
Maarten
> Support useOrigin for artifacts with a set url attribute
>
>
> Key: IVY-965
> URL: https://issues.apache.org/jira/browse/IVY-965
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: alex322
>Assignee: Maarten Coene
> Fix For: trunk
>
>
> Currently artifacts with a specified url are always considered remote because
> the code instantiates URLResource.
> This change would allow using FileResource when the url is "file://*".
> {noformat}
> --- BasicResolver.java.originalMon Oct 20 16:47:15 2008
> +++ BasicResolver.java Mon Nov 03 15:38:48 2008
> @@ -64,6 +64,8 @@
> import org.apache.ivy.plugins.repository.ArtifactResourceResolver;
> import org.apache.ivy.plugins.repository.Resource;
> import org.apache.ivy.plugins.repository.ResourceDownloader;
> +import org.apache.ivy.plugins.repository.file.FileRepository;
> +import org.apache.ivy.plugins.repository.file.FileResource;
> import org.apache.ivy.plugins.repository.url.URLRepository;
> import org.apache.ivy.plugins.repository.url.URLResource;
> import org.apache.ivy.plugins.resolver.util.MDResolvedResource;
> @@ -918,7 +920,14 @@
> URL url = artifact.getUrl();
> Message.verbose("\tusing url for " + artifact + ": " + url);
> logArtifactAttempt(artifact, url.toExternalForm());
> -ret = new ResolvedResource(new URLResource(url),
> artifact.getModuleRevisionId()
> +Resource resource;
> +if ("file".equals(url.getProtocol())) {
> + resource = new FileResource(new FileRepository(), new
> File(url.getPath()));
> +}
> +else {
> + resource = new URLResource(url);
> +}
> + ret = new ResolvedResource(resource,
> artifact.getModuleRevisionId()
> .getRevision());
> }
> return ret;
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-973) [PATCH] SFTP repositories become very slow after a while
[ https://issues.apache.org/jira/browse/IVY-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649483#action_12649483 ] Maarten Coene commented on IVY-973: --- I think your patch will only work if you don't have a [revision] token in your directory structure. Can you confirm this is the case in your situation? So if your pattern looks like for instance "[organisation]/[module]/[revision]/[artifact]-[revision].[ext]", you'll still have a roundtrip for each revision. I think we should try to avoid calling Resource.exists() in the ResolverHelper.findAll() method. > [PATCH] SFTP repositories become very slow after a while > > > Key: IVY-973 > URL: https://issues.apache.org/jira/browse/IVY-973 > Project: Ivy > Issue Type: Improvement > Components: Core >Affects Versions: 2.0-RC2 >Reporter: Johannes Rudolph >Priority: Minor > Attachments: faster-sftp.patch > > > If many versions of a module live in a folder of an SFTP repository each > resolve for dynamic versions becomes dreadfully slow because a roundtrip to > the server is made to the server for every version which lies on the server. > The call sequence goes like that: > org.apache.ivy.plugins.resolver.util.ResolverHelper.findAll calls > 1. org.apache.ivy.plugins.resolver.util.ResolverHelper.listTokenValues > which calls > SFTPRepository.list with the directory of the module as parameter (1. > roundtrip) > 2. for every found file matching the pattern > SFTPRepository.getResource(path).exists() > In turn SFTPResource tries to initialize itself and calls > SFTPRepository.resolveResource which does the second roundtrip to the server > - for every version of the file > Example: Having 20 versions of a module in a repository which is a roundtrip > of 150ms away, leads to a lag of 20 * 150ms = 3s . Multiply that with any > module having a dynamic version. > The solution is to cache all the resources in SFTPRepository. You can use the > information retrieved when calling SFTPRepository.list to fill the cache in > advance. > The disadvantage is that you may have stale data. IMO this is mostly no > problem because every call to list updates the cache and files already > available in the repository won't hopefully change any metadata in the time > between. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-970) wrong result when resolve fails
[ https://issues.apache.org/jira/browse/IVY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-970: -- Component/s: Ant Assignee: Maarten Coene Summary: wrong result when resolve fails (was: wrong result when ivy.xml changed (md5? sha1?)) > wrong result when resolve fails > - > > Key: IVY-970 > URL: https://issues.apache.org/jira/browse/IVY-970 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0-RC2 >Reporter: Michael Kebe >Assignee: Maarten Coene > > After publishing an artifact to the repository. Ivy uploads an ivy.xml and > generates related .md5 .sha1 files. > With a cleaned ivy cache the buildnumber task gives the wrong result when the > ivy.xml in the repository is changed without changing the hash files. > This is ok, as there is at least a warning. But currently there is nothing. > The ivy:buildnumber task runs without a message and returns the "possibly" > wrong next revision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-970) wrong result when resolve fails
[ https://issues.apache.org/jira/browse/IVY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-970. --- Resolution: Fixed Fix Version/s: trunk I've added a junit test and committed a patch into SVN trunk. Could you give it a try? > wrong result when resolve fails > - > > Key: IVY-970 > URL: https://issues.apache.org/jira/browse/IVY-970 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0-RC2 >Reporter: Michael Kebe >Assignee: Maarten Coene > Fix For: trunk > > > After publishing an artifact to the repository. Ivy uploads an ivy.xml and > generates related .md5 .sha1 files. > With a cleaned ivy cache the buildnumber task gives the wrong result when the > ivy.xml in the repository is changed without changing the hash files. > This is ok, as there is at least a warning. But currently there is nothing. > The ivy:buildnumber task runs without a message and returns the "possibly" > wrong next revision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-970) wrong result when resolve fails
[ https://issues.apache.org/jira/browse/IVY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649631#action_12649631 ] Maarten Coene commented on IVY-970: --- I don't think the buildnumber task should check the correctness of existing ivy.xml files. So what I would expect is that after you change the ivy.xml on the repository, the buildnumber task still works as if nothing has been changed. But it's strange that you still get "1.0-dev-b1" as buildnumber after your first publish. I'll try to reproduce the problem... > wrong result when resolve fails > - > > Key: IVY-970 > URL: https://issues.apache.org/jira/browse/IVY-970 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0-RC2 >Reporter: Michael Kebe >Assignee: Maarten Coene > Fix For: trunk > > > After publishing an artifact to the repository. Ivy uploads an ivy.xml and > generates related .md5 .sha1 files. > With a cleaned ivy cache the buildnumber task gives the wrong result when the > ivy.xml in the repository is changed without changing the hash files. > This is ok, as there is at least a warning. But currently there is nothing. > The ivy:buildnumber task runs without a message and returns the "possibly" > wrong next revision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-970) wrong result when resolve fails
[ https://issues.apache.org/jira/browse/IVY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650068#action_12650068 ] Maarten Coene commented on IVY-970: --- I think I've found the problem and committed a fix into svn trunk. Could you please give it another try? Even if we check the validity of the ivy.xml in the repository, your evil guy can still mess up things when he: - also updates the checksum files after changing the ivy.xml file to make sure they are ok - or he could add completely new revisions by creating new directories and adding valid ivy.xml files in there I just don't think it's the responsability of the buildnumber task to check this, but we could probably add a flag to the buildnumber task indicating that the found revision must be checked for validity. If you really want something like this, could you add a new JIRA improvement request? > wrong result when resolve fails > - > > Key: IVY-970 > URL: https://issues.apache.org/jira/browse/IVY-970 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0-RC2 >Reporter: Michael Kebe >Assignee: Maarten Coene > Fix For: trunk > > > After publishing an artifact to the repository. Ivy uploads an ivy.xml and > generates related .md5 .sha1 files. > With a cleaned ivy cache the buildnumber task gives the wrong result when the > ivy.xml in the repository is changed without changing the hash files. > This is ok, as there is at least a warning. But currently there is nothing. > The ivy:buildnumber task runs without a message and returns the "possibly" > wrong next revision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-970) wrong result when resolve fails
[ https://issues.apache.org/jira/browse/IVY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-970. --- Resolution: Fixed > wrong result when resolve fails > - > > Key: IVY-970 > URL: https://issues.apache.org/jira/browse/IVY-970 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0-RC2 >Reporter: Michael Kebe >Assignee: Maarten Coene > Fix For: trunk > > > After publishing an artifact to the repository. Ivy uploads an ivy.xml and > generates related .md5 .sha1 files. > With a cleaned ivy cache the buildnumber task gives the wrong result when the > ivy.xml in the repository is changed without changing the hash files. > This is ok, as there is at least a warning. But currently there is nothing. > The ivy:buildnumber task runs without a message and returns the "possibly" > wrong next revision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-970) returns wrong result when resolve fails
[ https://issues.apache.org/jira/browse/IVY-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-970: -- Summary: returns wrong result when resolve fails (was: wrong result when resolve fails) > returns wrong result when resolve fails > - > > Key: IVY-970 > URL: https://issues.apache.org/jira/browse/IVY-970 > Project: Ivy > Issue Type: Bug > Components: Ant >Affects Versions: 2.0-RC2 >Reporter: Michael Kebe >Assignee: Maarten Coene > Fix For: trunk > > > After publishing an artifact to the repository. Ivy uploads an ivy.xml and > generates related .md5 .sha1 files. > With a cleaned ivy cache the buildnumber task gives the wrong result when the > ivy.xml in the repository is changed without changing the hash files. > This is ok, as there is at least a warning. But currently there is nothing. > The ivy:buildnumber task runs without a message and returns the "possibly" > wrong next revision. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-975) IO problem while parsing ivy file (Resetting to invalid mark)
[ https://issues.apache.org/jira/browse/IVY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-975: - Assignee: Maarten Coene > IO problem while parsing ivy file (Resetting to invalid mark) > - > > Key: IVY-975 > URL: https://issues.apache.org/jira/browse/IVY-975 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.0-RC2 > Environment: Windows XP SP2, Java 1.6.0_07, Ant 1.7.1 >Reporter: Nicolas Labrot >Assignee: Maarten Coene > Attachments: IvyIssue.rar > > > I'm trying to resolve MyFaces 1.1.6 > > But Ivy return this error : > [ivy:retrieve] :: problems summary :: > [ivy:retrieve] WARNINGS > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/myfaces/6/myfaces-6.pom: Resetting to invalid mark > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/core/myfaces-core-project/1.1.6/myfaces-core-project-1.1.6.pom: > Impossible to load parent for > (..)/.ivy2/cache/org.apache.myfaces.core/myfaces-core-project/ivy-1.1.6.xml.original. > Parent=org.apache.myfaces#myfaces;6 > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/core/myfaces-api/1.1.6/myfaces-api-1.1.6.pom: > Impossible to load parent for > (..)/.ivy2/cache/org.apache.myfaces.core/myfaces-api/ivy-1.1.6.xml.original. > Parent=org.apache.myfaces.core#myfaces-core-project;1.1.6 > [ivy:retrieve] module not found: > org.apache.myfaces.core#myfaces-api;1.1.6 > [ivy:retrieve] artifactory: tried > [ivy:retrieve] (..)/org/apache/myfaces/myfaces/6/myfaces-6.pom > [ivy:retrieve] :: > [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: > [ivy:retrieve] :: > [ivy:retrieve] :: org.apache.myfaces.core#myfaces-api;1.1.6: not found > [ivy:retrieve] :: > [ivy:retrieve] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-975) IO problem while parsing ivy file (Resetting to invalid mark)
[ https://issues.apache.org/jira/browse/IVY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-975. --- Resolution: Fixed Fix Version/s: trunk Should be fixed now in SVN trunk. Could you give it a try? > IO problem while parsing ivy file (Resetting to invalid mark) > - > > Key: IVY-975 > URL: https://issues.apache.org/jira/browse/IVY-975 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.0-RC2 > Environment: Windows XP SP2, Java 1.6.0_07, Ant 1.7.1 >Reporter: Nicolas Labrot >Assignee: Maarten Coene > Fix For: trunk > > Attachments: IvyIssue.rar > > > I'm trying to resolve MyFaces 1.1.6 > > But Ivy return this error : > [ivy:retrieve] :: problems summary :: > [ivy:retrieve] WARNINGS > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/myfaces/6/myfaces-6.pom: Resetting to invalid mark > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/core/myfaces-core-project/1.1.6/myfaces-core-project-1.1.6.pom: > Impossible to load parent for > (..)/.ivy2/cache/org.apache.myfaces.core/myfaces-core-project/ivy-1.1.6.xml.original. > Parent=org.apache.myfaces#myfaces;6 > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/core/myfaces-api/1.1.6/myfaces-api-1.1.6.pom: > Impossible to load parent for > (..)/.ivy2/cache/org.apache.myfaces.core/myfaces-api/ivy-1.1.6.xml.original. > Parent=org.apache.myfaces.core#myfaces-core-project;1.1.6 > [ivy:retrieve] module not found: > org.apache.myfaces.core#myfaces-api;1.1.6 > [ivy:retrieve] artifactory: tried > [ivy:retrieve] (..)/org/apache/myfaces/myfaces/6/myfaces-6.pom > [ivy:retrieve] :: > [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: > [ivy:retrieve] :: > [ivy:retrieve] :: org.apache.myfaces.core#myfaces-api;1.1.6: not found > [ivy:retrieve] :: > [ivy:retrieve] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-912) Can the getArchiveFileInCache() methods be put on the RepositoryCacheManager interface?
[
https://issues.apache.org/jira/browse/IVY-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650357#action_12650357
]
Maarten Coene commented on IVY-912:
---
The problem is that it is possible that the artifact isn't in the cache (can
happen if you set useOrigin="true" on the cache element in your settings.xml).
In that case, the File returned by that method will probably not exist.
You should take a look at the IvyCachePath task to have an example of getting
the resolved artifacts as file paths by using the ResolveReport.
If I'm not mistaken, IvyDE (the eclipse plugin) uses a similar approach.
> Can the getArchiveFileInCache() methods be put on the RepositoryCacheManager
> interface?
>
>
> Key: IVY-912
> URL: https://issues.apache.org/jira/browse/IVY-912
> Project: Ivy
> Issue Type: Wish
> Components: Core
>Affects Versions: 2.0.0-beta-2
>Reporter: Guy Mahieu
>
> I'm writing an IDE plugin, and I need to access the filepath of a resolved
> dependency to add to the dependencies of the IDE project.
> To do this, I needed to use the DefaultRepositoryCacheManager directly since
> the getArchiveFileInCache(artifact) method is not on the interface.
> Was this an intentional decision, if so: how should I lookup the archive for
> the artifact?
> If not, can this method become part of the interface so the usability of the
> API increases?
> Small code snippet to illustrate the current API usage: {noformat} if
> (repositoryCacheManager instanceof DefaultRepositoryCacheManager) {
> DefaultRepositoryCacheManager defaultRepositoryCacheManager =
> (DefaultRepositoryCacheManager) repositoryCacheManager;
>
> projectDependencies.add(defaultRepositoryCacheManager.getArchiveFileInCache(artifact).getAbsolutePath());
>
> }
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-976) Ivy Standalone setting to overwrite publications
[ https://issues.apache.org/jira/browse/IVY-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-976: -- Assignee: Maarten Coene Remaining Estimate: (was: 2h) Original Estimate: (was: 2h) > Ivy Standalone setting to overwrite publications > - > > Key: IVY-976 > URL: https://issues.apache.org/jira/browse/IVY-976 > Project: Ivy > Issue Type: New Feature > Components: Core > Environment: I'm using ivy standalone with windows and nant for c# > development. >Reporter: Tomas Roos >Assignee: Maarten Coene > > Ivy is working very well with our setup. > We are using ivy standalone + nant + subversion. > Any way the issue is when a dll has same size as the previous but the > versionnumber might diff then it wont publish the new dependencies because > the overwrite is set to false. > It would be nice to be able to set this somewhere, mabe in the commandline. > Doesnt matter as long as there is a posiblity. > Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-976) Ivy Standalone setting to overwrite publications
[ https://issues.apache.org/jira/browse/IVY-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-976: -- Issue Type: Improvement (was: New Feature) > Ivy Standalone setting to overwrite publications > - > > Key: IVY-976 > URL: https://issues.apache.org/jira/browse/IVY-976 > Project: Ivy > Issue Type: Improvement > Components: Core > Environment: I'm using ivy standalone with windows and nant for c# > development. >Reporter: Tomas Roos >Assignee: Maarten Coene > > Ivy is working very well with our setup. > We are using ivy standalone + nant + subversion. > Any way the issue is when a dll has same size as the previous but the > versionnumber might diff then it wont publish the new dependencies because > the overwrite is set to false. > It would be nice to be able to set this somewhere, mabe in the commandline. > Doesnt matter as long as there is a posiblity. > Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-976) Ivy Standalone setting to overwrite publications
[ https://issues.apache.org/jira/browse/IVY-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-976. --- Resolution: Fixed Fix Version/s: trunk I've added a command-line option to indicate you want to overwrite existing artifacts in SVN trunk. Could you give it a try? > Ivy Standalone setting to overwrite publications > - > > Key: IVY-976 > URL: https://issues.apache.org/jira/browse/IVY-976 > Project: Ivy > Issue Type: Improvement > Components: Core > Environment: I'm using ivy standalone with windows and nant for c# > development. >Reporter: Tomas Roos >Assignee: Maarten Coene > Fix For: trunk > > > Ivy is working very well with our setup. > We are using ivy standalone + nant + subversion. > Any way the issue is when a dll has same size as the previous but the > versionnumber might diff then it wont publish the new dependencies because > the overwrite is set to false. > It would be nice to be able to set this somewhere, mabe in the commandline. > Doesnt matter as long as there is a posiblity. > Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-978) buildnumber Ant task ignoring prefix attribute
[
https://issues.apache.org/jira/browse/IVY-978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650741#action_12650741
]
Maarten Coene commented on IVY-978:
---
I couldn't reproduce your problem, for instance I have the following:
{noformat}
${repo.revision}
${repo.new.revision}
{noformat}
Which results in the following output:
{noformat}
[echo] 2.0.0-rc2
[echo] 2.0.0-rc3
{noformat}
The only explenation I can see is that the buildnumber task doesn't find a
revision for your module, but that doesn't explain why the ivy.revision
property is set.
Could you run ant in debug mode and post the output of the buildnumber task
here?
> buildnumber Ant task ignoring prefix attribute
> --
>
> Key: IVY-978
> URL: https://issues.apache.org/jira/browse/IVY-978
> Project: Ivy
> Issue Type: Bug
> Components: Ant
>Affects Versions: 2.0-RC2
> Environment: JDK 1.6.0_07 on Windows Vista
>Reporter: Mitch Gitman
>
> I'm setting the prefix attribute on the buildnumber Ant task:
>module="${ivy.module}"
> default="${ivy.default.revision}" prefix="repo" />
> But when I go to manually output the properties that are set, I see:
> ivy-buildnumber:
> [echo] ivy:buildnumber output:
> [echo] ivy.revision=1.1
> [echo] repo.revision=${repo.revision}
> You see that the default ivy.revision property gets set; the repo.revision
> property does not.
> Here's what the buildnumber documentation has to say about the prefix
> attribute:
> "the prefix to use for the property names set (will be prefix.revision,
> prefix.new.revision, ...)"
> Addendum: There's another, possibly related issue with the buildnumber task.
> My understanding is that the ivy.revision property is supposed to behave as a
> variable. As long as the user hasn't manually set it at any point, an Ant
> task can set it to one value, and then another Ant task can come along and
> set it to another value.
> I've run into a situation where I might run a task like ivy:info and then
> subsequently run ivy:buildnumber. According to info, which reads the ivy.xml,
> the revision is, say 1.1.200. According to buildnumber, which scans the
> repository, the revision SHOULD BE [EMAIL PROTECTED] (Set aside the fact that
> the ivy.xml and repository are themselves inconsistent; I'm trying to catch
> and deal with the situation where they are.) The buildnumber invocation shows
> revision as 1.1.200 rather than [EMAIL PROTECTED] In other words, it fails to
> find the main thing it's supposed to be finding.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-977) publish fails when setting ivy.checksums via a property file
[
https://issues.apache.org/jira/browse/IVY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650750#action_12650750
]
Maarten Coene commented on IVY-977:
---
Marc,
just to be sure, but did you specify the ivy.checksums property in the
properties file without the double quotest like this?
{noformat}
ivy.checksums=
{noformat}
> publish fails when setting ivy.checksums via a property file
> -
>
> Key: IVY-977
> URL: https://issues.apache.org/jira/browse/IVY-977
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0.0-beta-2
> Environment: Windows XP
>Reporter: Marc De Boeck
>Priority: Minor
>
> When setting the property ivy.checksums in a property file, each publish
> operation failed with the following error:
> publish:package:
> [echo] >>> Publishing main package to local repository
> [ivy:publish] :: publishing :: com.bene_system#common2-message
> [ivy:publish] publish aborted: deleted
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\var\my_local_repo\com.bene_system\common2-message\20081125153702.part
> BUILD FAILED
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:786: The
> following error occurred while executing this line:
> R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:787:
> impossible to publish artifacts for com.bene_system#common2-message;[EMAIL
> PROTECTED]: java.io.IOException: The filename, directory name, or volume
> label syntax is incorrect
> Total time: 3 seconds
> My ivysettings-file looked as follow:
>
>
>
>
> In the property file default.properties ivy.checksums was defined as follows:
> ivy.checksums = ""
> Even when setting ivy.checksums="md5, sha1" or any other value, the build
> still failed.
> I then tried to set the property directly in the ivysettings file:
>
>
>
> And that worked fine.
> So there is a workaround, but it took me a very long time to find out the
> root cause of this failure. So I propose that at least this is documented
> somewhere.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-977) publish fails when setting ivy.checksums via a property file
[ https://issues.apache.org/jira/browse/IVY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12650890#action_12650890 ] Maarten Coene commented on IVY-977: --- Marc, can you give it a try *without* the double quotes? If that doesn't work, could you post the console log when running ant in debug mode (ant -d), together with your settings.xml and your properties file? Maarten > publish fails when setting ivy.checksums via a property file > - > > Key: IVY-977 > URL: https://issues.apache.org/jira/browse/IVY-977 > Project: Ivy > Issue Type: Bug >Affects Versions: 2.0.0-beta-2 > Environment: * Windows XP > * java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing) > * Apache Ant version 1.7.0 compiled on December 13 2006 >Reporter: Marc De Boeck >Priority: Minor > > When setting the property ivy.checksums in a property file, each publish > operation failed with the following error: > publish:package: > [echo] >>> Publishing main package to local repository > [ivy:publish] :: publishing :: com.bene_system#common2-message > [ivy:publish] publish aborted: deleted > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\var\my_local_repo\com.bene_system\common2-message\20081125153702.part > BUILD FAILED > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:786: The > following error occurred while executing this line: > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:787: > impossible to publish artifacts for com.bene_system#common2-message;[EMAIL > PROTECTED]: java.io.IOException: The filename, directory name, or volume > label syntax is incorrect > Total time: 3 seconds > My ivysettings-file looked as follow: > > > > > In the property file default.properties ivy.checksums was defined as follows: > ivy.checksums = "" > Even when setting ivy.checksums="md5, sha1" or any other value, the build > still failed. > I then tried to set the property directly in the ivysettings file: > > > > And that worked fine. > So there is a workaround, but it took me a very long time to find out the > root cause of this failure. So I propose that at least this is documented > somewhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-977) error message is not clear when specifying an invalid value for checksums
[ https://issues.apache.org/jira/browse/IVY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene reassigned IVY-977: - Assignee: Maarten Coene > error message is not clear when specifying an invalid value for checksums > - > > Key: IVY-977 > URL: https://issues.apache.org/jira/browse/IVY-977 > Project: Ivy > Issue Type: Improvement >Affects Versions: 2.0.0-beta-2 > Environment: * Windows XP > * java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing) > * Apache Ant version 1.7.0 compiled on December 13 2006 >Reporter: Marc De Boeck >Assignee: Maarten Coene >Priority: Minor > > When setting the property ivy.checksums in a property file, each publish > operation failed with the following error: > publish:package: > [echo] >>> Publishing main package to local repository > [ivy:publish] :: publishing :: com.bene_system#common2-message > [ivy:publish] publish aborted: deleted > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\var\my_local_repo\com.bene_system\common2-message\20081125153702.part > BUILD FAILED > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:786: The > following error occurred while executing this line: > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:787: > impossible to publish artifacts for com.bene_system#common2-message;[EMAIL > PROTECTED]: java.io.IOException: The filename, directory name, or volume > label syntax is incorrect > Total time: 3 seconds > My ivysettings-file looked as follow: > > > > > In the property file default.properties ivy.checksums was defined as follows: > ivy.checksums = "" > Even when setting ivy.checksums="md5, sha1" or any other value, the build > still failed. > I then tried to set the property directly in the ivysettings file: > > > > And that worked fine. > So there is a workaround, but it took me a very long time to find out the > root cause of this failure. So I propose that at least this is documented > somewhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-977) error message is not clear when specifying an invalid value for checksums
[ https://issues.apache.org/jira/browse/IVY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-977: -- Issue Type: Improvement (was: Bug) Summary: error message is not clear when specifying an invalid value for checksums (was: publish fails when setting ivy.checksums via a property file) > error message is not clear when specifying an invalid value for checksums > - > > Key: IVY-977 > URL: https://issues.apache.org/jira/browse/IVY-977 > Project: Ivy > Issue Type: Improvement >Affects Versions: 2.0.0-beta-2 > Environment: * Windows XP > * java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing) > * Apache Ant version 1.7.0 compiled on December 13 2006 >Reporter: Marc De Boeck >Priority: Minor > > When setting the property ivy.checksums in a property file, each publish > operation failed with the following error: > publish:package: > [echo] >>> Publishing main package to local repository > [ivy:publish] :: publishing :: com.bene_system#common2-message > [ivy:publish] publish aborted: deleted > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\var\my_local_repo\com.bene_system\common2-message\20081125153702.part > BUILD FAILED > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:786: The > following error occurred while executing this line: > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:787: > impossible to publish artifacts for com.bene_system#common2-message;[EMAIL > PROTECTED]: java.io.IOException: The filename, directory name, or volume > label syntax is incorrect > Total time: 3 seconds > My ivysettings-file looked as follow: > > > > > In the property file default.properties ivy.checksums was defined as follows: > ivy.checksums = "" > Even when setting ivy.checksums="md5, sha1" or any other value, the build > still failed. > I then tried to set the property directly in the ivysettings file: > > > > And that worked fine. > So there is a workaround, but it took me a very long time to find out the > root cause of this failure. So I propose that at least this is documented > somewhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-977) error message is not clear when specifying an invalid value for checksums
[ https://issues.apache.org/jira/browse/IVY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-977. --- Resolution: Fixed Fix Version/s: trunk I've updated the code in SVN trunk in an attempt to provide a more meaningfull error message. Could you give it a try to see if the message is more clear now? > error message is not clear when specifying an invalid value for checksums > - > > Key: IVY-977 > URL: https://issues.apache.org/jira/browse/IVY-977 > Project: Ivy > Issue Type: Improvement >Affects Versions: 2.0.0-beta-2 > Environment: * Windows XP > * java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing) > * Apache Ant version 1.7.0 compiled on December 13 2006 >Reporter: Marc De Boeck >Assignee: Maarten Coene >Priority: Minor > Fix For: trunk > > > When setting the property ivy.checksums in a property file, each publish > operation failed with the following error: > publish:package: > [echo] >>> Publishing main package to local repository > [ivy:publish] :: publishing :: com.bene_system#common2-message > [ivy:publish] publish aborted: deleted > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\var\my_local_repo\com.bene_system\common2-message\20081125153702.part > BUILD FAILED > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:786: The > following error occurred while executing this line: > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:787: > impossible to publish artifacts for com.bene_system#common2-message;[EMAIL > PROTECTED]: java.io.IOException: The filename, directory name, or volume > label syntax is incorrect > Total time: 3 seconds > My ivysettings-file looked as follow: > > > > > In the property file default.properties ivy.checksums was defined as follows: > ivy.checksums = "" > Even when setting ivy.checksums="md5, sha1" or any other value, the build > still failed. > I then tried to set the property directly in the ivysettings file: > > > > And that worked fine. > So there is a workaround, but it took me a very long time to find out the > root cause of this failure. So I propose that at least this is documented > somewhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-977) error message is not clear when specifying an invalid value for checksums
[ https://issues.apache.org/jira/browse/IVY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651362#action_12651362 ] Maarten Coene commented on IVY-977: --- Marc, Can you paste the stacktrace here when running ant in verbose mode (ant -v) ? Maarten > error message is not clear when specifying an invalid value for checksums > - > > Key: IVY-977 > URL: https://issues.apache.org/jira/browse/IVY-977 > Project: Ivy > Issue Type: Improvement >Affects Versions: 2.0.0-beta-2 > Environment: * Windows XP > * java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing) > * Apache Ant version 1.7.0 compiled on December 13 2006 >Reporter: Marc De Boeck >Assignee: Maarten Coene >Priority: Minor > Fix For: trunk > > > When setting the property ivy.checksums in a property file, each publish > operation failed with the following error: > publish:package: > [echo] >>> Publishing main package to local repository > [ivy:publish] :: publishing :: com.bene_system#common2-message > [ivy:publish] publish aborted: deleted > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\var\my_local_repo\com.bene_system\common2-message\20081125153702.part > BUILD FAILED > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:786: The > following error occurred while executing this line: > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:787: > impossible to publish artifacts for com.bene_system#common2-message;[EMAIL > PROTECTED]: java.io.IOException: The filename, directory name, or volume > label syntax is incorrect > Total time: 3 seconds > My ivysettings-file looked as follow: > > > > > In the property file default.properties ivy.checksums was defined as follows: > ivy.checksums = "" > Even when setting ivy.checksums="md5, sha1" or any other value, the build > still failed. > I then tried to set the property directly in the ivysettings file: > > > > And that worked fine. > So there is a workaround, but it took me a very long time to find out the > root cause of this failure. So I propose that at least this is documented > somewhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-977) error message is not clear when specifying an invalid value for checksums
[ https://issues.apache.org/jira/browse/IVY-977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651420#action_12651420 ] Maarten Coene commented on IVY-977: --- Thank you for the extra information. I've committed an additional fix into SVN trunk. Could you give it another try? thanks, Maarten > error message is not clear when specifying an invalid value for checksums > - > > Key: IVY-977 > URL: https://issues.apache.org/jira/browse/IVY-977 > Project: Ivy > Issue Type: Improvement >Affects Versions: 2.0.0-beta-2 > Environment: * Windows XP > * java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode, sharing) > * Apache Ant version 1.7.0 compiled on December 13 2006 >Reporter: Marc De Boeck >Assignee: Maarten Coene >Priority: Minor > Fix For: trunk > > Attachments: ant_stdout.txt > > > When setting the property ivy.checksums in a property file, each publish > operation failed with the following error: > publish:package: > [echo] >>> Publishing main package to local repository > [ivy:publish] :: publishing :: com.bene_system#common2-message > [ivy:publish] publish aborted: deleted > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\var\my_local_repo\com.bene_system\common2-message\20081125153702.part > BUILD FAILED > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:786: The > following error occurred while executing this line: > R:\ext950_r_costa_INCEPTION_int_dn\devtools\oobs\oobs-java.xml:787: > impossible to publish artifacts for com.bene_system#common2-message;[EMAIL > PROTECTED]: java.io.IOException: The filename, directory name, or volume > label syntax is incorrect > Total time: 3 seconds > My ivysettings-file looked as follow: > > > > > In the property file default.properties ivy.checksums was defined as follows: > ivy.checksums = "" > Even when setting ivy.checksums="md5, sha1" or any other value, the build > still failed. > I then tried to set the property directly in the ivysettings file: > > > > And that worked fine. > So there is a workaround, but it took me a very long time to find out the > root cause of this failure. So I propose that at least this is documented > somewhere. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-980) NullPointerException when resolving module wihout revision in the pattern
[ https://issues.apache.org/jira/browse/IVY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-980: -- Fix Version/s: (was: 2.0.0-beta-2) (was: 2.0.0-beta-1) trunk Assignee: Maarten Coene Summary: NullPointerException when resolving module wihout revision in the pattern (was: NullPointerException : BasicResolver resolveAndCheckRevision) > NullPointerException when resolving module wihout revision in the pattern > - > > Key: IVY-980 > URL: https://issues.apache.org/jira/browse/IVY-980 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1, 2.0-RC2 > Environment: Intel / Windows 2000 (Server) / Windows XP. >Reporter: Craig paddon >Assignee: Maarten Coene > Fix For: trunk > > > When I switched to RC1 or RC2 I experianced the following error (which worked > fine in previuos versions). > When there is a dependancy which uses the rev="+" and there is no revision on > the artifact in the repository the resolver throws a null pointer. > [ivy:resolve] WARNINGS > [ivy:resolve] :: > [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: > [ivy:resolve] :: > [ivy:resolve] :: acme#SomeJar;+: java.lang.NullPointerException at > org.apache.ivy.plugins.resolver.Bas > icResolver.resolveAndCheckRevision(BasicResolver.java:457) > [ivy:resolve] :: > I have a filesystem resolver with the following pattern: > > pattern="\\someServer\IvyRepo\external\[organisation]\[artifact]-[revision].[ext]"/> > pattern="\\someServer\IvyRepo\external\[organisation]\[artifact].[ext]"/> > > (Some artifacts in the 3rd party library don't have versions). > The file path is: > \\someServer\IvyRepo\external\acme\SomeJar.jar > The dependancy is: > > From a client point of view, the module doesn't care what version... just get > the latest and if there is no version just get the current one. > There are a number of work arounds... > a) Ensure all JARs in the repository have a version ... Invent a version on > ones which don't have any version. (Probably a good idea anyway). >- If this is the case then thats fine. It should just be a documented > feature :) > b) Use the beta version of ivy. > c) Change the client module to specify no revision rev="" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-980) NullPointerException when resolving module without revision in the pattern
[ https://issues.apache.org/jira/browse/IVY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-980: -- Summary: NullPointerException when resolving module without revision in the pattern (was: NullPointerException when resolving module wihout revision in the pattern) > NullPointerException when resolving module without revision in the pattern > -- > > Key: IVY-980 > URL: https://issues.apache.org/jira/browse/IVY-980 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1, 2.0-RC2 > Environment: Intel / Windows 2000 (Server) / Windows XP. >Reporter: Craig paddon >Assignee: Maarten Coene > Fix For: trunk > > > When I switched to RC1 or RC2 I experianced the following error (which worked > fine in previuos versions). > When there is a dependancy which uses the rev="+" and there is no revision on > the artifact in the repository the resolver throws a null pointer. > [ivy:resolve] WARNINGS > [ivy:resolve] :: > [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: > [ivy:resolve] :: > [ivy:resolve] :: acme#SomeJar;+: java.lang.NullPointerException at > org.apache.ivy.plugins.resolver.Bas > icResolver.resolveAndCheckRevision(BasicResolver.java:457) > [ivy:resolve] :: > I have a filesystem resolver with the following pattern: > > pattern="\\someServer\IvyRepo\external\[organisation]\[artifact]-[revision].[ext]"/> > pattern="\\someServer\IvyRepo\external\[organisation]\[artifact].[ext]"/> > > (Some artifacts in the 3rd party library don't have versions). > The file path is: > \\someServer\IvyRepo\external\acme\SomeJar.jar > The dependancy is: > > From a client point of view, the module doesn't care what version... just get > the latest and if there is no version just get the current one. > There are a number of work arounds... > a) Ensure all JARs in the repository have a version ... Invent a version on > ones which don't have any version. (Probably a good idea anyway). >- If this is the case then thats fine. It should just be a documented > feature :) > b) Use the beta version of ivy. > c) Change the client module to specify no revision rev="" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-980) NullPointerException when resolving module without revision in the pattern
[ https://issues.apache.org/jira/browse/IVY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-980. --- Resolution: Fixed I've committed a fix into svn trunk. Could you please give it a try to see if it has solved your problem and provide us your feedback? thanks, Maarten > NullPointerException when resolving module without revision in the pattern > -- > > Key: IVY-980 > URL: https://issues.apache.org/jira/browse/IVY-980 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1, 2.0-RC2 > Environment: Intel / Windows 2000 (Server) / Windows XP. >Reporter: Craig paddon >Assignee: Maarten Coene > Fix For: trunk > > > When I switched to RC1 or RC2 I experianced the following error (which worked > fine in previuos versions). > When there is a dependancy which uses the rev="+" and there is no revision on > the artifact in the repository the resolver throws a null pointer. > [ivy:resolve] WARNINGS > [ivy:resolve] :: > [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: > [ivy:resolve] :: > [ivy:resolve] :: acme#SomeJar;+: java.lang.NullPointerException at > org.apache.ivy.plugins.resolver.Bas > icResolver.resolveAndCheckRevision(BasicResolver.java:457) > [ivy:resolve] :: > I have a filesystem resolver with the following pattern: > > pattern="\\someServer\IvyRepo\external\[organisation]\[artifact]-[revision].[ext]"/> > pattern="\\someServer\IvyRepo\external\[organisation]\[artifact].[ext]"/> > > (Some artifacts in the 3rd party library don't have versions). > The file path is: > \\someServer\IvyRepo\external\acme\SomeJar.jar > The dependancy is: > > From a client point of view, the module doesn't care what version... just get > the latest and if there is no version just get the current one. > There are a number of work arounds... > a) Ensure all JARs in the repository have a version ... Invent a version on > ones which don't have any version. (Probably a good idea anyway). >- If this is the case then thats fine. It should just be a documented > feature :) > b) Use the beta version of ivy. > c) Change the client module to specify no revision rev="" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-976) Ivy Standalone setting to overwrite publications
[ https://issues.apache.org/jira/browse/IVY-976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-976: -- Fix Version/s: (was: trunk) 2.0 This will be included in the 2.0.0 final release. > Ivy Standalone setting to overwrite publications > - > > Key: IVY-976 > URL: https://issues.apache.org/jira/browse/IVY-976 > Project: Ivy > Issue Type: Improvement > Components: Core > Environment: I'm using ivy standalone with windows and nant for c# > development. >Reporter: Tomas Roos >Assignee: Maarten Coene > Fix For: 2.0 > > > Ivy is working very well with our setup. > We are using ivy standalone + nant + subversion. > Any way the issue is when a dll has same size as the previous but the > versionnumber might diff then it wont publish the new dependencies because > the overwrite is set to false. > It would be nice to be able to set this somewhere, mabe in the commandline. > Doesnt matter as long as there is a posiblity. > Thanks in advance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-960) Log levels aren't respected in certain cases using the standalone functionality
[ https://issues.apache.org/jira/browse/IVY-960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-960: -- Fix Version/s: (was: trunk) 2.0 This will be included in the 2.0.0 final release. > Log levels aren't respected in certain cases using the standalone > functionality > --- > > Key: IVY-960 > URL: https://issues.apache.org/jira/browse/IVY-960 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1 > Environment: Windows XP > java version "1.5.0_14" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_14-b03) > Java HotSpot(TM) Client VM (build 1.5.0_14-b03, mixed mode) >Reporter: Patrick Woodworth >Assignee: Maarten Coene > Fix For: 2.0 > > Attachments: ivypushcntxt.patch > > > When using Ivy in standalone mode and passing the -dependency option, it is > impossible to suppress a "loading settings" banner from being the first line > of output, regardless of whether the -warn or -error flags have been passed. > For some reason this is not a problem when using the -ivy option instead of > -dependency. The attached patch solves the problem in my environment. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-961) NPE in LogReportOutputter
[
https://issues.apache.org/jira/browse/IVY-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-961:
--
Fix Version/s: (was: trunk)
2.0
This will be included in the 2.0.0 final release.
> NPE in LogReportOutputter
> -
>
> Key: IVY-961
> URL: https://issues.apache.org/jira/browse/IVY-961
> Project: Ivy
> Issue Type: Bug
>Affects Versions: 2.0-RC1
>Reporter: Hans Dockter
>Assignee: Maarten Coene
> Fix For: 2.0
>
> Attachments: npe.zip
>
>
> If the variable {{}} is
> set to true, the LogReportOutputter throws an NPE in line 70.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-980) NullPointerException when resolving module without revision in the pattern
[ https://issues.apache.org/jira/browse/IVY-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-980: -- Fix Version/s: (was: trunk) 2.0 This will be fixed in the 2.0.0 final release. > NullPointerException when resolving module without revision in the pattern > -- > > Key: IVY-980 > URL: https://issues.apache.org/jira/browse/IVY-980 > Project: Ivy > Issue Type: Bug > Components: Core >Affects Versions: 2.0-RC1, 2.0-RC2 > Environment: Intel / Windows 2000 (Server) / Windows XP. >Reporter: Craig paddon >Assignee: Maarten Coene > Fix For: 2.0 > > > When I switched to RC1 or RC2 I experianced the following error (which worked > fine in previuos versions). > When there is a dependancy which uses the rev="+" and there is no revision on > the artifact in the repository the resolver throws a null pointer. > [ivy:resolve] WARNINGS > [ivy:resolve] :: > [ivy:resolve] :: UNRESOLVED DEPENDENCIES :: > [ivy:resolve] :: > [ivy:resolve] :: acme#SomeJar;+: java.lang.NullPointerException at > org.apache.ivy.plugins.resolver.Bas > icResolver.resolveAndCheckRevision(BasicResolver.java:457) > [ivy:resolve] :: > I have a filesystem resolver with the following pattern: > > pattern="\\someServer\IvyRepo\external\[organisation]\[artifact]-[revision].[ext]"/> > pattern="\\someServer\IvyRepo\external\[organisation]\[artifact].[ext]"/> > > (Some artifacts in the 3rd party library don't have versions). > The file path is: > \\someServer\IvyRepo\external\acme\SomeJar.jar > The dependancy is: > > From a client point of view, the module doesn't care what version... just get > the latest and if there is no version just get the current one. > There are a number of work arounds... > a) Ensure all JARs in the repository have a version ... Invent a version on > ones which don't have any version. (Probably a good idea anyway). >- If this is the case then thats fine. It should just be a documented > feature :) > b) Use the beta version of ivy. > c) Change the client module to specify no revision rev="" -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-965) Support useOrigin for artifacts with a set url attribute
[
https://issues.apache.org/jira/browse/IVY-965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene updated IVY-965:
--
Fix Version/s: (was: trunk)
2.0
This will be included in the 2.0.0 final release.
> Support useOrigin for artifacts with a set url attribute
>
>
> Key: IVY-965
> URL: https://issues.apache.org/jira/browse/IVY-965
> Project: Ivy
> Issue Type: Improvement
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: alex322
>Assignee: Maarten Coene
> Fix For: 2.0
>
>
> Currently artifacts with a specified url are always considered remote because
> the code instantiates URLResource.
> This change would allow using FileResource when the url is "file://*".
> {noformat}
> --- BasicResolver.java.originalMon Oct 20 16:47:15 2008
> +++ BasicResolver.java Mon Nov 03 15:38:48 2008
> @@ -64,6 +64,8 @@
> import org.apache.ivy.plugins.repository.ArtifactResourceResolver;
> import org.apache.ivy.plugins.repository.Resource;
> import org.apache.ivy.plugins.repository.ResourceDownloader;
> +import org.apache.ivy.plugins.repository.file.FileRepository;
> +import org.apache.ivy.plugins.repository.file.FileResource;
> import org.apache.ivy.plugins.repository.url.URLRepository;
> import org.apache.ivy.plugins.repository.url.URLResource;
> import org.apache.ivy.plugins.resolver.util.MDResolvedResource;
> @@ -918,7 +920,14 @@
> URL url = artifact.getUrl();
> Message.verbose("\tusing url for " + artifact + ": " + url);
> logArtifactAttempt(artifact, url.toExternalForm());
> -ret = new ResolvedResource(new URLResource(url),
> artifact.getModuleRevisionId()
> +Resource resource;
> +if ("file".equals(url.getProtocol())) {
> + resource = new FileResource(new FileRepository(), new
> File(url.getPath()));
> +}
> +else {
> + resource = new URLResource(url);
> +}
> + ret = new ResolvedResource(resource,
> artifact.getModuleRevisionId()
> .getRevision());
> }
> return ret;
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-975) IO problem while parsing ivy file (Resetting to invalid mark)
[ https://issues.apache.org/jira/browse/IVY-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-975: -- Fix Version/s: (was: trunk) 2.0 This will be fixed in the 2.0.0 final release. > IO problem while parsing ivy file (Resetting to invalid mark) > - > > Key: IVY-975 > URL: https://issues.apache.org/jira/browse/IVY-975 > Project: Ivy > Issue Type: Bug > Components: Maven Compatibility >Affects Versions: 2.0-RC2 > Environment: Windows XP SP2, Java 1.6.0_07, Ant 1.7.1 >Reporter: Nicolas Labrot >Assignee: Maarten Coene > Fix For: 2.0 > > Attachments: IvyIssue.rar > > > I'm trying to resolve MyFaces 1.1.6 > > But Ivy return this error : > [ivy:retrieve] :: problems summary :: > [ivy:retrieve] WARNINGS > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/myfaces/6/myfaces-6.pom: Resetting to invalid mark > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/core/myfaces-core-project/1.1.6/myfaces-core-project-1.1.6.pom: > Impossible to load parent for > (..)/.ivy2/cache/org.apache.myfaces.core/myfaces-core-project/ivy-1.1.6.xml.original. > Parent=org.apache.myfaces#myfaces;6 > [ivy:retrieve] io problem while parsing ivy file: > (..)/org/apache/myfaces/core/myfaces-api/1.1.6/myfaces-api-1.1.6.pom: > Impossible to load parent for > (..)/.ivy2/cache/org.apache.myfaces.core/myfaces-api/ivy-1.1.6.xml.original. > Parent=org.apache.myfaces.core#myfaces-core-project;1.1.6 > [ivy:retrieve] module not found: > org.apache.myfaces.core#myfaces-api;1.1.6 > [ivy:retrieve] artifactory: tried > [ivy:retrieve] (..)/org/apache/myfaces/myfaces/6/myfaces-6.pom > [ivy:retrieve] :: > [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: > [ivy:retrieve] :: > [ivy:retrieve] :: org.apache.myfaces.core#myfaces-api;1.1.6: not found > [ivy:retrieve] :: > [ivy:retrieve] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-988) Files with '#' in their names fail to download
Files with '#' in their names fail to download -- Key: IVY-988 URL: https://issues.apache.org/jira/browse/IVY-988 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0 Reporter: Maarten Coene This problem was reported in IVY-962 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-962) Files with non-latin symbols fail to download
[
https://issues.apache.org/jira/browse/IVY-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-962.
---
Resolution: Fixed
Fix Version/s: 2.0
I've created a new issue for the problem with the '#' and mark this one as
fixed.
> Files with non-latin symbols fail to download
> -
>
> Key: IVY-962
> URL: https://issues.apache.org/jira/browse/IVY-962
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC1
>Reporter: Yegor Yarko
>Assignee: Maarten Coene
> Fix For: 2.0
>
> Attachments: .ivy.zip, ivy.xml, output.txt, testOnPublicServer.zip,
> русский.txt
>
>
> When I try to download a file with russian characters via Ivy (via Ant
> tasks), Ivy fails to download it
> Server's ivy.xml part:
> {code:xml}
>
> {code}
> Console output
> {noformat}
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: FAILED DOWNLOADS::
> [ivy:retrieve] WARN::: ^ see resolution messages for details ^ ::
> [ivy:retrieve] WARN:::
> [ivy:retrieve] WARN::: org#bt413;8!Ёєёёъшщ.txt
> [ivy:retrieve] WARN:::
> {noformat}
> Please find the client's ivy.xml, Ivy cache and output in the attachments.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-994) Extend packager resolver to allow arbitrary ant tasks in build instructions
[ https://issues.apache.org/jira/browse/IVY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-994: -- Fix Version/s: (was: unspecified) > Extend packager resolver to allow arbitrary ant tasks in build instructions > --- > > Key: IVY-994 > URL: https://issues.apache.org/jira/browse/IVY-994 > Project: Ivy > Issue Type: Improvement > Components: Core >Affects Versions: 2.0-RC2 >Reporter: Archie Cobbs >Assignee: Maarten Coene > Attachments: restricted.txt > > > Some software requires more than just move, copy, unzip, etc. in the packager > resolver build instructions to build the software. E.g., Javadoc can only be > constructed by building it with ant. > Request extending packager resolver to support arbitrary build instructions. > Do this via a new "restricted" configuration attribute, which when true (the > default) reproduces the existing behavior, but when false, allows arbitrary > ant tasks in the build instructions. > See attached patch for proposed implementation and documentation updates. > Background discussion: > [here|http://www.nabble.com/Relaxing-allowed-ant-tasks-in-packager.xsl-td21305175.html]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-994) Extend packager resolver to allow arbitrary ant tasks in build instructions
[ https://issues.apache.org/jira/browse/IVY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene updated IVY-994: -- Fix Version/s: (was: 2.0) unspecified Assignee: Maarten Coene > Extend packager resolver to allow arbitrary ant tasks in build instructions > --- > > Key: IVY-994 > URL: https://issues.apache.org/jira/browse/IVY-994 > Project: Ivy > Issue Type: Improvement > Components: Core >Affects Versions: 2.0-RC2 >Reporter: Archie Cobbs >Assignee: Maarten Coene > Attachments: restricted.txt > > > Some software requires more than just move, copy, unzip, etc. in the packager > resolver build instructions to build the software. E.g., Javadoc can only be > constructed by building it with ant. > Request extending packager resolver to support arbitrary build instructions. > Do this via a new "restricted" configuration attribute, which when true (the > default) reproduces the existing behavior, but when false, allows arbitrary > ant tasks in the build instructions. > See attached patch for proposed implementation and documentation updates. > Background discussion: > [here|http://www.nabble.com/Relaxing-allowed-ant-tasks-in-packager.xsl-td21305175.html]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-995) Nullpointer at PomModuleDescriptorBuilder.addDependency
[
https://issues.apache.org/jira/browse/IVY-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene reassigned IVY-995:
-
Assignee: Maarten Coene
> Nullpointer at PomModuleDescriptorBuilder.addDependency
> ---
>
> Key: IVY-995
> URL: https://issues.apache.org/jira/browse/IVY-995
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC2
> Environment: jdk 1.5.0_13
> ant 1.7.1
> osx 10.5.5
>Reporter: lalyos
>Assignee: Maarten Coene
>
> While iwas trying to resolve a new dependency on
>org="net.sourceforge.jwebunit" rev="1.5" conf="test->default"/>
> i got the following nullpointer exception:
> [ivy:retrieve]public3: found md file for
> net.sourceforge.jwebunit#jwebunit-htmlunit-plugin;1.5
> [ivy:retrieve]=>
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom
> (1.5)
> [ivy:retrieve] downloading
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom
> ...
> [ivy:retrieve]public3: downloading
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom
> [ivy:retrieve]public3: downloading
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom.sha1
> [ivy:retrieve] sha1 OK for
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom
> [ivy:retrieve][SUCCESSFUL ]
> net.sourceforge.jwebunit#jwebunit-htmlunit-plugin;1.5!jwebunit-htmlunit-plugin.pom(pom.original)
> (588ms)
> [ivy:retrieve] default: Checking cache for: dependency:
> net.sourceforge.jwebunit#jwebunit;1.5 {}
> [ivy:retrieve] default: module revision found in cache:
> net.sourceforge.jwebunit#jwebunit;1.5
> [ivy:retrieve] problem occured while resolving dependency:
> net.sourceforge.jwebunit#jwebunit-htmlunit-plugin;1.5 {test=[default]} with
> public3: java.lang.NullPointerException
> [ivy:retrieve]at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorBuilder.addDependency(PomModuleDescriptorBuilder.java:291)
> [ivy:retrieve]at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:235)
> [ivy:retrieve]at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:105)
> [ivy:retrieve]at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:633)
> [ivy:retrieve]at
> org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68)
> [ivy:retrieve]at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:650)
> [ivy:retrieve]at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:939)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:538)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:261)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:500)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:126)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:126)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:126)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:169)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:271)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:671)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:757)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:679)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:551)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:235)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:193)
> [ivy:retrieve]at org.apache.ivy.Ivy.resolve(Ivy.java:502)
> [ivy:retrieve]at
> org.apache.ivy.ant.IvyResolve.doExecute(IvyResolve.jav
[jira] Resolved: (IVY-994) Extend packager resolver to allow arbitrary ant tasks in build instructions
[ https://issues.apache.org/jira/browse/IVY-994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maarten Coene resolved IVY-994. --- Resolution: Fixed Fix Version/s: 2.0 I've added your patch to the 2.0.0 release. I had to modify the packager stylesheet a bit because the subelements were matching the wrong template now (although I don't exactly understand why this was the case ...) Thanks for the contribution! Maarten > Extend packager resolver to allow arbitrary ant tasks in build instructions > --- > > Key: IVY-994 > URL: https://issues.apache.org/jira/browse/IVY-994 > Project: Ivy > Issue Type: Improvement > Components: Core >Affects Versions: 2.0-RC2 >Reporter: Archie Cobbs >Assignee: Maarten Coene > Fix For: 2.0 > > Attachments: restricted.txt > > > Some software requires more than just move, copy, unzip, etc. in the packager > resolver build instructions to build the software. E.g., Javadoc can only be > constructed by building it with ant. > Request extending packager resolver to support arbitrary build instructions. > Do this via a new "restricted" configuration attribute, which when true (the > default) reproduces the existing behavior, but when false, allows arbitrary > ant tasks in the build instructions. > See attached patch for proposed implementation and documentation updates. > Background discussion: > [here|http://www.nabble.com/Relaxing-allowed-ant-tasks-in-packager.xsl-td21305175.html]. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-995) Nullpointer at PomModuleDescriptorBuilder.addDependency
[
https://issues.apache.org/jira/browse/IVY-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maarten Coene resolved IVY-995.
---
Resolution: Fixed
Fix Version/s: 2.0
Thanks for the report.
I've committed a fix into SVN (2.0.0 branch)
Maarten
> Nullpointer at PomModuleDescriptorBuilder.addDependency
> ---
>
> Key: IVY-995
> URL: https://issues.apache.org/jira/browse/IVY-995
> Project: Ivy
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.0-RC2
> Environment: jdk 1.5.0_13
> ant 1.7.1
> osx 10.5.5
>Reporter: lalyos
>Assignee: Maarten Coene
> Fix For: 2.0
>
>
> While iwas trying to resolve a new dependency on
>org="net.sourceforge.jwebunit" rev="1.5" conf="test->default"/>
> i got the following nullpointer exception:
> [ivy:retrieve]public3: found md file for
> net.sourceforge.jwebunit#jwebunit-htmlunit-plugin;1.5
> [ivy:retrieve]=>
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom
> (1.5)
> [ivy:retrieve] downloading
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom
> ...
> [ivy:retrieve]public3: downloading
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom
> [ivy:retrieve]public3: downloading
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom.sha1
> [ivy:retrieve] sha1 OK for
> http://repo1.maven.org/maven2/net/sourceforge/jwebunit/jwebunit-htmlunit-plugin/1.5/jwebunit-htmlunit-plugin-1.5.pom
> [ivy:retrieve][SUCCESSFUL ]
> net.sourceforge.jwebunit#jwebunit-htmlunit-plugin;1.5!jwebunit-htmlunit-plugin.pom(pom.original)
> (588ms)
> [ivy:retrieve] default: Checking cache for: dependency:
> net.sourceforge.jwebunit#jwebunit;1.5 {}
> [ivy:retrieve] default: module revision found in cache:
> net.sourceforge.jwebunit#jwebunit;1.5
> [ivy:retrieve] problem occured while resolving dependency:
> net.sourceforge.jwebunit#jwebunit-htmlunit-plugin;1.5 {test=[default]} with
> public3: java.lang.NullPointerException
> [ivy:retrieve]at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorBuilder.addDependency(PomModuleDescriptorBuilder.java:291)
> [ivy:retrieve]at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:235)
> [ivy:retrieve]at
> org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:105)
> [ivy:retrieve]at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager$MyModuleDescriptorProvider.provideModule(DefaultRepositoryCacheManager.java:633)
> [ivy:retrieve]at
> org.apache.ivy.core.cache.ModuleDescriptorMemoryCache.getStale(ModuleDescriptorMemoryCache.java:68)
> [ivy:retrieve]at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.getStaledMd(DefaultRepositoryCacheManager.java:650)
> [ivy:retrieve]at
> org.apache.ivy.core.cache.DefaultRepositoryCacheManager.cacheModuleDescriptor(DefaultRepositoryCacheManager.java:939)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.BasicResolver.parse(BasicResolver.java:538)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.BasicResolver.getDependency(BasicResolver.java:261)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.IBiblioResolver.getDependency(IBiblioResolver.java:500)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:126)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:126)
> [ivy:retrieve]at
> org.apache.ivy.plugins.resolver.ChainResolver.getDependency(ChainResolver.java:126)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.IvyNode.loadData(IvyNode.java:169)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.VisitNode.loadData(VisitNode.java:271)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:671)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.doFetchDependencies(ResolveEngine.java:757)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.fetchDependencies(ResolveEngine.java:679)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.getDependencies(ResolveEngine.java:551)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:235)
> [ivy:retrieve]at
> org.apache.ivy.core.resolve.ResolveEngine.resolve(ResolveEngine.java:193)
> [ivy:retrieve]at or
