[jira] [Closed] (IVY-444) provide versioned doc online
[ https://issues.apache.org/jira/browse/IVY-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin closed IVY-444. Resolution: Fixed Indeed, and it's been for a while! Thanks for pointing that out. > provide versioned doc online > > > Key: IVY-444 > URL: https://issues.apache.org/jira/browse/IVY-444 > Project: Ivy > Issue Type: Improvement > Components: Documentation >Reporter: Xavier Hanin > > The current online version of the documentation reflects the latest change, > and can cause confusion for new users who download Ivy 1.4.1. > The suggestion is to provide a snapshot of the 1.4.1 doc as well as latest > doc version online. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] Created: (IVY-1097) configuration groups
configuration groups
Key: IVY-1097
URL: https://issues.apache.org/jira/browse/IVY-1097
Project: Ivy
Issue Type: New Feature
Components: Core
Reporter: Xavier Hanin
Assignee: Xavier Hanin
In modules having a lot of configurations, sometimes it would be nice to be
able to define a group of configurations based on their attributes (including
extra attributes). The proposed syntax is {{*[att=value]}}
For instance, one could define an extra attribute named 'axis' on the
configuration, and then refer to all configurations where 'axis' is 'platform'
with {{*[axis=platform]}}.
Here is an example of Ivy file using this notation:
{noformat}
ivy-module version=1.0 xmlns:e=http://ant.apache.org/ivy/extra;
info organisation=org5
module=mod5.1
revision=4.5
status=integration
publication=2009050111
/
configurations
conf name=A /
conf name=B /
conf name=windows e:axis=platform /
conf name=linux e:axis=platform/
/configurations
publications
artifact name=art51A type=jar conf=A,*[axis=platform]/
artifact name=art51B type=jar conf=B,*[axis=platform]/
artifact name=art51B type=dll conf=B,windows/
artifact name=art51B type=so conf=B,linux/
/publications
dependencies
dependency org=org1 name=mod1.2 rev=2.0
conf=B,*[axis=platform]-default/
/dependencies
/ivy-module
{noformat}
In this ivy file, {{*[axis=platform]}} is equivalent to {{windows,linux}}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-1083) transitive dependencies and conflict management
transitive dependencies and conflict management
---
Key: IVY-1083
URL: https://issues.apache.org/jira/browse/IVY-1083
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.1.0-RC1, 2.0
Reporter: Xavier Hanin
Assignee: Xavier Hanin
let's say we have the following modules:
{noformat}
mod20.4 - mod20.3;1.0 mod20.2;1.0
mod20.3;1.0 - mod20.1;1.0
mod20.2;1.0 - mod20.1;1.1 (transitive false)
mod20.1;1.0 - mod1.2;1.0
mod20.1;1.1 - mod1.2;1.0
{noformat}
when the conflict manager evicts mod20.1;1.0 in favor of mod20.1;1.1, it loses
the information that the dependency was transitive from mod20.3, and as such
transitively exclude mod1.2.
Note that if the dependencies in mod20.4 are expressed the other way
(mod20.2;1.0 mod20.3;1.0) then transitivity is handled correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1083) transitive dependencies and conflict management
[
https://issues.apache.org/jira/browse/IVY-1083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-1083.
---
Resolution: Fixed
Fix Version/s: trunk
I've added a unit test and fixed the problem.
transitive dependencies and conflict management
---
Key: IVY-1083
URL: https://issues.apache.org/jira/browse/IVY-1083
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0, 2.1.0-RC1
Reporter: Xavier Hanin
Assignee: Xavier Hanin
Fix For: trunk
let's say we have the following modules:
{noformat}
mod20.4 - mod20.3;1.0 mod20.2;1.0
mod20.3;1.0 - mod20.1;1.0
mod20.2;1.0 - mod20.1;1.1 (transitive false)
mod20.1;1.0 - mod1.2;1.0
mod20.1;1.1 - mod1.2;1.0
{noformat}
when the conflict manager evicts mod20.1;1.0 in favor of mod20.1;1.1, it
loses the information that the dependency was transitive from mod20.3, and as
such transitively exclude mod1.2.
Note that if the dependencies in mod20.4 are expressed the other way
(mod20.2;1.0 mod20.3;1.0) then transitivity is handled correctly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-1084) post-retrieve-artifact-trigger
post-retrieve-artifact-trigger -- Key: IVY-1084 URL: https://issues.apache.org/jira/browse/IVY-1084 Project: Ivy Issue Type: Improvement Components: Core Affects Versions: 2.1.0-RC1, 2.0 Reporter: Xavier Hanin Assignee: Xavier Hanin adding an event after an artifact has been retrieved to final destination would be useful -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-987) Error message: impossible to get artifacts when data has not been loaded , on certain modules only
[ https://issues.apache.org/jira/browse/IVY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680003#action_12680003 ] Xavier Hanin commented on IVY-987: -- Sorry for the delay on this issue, too hard to find free time ATM. Maarten (or anybody), maybe you already have a unit test reproducing the problem? It would help me to investigate and hopefully fix this bug. Error message: impossible to get artifacts when data has not been loaded , on certain modules only Key: IVY-987 URL: https://issues.apache.org/jira/browse/IVY-987 Project: Ivy Issue Type: Bug Affects Versions: 2.0 Environment: ubuntu 8.04, java .1.6.0_06 Java HotSpot(TM) Client VM, calling external ant 1.7 from netbeans 6.1 IDE, ivy ant task in ants home lib dir Reporter: K. Rekk I found a similiar post here: http://www.mail-archive.com/ivy-u...@ant.apache.org/msg01766.html Everything worked fine with 2.0.0 beta . It's just a simple test and dom4j seems to cause the problem with standard ivysettings : dependencies dependency org=dom4j name=dom4j rev=1.6.1/ dependency org=log4j name=log4j rev=1.2.9/ dependency org=junit name=junit rev=4.5/ /dependencies /ivy-module Removing dom4j makes it work again. So I dont know, is it dom4j or ivy causing the problem? output: init: deps-jar: ivy-retrieve: No ivy:settings found for the default reference 'ivy.instance'. A default instance will be used no settings file found, using default... :: loading settings :: url = jar:file:/home/kostja/VZG/soa-workarea-ref/tools/ant/lib/ivy-2.0.0-rc2.jar!/org/apache/ivy/core/settings/ivysettings.xml :: resolving dependencies :: gbv.de#test;work...@myhome confs: [default] found dom4j#dom4j;1.6.1 in public found xml-apis#xml-apis;1.0.b2 in public found jaxme#jaxme-api;0.3 in public found jaxen#jaxen;1.1-beta-6 in public found jdom#jdom;1.0 in public found xerces#xmlParserAPIs;2.6.2 in public found xerces#xercesImpl;2.6.2 in public found xom#xom;1.0b3 in public found com.ibm.icu#icu4j;2.6.1 in public found org.ccil.cowan.tagsoup#tagsoup;0.9.7 in public found msv#xsdlib;20030807 in public found msv#relaxngDatatype;20030807 in public found pull-parser#pull-parser;2 in public found xpp3#xpp3;1.1.3.3 in public found stax#stax-api;1.0 in public found log4j#log4j;1.2.9 in public found junit#junit;4.5 in public :: problems summary :: ERRORS impossible to get artifacts when data has not been loaded. IvyNode = xalan#xalan;2.5.1 :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS /home/kostja/VZG/soa-workarea-ref/projects/Test/build.xml:15: impossible to resolve dependencies: java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = xalan#xalan;2.5.1 BUILD FAILED (total time: 0 seconds) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-987) Error message: impossible to get artifacts when data has not been loaded , on certain modules only
[ https://issues.apache.org/jira/browse/IVY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12680018#action_12680018 ] Xavier Hanin commented on IVY-987: -- I've investigated using the dependencies description provided here, I've reproduced and fixed the bug (at least in this case). I haven't changed how forced dependencies are handled in conflict managers, so there may still need some investigation in this area, I'm not really sure. What I've changed is just the way * configurations is resolved during conflict management, to be consistent with how they are handled in fetchDependencies. I haven't had time to add a junit test, so I don't mark the bug resolved now. I don't think I'll have much time in the coming weeks, so if someone can submit or commit a junit test it would be really nice. Otherwise we may also decide to mark this as resolved without a unit test to release 2.0.1. Error message: impossible to get artifacts when data has not been loaded , on certain modules only Key: IVY-987 URL: https://issues.apache.org/jira/browse/IVY-987 Project: Ivy Issue Type: Bug Affects Versions: 2.0 Environment: ubuntu 8.04, java .1.6.0_06 Java HotSpot(TM) Client VM, calling external ant 1.7 from netbeans 6.1 IDE, ivy ant task in ants home lib dir Reporter: K. Rekk I found a similiar post here: http://www.mail-archive.com/ivy-u...@ant.apache.org/msg01766.html Everything worked fine with 2.0.0 beta . It's just a simple test and dom4j seems to cause the problem with standard ivysettings : dependencies dependency org=dom4j name=dom4j rev=1.6.1/ dependency org=log4j name=log4j rev=1.2.9/ dependency org=junit name=junit rev=4.5/ /dependencies /ivy-module Removing dom4j makes it work again. So I dont know, is it dom4j or ivy causing the problem? output: init: deps-jar: ivy-retrieve: No ivy:settings found for the default reference 'ivy.instance'. A default instance will be used no settings file found, using default... :: loading settings :: url = jar:file:/home/kostja/VZG/soa-workarea-ref/tools/ant/lib/ivy-2.0.0-rc2.jar!/org/apache/ivy/core/settings/ivysettings.xml :: resolving dependencies :: gbv.de#test;work...@myhome confs: [default] found dom4j#dom4j;1.6.1 in public found xml-apis#xml-apis;1.0.b2 in public found jaxme#jaxme-api;0.3 in public found jaxen#jaxen;1.1-beta-6 in public found jdom#jdom;1.0 in public found xerces#xmlParserAPIs;2.6.2 in public found xerces#xercesImpl;2.6.2 in public found xom#xom;1.0b3 in public found com.ibm.icu#icu4j;2.6.1 in public found org.ccil.cowan.tagsoup#tagsoup;0.9.7 in public found msv#xsdlib;20030807 in public found msv#relaxngDatatype;20030807 in public found pull-parser#pull-parser;2 in public found xpp3#xpp3;1.1.3.3 in public found stax#stax-api;1.0 in public found log4j#log4j;1.2.9 in public found junit#junit;4.5 in public :: problems summary :: ERRORS impossible to get artifacts when data has not been loaded. IvyNode = xalan#xalan;2.5.1 :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS /home/kostja/VZG/soa-workarea-ref/projects/Test/build.xml:15: impossible to resolve dependencies: java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = xalan#xalan;2.5.1 BUILD FAILED (total time: 0 seconds) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1027) resolver, which can do automatic build of dependencies
[ https://issues.apache.org/jira/browse/IVY-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671166#action_12671166 ] Xavier Hanin commented on IVY-1027: --- I've not had the time to have a look at the code, but does it require change in Ivy core? Maybe this could be provided as a separate project instead of being included in Ivy core? resolver, which can do automatic build of dependencies -- Key: IVY-1027 URL: https://issues.apache.org/jira/browse/IVY-1027 Project: Ivy Issue Type: New Feature Environment: any. Reporter: Ruslan Shevchenko Attachments: ivy.build.plugin-src-1.0.tar.gz Good day. I wrote resolver, which can do automatic build and publish of dependencies, if their source code is available. (detailed description at http://redmine.gradsoft.ua/wiki/jungleplatform/Ivybuildplugin) I want donate all code to ivy project and include resolver to ivy core. Source archive is in attachment. Now this is separate module, I need some advise before preparing path to ivy (It is necessory to rewrite resolver in JDK-1.4 ? Where to put testcases ?) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-987) Error message: impossible to get artifacts when data has not been loaded , on certain modules only
[ https://issues.apache.org/jira/browse/IVY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670872#action_12670872 ] Xavier Hanin commented on IVY-987: -- I'll try to find some time, but I'm currently overbooked with my job, so I can't promise anything, at least in the coming weeks... Error message: impossible to get artifacts when data has not been loaded , on certain modules only Key: IVY-987 URL: https://issues.apache.org/jira/browse/IVY-987 Project: Ivy Issue Type: Bug Affects Versions: 2.0 Environment: ubuntu 8.04, java .1.6.0_06 Java HotSpot(TM) Client VM, calling external ant 1.7 from netbeans 6.1 IDE, ivy ant task in ants home lib dir Reporter: K. Rekk I found a similiar post here: http://www.mail-archive.com/ivy-u...@ant.apache.org/msg01766.html Everything worked fine with 2.0.0 beta . It's just a simple test and dom4j seems to cause the problem with standard ivysettings : dependencies dependency org=dom4j name=dom4j rev=1.6.1/ dependency org=log4j name=log4j rev=1.2.9/ dependency org=junit name=junit rev=4.5/ /dependencies /ivy-module Removing dom4j makes it work again. So I dont know, is it dom4j or ivy causing the problem? output: init: deps-jar: ivy-retrieve: No ivy:settings found for the default reference 'ivy.instance'. A default instance will be used no settings file found, using default... :: loading settings :: url = jar:file:/home/kostja/VZG/soa-workarea-ref/tools/ant/lib/ivy-2.0.0-rc2.jar!/org/apache/ivy/core/settings/ivysettings.xml :: resolving dependencies :: gbv.de#test;work...@myhome confs: [default] found dom4j#dom4j;1.6.1 in public found xml-apis#xml-apis;1.0.b2 in public found jaxme#jaxme-api;0.3 in public found jaxen#jaxen;1.1-beta-6 in public found jdom#jdom;1.0 in public found xerces#xmlParserAPIs;2.6.2 in public found xerces#xercesImpl;2.6.2 in public found xom#xom;1.0b3 in public found com.ibm.icu#icu4j;2.6.1 in public found org.ccil.cowan.tagsoup#tagsoup;0.9.7 in public found msv#xsdlib;20030807 in public found msv#relaxngDatatype;20030807 in public found pull-parser#pull-parser;2 in public found xpp3#xpp3;1.1.3.3 in public found stax#stax-api;1.0 in public found log4j#log4j;1.2.9 in public found junit#junit;4.5 in public :: problems summary :: ERRORS impossible to get artifacts when data has not been loaded. IvyNode = xalan#xalan;2.5.1 :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS /home/kostja/VZG/soa-workarea-ref/projects/Test/build.xml:15: impossible to resolve dependencies: java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = xalan#xalan;2.5.1 BUILD FAILED (total time: 0 seconds) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-996) Remove excessive HEAD requests for URL repository
[ https://issues.apache.org/jira/browse/IVY-996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669636#action_12669636 ] Xavier Hanin commented on IVY-996: -- Thanks to Nicolas Lalevée, an update site with trunk versions of both IvyDE and Ivy is now available here: http://hudson.zones.apache.org/hudson/view/Ant/job/IvyDE-updatesite/lastSuccessfulBuild/artifact/trunk/build/ Please use this to test the trunk Ivy version and tell me if it works as you expect. Remove excessive HEAD requests for URL repository - Key: IVY-996 URL: https://issues.apache.org/jira/browse/IVY-996 Project: Ivy Issue Type: Improvement Components: Core Affects Versions: 2.0-RC2 Reporter: Eric Anderson Assignee: Xavier Hanin Fix For: trunk h3. Fixing useless extra HEAD requests When searching for an artifact named project version 2.2.+ for organization org, Ivy attempts HEAD requests for completely not possible versions. IE: /org/project/0.9.2/ivy-0.9.2.xml This is not terribly painful unless you have thousands of builds and are not on the same network as your ivy server. h3. Are HEAD requests even necessary? Simply getting a directory listing should be good enough to determine if there is an artifact (for choosing latest-release). Now, after one is chosen, if no ivy.xml file exists, I could understand trying the next one, but trying all of them, just to select the latest one anyways seems like a complete waste. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-1022) Forced resolver behavior is inappropriate for ivy:install
[ https://issues.apache.org/jira/browse/IVY-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin updated IVY-1022: -- Issue Type: Improvement (was: Bug) I don't classify this as a bug, because if you use a forced resolver in your source resolver chain, it's not that much a bug what happen. It's more a settings problem IMHO. But having an easy way to prevent forced resolvers from being forced during install could be an interesting improvement. Forced resolver behavior is inappropriate for ivy:install - Key: IVY-1022 URL: https://issues.apache.org/jira/browse/IVY-1022 Project: Ivy Issue Type: Improvement Components: Ant Affects Versions: 2.0 Reporter: Carlton Brown I tried to install a certain revision of a module from a chained resolver to an fs resolver, and observed that Ivy installed a revision other than what I specified. After investigation I noticed that the chain contained a forced fs resolver. I removed the forced resolver from the chain, replacing it with an equivalent un-forced fs resolver. The install worked correctly after that. I think that ivy:install should not be doing any dynamic version resolution at all. It should in every case use the literal module identifiers that are passed to it. This being the case, install should ignore a force attribute wherever it is encountered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-987) Error message: impossible to get artifacts when data has not been loaded , on certain modules only
[ https://issues.apache.org/jira/browse/IVY-987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668391#action_12668391 ] Xavier Hanin commented on IVY-987: -- Maybe in this situation the conflict manager should resolve the conflict as if they were not forced. I mean, the conflict manager could first check if there is at least one revision being forced, if it is the case it ignores non forced revision and do its usual job with the forced revisions only. Does it make sense? Error message: impossible to get artifacts when data has not been loaded , on certain modules only Key: IVY-987 URL: https://issues.apache.org/jira/browse/IVY-987 Project: Ivy Issue Type: Bug Affects Versions: 2.0 Environment: ubuntu 8.04, java .1.6.0_06 Java HotSpot(TM) Client VM, calling external ant 1.7 from netbeans 6.1 IDE, ivy ant task in ants home lib dir Reporter: K. Rekk I found a similiar post here: http://www.mail-archive.com/ivy-u...@ant.apache.org/msg01766.html Everything worked fine with 2.0.0 beta . It's just a simple test and dom4j seems to cause the problem with standard ivysettings : dependencies dependency org=dom4j name=dom4j rev=1.6.1/ dependency org=log4j name=log4j rev=1.2.9/ dependency org=junit name=junit rev=4.5/ /dependencies /ivy-module Removing dom4j makes it work again. So I dont know, is it dom4j or ivy causing the problem? output: init: deps-jar: ivy-retrieve: No ivy:settings found for the default reference 'ivy.instance'. A default instance will be used no settings file found, using default... :: loading settings :: url = jar:file:/home/kostja/VZG/soa-workarea-ref/tools/ant/lib/ivy-2.0.0-rc2.jar!/org/apache/ivy/core/settings/ivysettings.xml :: resolving dependencies :: gbv.de#test;work...@myhome confs: [default] found dom4j#dom4j;1.6.1 in public found xml-apis#xml-apis;1.0.b2 in public found jaxme#jaxme-api;0.3 in public found jaxen#jaxen;1.1-beta-6 in public found jdom#jdom;1.0 in public found xerces#xmlParserAPIs;2.6.2 in public found xerces#xercesImpl;2.6.2 in public found xom#xom;1.0b3 in public found com.ibm.icu#icu4j;2.6.1 in public found org.ccil.cowan.tagsoup#tagsoup;0.9.7 in public found msv#xsdlib;20030807 in public found msv#relaxngDatatype;20030807 in public found pull-parser#pull-parser;2 in public found xpp3#xpp3;1.1.3.3 in public found stax#stax-api;1.0 in public found log4j#log4j;1.2.9 in public found junit#junit;4.5 in public :: problems summary :: ERRORS impossible to get artifacts when data has not been loaded. IvyNode = xalan#xalan;2.5.1 :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS /home/kostja/VZG/soa-workarea-ref/projects/Test/build.xml:15: impossible to resolve dependencies: java.lang.IllegalStateException: impossible to get artifacts when data has not been loaded. IvyNode = xalan#xalan;2.5.1 BUILD FAILED (total time: 0 seconds) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (IVY-1018) include jsch classes in ivy jar
[ https://issues.apache.org/jira/browse/IVY-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin closed IVY-1018. - Resolution: Fixed Including jsch in our distribution is the best we can do, we won't package it in ivy.jar itself. include jsch classes in ivy jar --- Key: IVY-1018 URL: https://issues.apache.org/jira/browse/IVY-1018 Project: Ivy Issue Type: Wish Components: Core Environment: any Reporter: Ruslan Shevchenko Priority: Minor Original Estimate: 24h Remaining Estimate: 24h It would be good include copy of jsch in ivy.jar -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1016) Patch to add an ivy:eclipse ant task that generates Eclipse .classpath files
[
https://issues.apache.org/jira/browse/IVY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667648#action_12667648
]
Xavier Hanin commented on IVY-1016:
---
And don't forget to talk about it on the user mailing list, and also add a link
to it on the wiki.
Patch to add an ivy:eclipse ant task that generates Eclipse .classpath files
Key: IVY-1016
URL: https://issues.apache.org/jira/browse/IVY-1016
Project: Ivy
Issue Type: New Feature
Components: Ant
Affects Versions: trunk
Reporter: Jing Xue
Attachments: EclipseClasspath.java
I put together a post-resolve ivy:eclipse task that updates the Eclipse
.classpath file according to the result of ivy:resolve. It also will
discover any source jars if they are part of the resolve/download, and
automatically attach them to the corresponding entries.
For example, I have this entry in ivy.xml:
{code:xml|title=ivy.xml}
dependency org=commons-collections name=commons-collections rev=3.2.1
conf=compile;references
artifact name=commons-collections type=sources ext=jar
m:classifier=sources conf=references /
/dependency
{code}
In build.xml, I have:
{code:xml|title=build.xml}
target name=eclipse description=Updates eclipse classpath.
ivy:configure settingsId=ivy.eclipse override=true /
ivy:resolve settingsRef=ivy.eclipse conf=compile, references /
ivy:eclipse settingsRef=ivy.eclipse conf=compile, references /
/target
{code}
And running 'ant eclipse' will update my .classpath with the cache path to
the commons-collections jar, with its sources jar attached. The classpath
entry will be annotated with an ivygen=true. Next time I run 'ant eclipse',
this entry will be recognized and replaced with whatever updated paths.
This is only the first draft. I know there is IvyDE, but I feel that this
could be a good starting point for an alternative that is more Ant-oriented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-1017) add refresh parameter to post resolve tasks
add refresh parameter to post resolve tasks --- Key: IVY-1017 URL: https://issues.apache.org/jira/browse/IVY-1017 Project: Ivy Issue Type: Improvement Components: Ant Affects Versions: 2.0 Reporter: Xavier Hanin Assignee: Xavier Hanin The refresh parameter available on the resolve task is not available on post resolve tasks. Therefore if one wants to set refresh there is no other option than calling resolve explicitly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1011) Enhance download options
[
https://issues.apache.org/jira/browse/IVY-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667214#action_12667214
]
Xavier Hanin commented on IVY-1011:
---
a vertical progress bar sounds like a nice idea, I really like it!
Enhance download options
Key: IVY-1011
URL: https://issues.apache.org/jira/browse/IVY-1011
Project: Ivy
Issue Type: New Feature
Components: Core
Reporter: Jan Matèrne
Priority: Minor
Enhance the downloading of artefacts.
- parallel downloads
- resuming a download
- partial downloads
- using a downloadmanager (for getting the first three topics)
(Without knowing the internals) I think of something like
public interface Downloader {
/**
* @param source From where to download
* @param target where to store the artefact
* @param progressReporter something that reports the progress (the
[...]ok at the moment)
*/
download(URI source, File target, ?? progressReporter);
}
Implementations:
- SerialDownloader : the existing downloader
- ParallelDownloader : starts multiple downloads in parallel
- SunDownloader : uses Suns Downloadmanager [1] for doing the job
- ??Downloader : other (free available Java based) download manager
[1] http://www.sun.com/download/sdm/download.xml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1017) add refresh parameter to post resolve tasks
[ https://issues.apache.org/jira/browse/IVY-1017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-1017. --- Resolution: Fixed Fix Version/s: trunk I've implemented this on trunk. In the documentation I've put since 2.1 but I don't know if this will go in 2.1 only, or 2.0.1 too. Documentation will need an update if we decide to merge this to 2.0.x branch. add refresh parameter to post resolve tasks --- Key: IVY-1017 URL: https://issues.apache.org/jira/browse/IVY-1017 Project: Ivy Issue Type: Improvement Components: Ant Affects Versions: 2.0 Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: trunk The refresh parameter available on the resolve task is not available on post resolve tasks. Therefore if one wants to set refresh there is no other option than calling resolve explicitly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1016) Patch to add an ivy:eclipse ant task that generates Eclipse .classpath files
[
https://issues.apache.org/jira/browse/IVY-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667216#action_12667216
]
Xavier Hanin commented on IVY-1016:
---
Thanks for this contribution Jing! But does it really need to be integrated in
ivy core? Maybe this could be provided as a separate plugin?
Patch to add an ivy:eclipse ant task that generates Eclipse .classpath files
Key: IVY-1016
URL: https://issues.apache.org/jira/browse/IVY-1016
Project: Ivy
Issue Type: New Feature
Components: Ant
Affects Versions: trunk
Reporter: Jing Xue
Attachments: EclipseClasspath.java
I put together a post-resolve ivy:eclipse task that updates the Eclipse
.classpath file according to the result of ivy:resolve. It also will
discover any source jars if they are part of the resolve/download, and
automatically attach them to the corresponding entries.
For example, I have this entry in ivy.xml:
{code:xml|title=ivy.xml}
dependency org=commons-collections name=commons-collections rev=3.2.1
conf=compile;references
artifact name=commons-collections type=sources ext=jar
m:classifier=sources conf=references /
/dependency
{code}
In build.xml, I have:
{code:xml|title=build.xml}
target name=eclipse description=Updates eclipse classpath.
ivy:configure settingsId=ivy.eclipse override=true /
ivy:resolve settingsRef=ivy.eclipse conf=compile, references /
ivy:eclipse settingsRef=ivy.eclipse conf=compile, references /
/target
{code}
And running 'ant eclipse' will update my .classpath with the cache path to
the commons-collections jar, with its sources jar attached. The classpath
entry will be annotated with an ivygen=true. Next time I run 'ant eclipse',
this entry will be recognized and replaced with whatever updated paths.
This is only the first draft. I know there is IvyDE, but I feel that this
could be a good starting point for an alternative that is more Ant-oriented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-1011) Enhance download options
[
https://issues.apache.org/jira/browse/IVY-1011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666858#action_12666858
]
Xavier Hanin commented on IVY-1011:
---
One issue with parallel downloading is download progress reporting. When used
from Ant, we are very limited in reporting, output to console being done only
by whole lines. I guess this is not a showstopper if we don't get something
clean during parallel downloads, but we need to be careful with this IMO.
Enhance download options
Key: IVY-1011
URL: https://issues.apache.org/jira/browse/IVY-1011
Project: Ivy
Issue Type: New Feature
Components: Core
Reporter: Jan Matèrne
Priority: Minor
Enhance the downloading of artefacts.
- parallel downloads
- resuming a download
- partial downloads
- using a downloadmanager (for getting the first three topics)
(Without knowing the internals) I think of something like
public interface Downloader {
/**
* @param source From where to download
* @param target where to store the artefact
* @param progressReporter something that reports the progress (the
[...]ok at the moment)
*/
download(URI source, File target, ?? progressReporter);
}
Implementations:
- SerialDownloader : the existing downloader
- ParallelDownloader : starts multiple downloads in parallel
- SunDownloader : uses Suns Downloadmanager [1] for doing the job
- ??Downloader : other (free available Java based) download manager
[1] http://www.sun.com/download/sdm/download.xml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVYDE-157) [regression] when possible, do not resolve issues on startup, only refresh last resolve from cache
[regression] when possible, do not resolve issues on startup, only refresh last resolve from cache -- Key: IVYDE-157 URL: https://issues.apache.org/jira/browse/IVYDE-157 Project: IvyDE Issue Type: Improvement Components: classpath container Affects Versions: 2.0.0.beta1 Reporter: Xavier Hanin Assignee: Xavier Hanin In previous IvyDE version, on eclipse startup dependencies where not fully resolved, but the last resolve found in cache was used when available. This is not the case anymore, which causes very slow startup of eclipse on projects using Ivy extensively with a slow connection to repositories -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVYDE-157) [regression] when possible, do not resolve issues on startup, only refresh last resolve from cache
[ https://issues.apache.org/jira/browse/IVYDE-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVYDE-157. Resolution: Invalid I missed the implementation of IVYDE-74 which makes this issue invalid. [regression] when possible, do not resolve issues on startup, only refresh last resolve from cache -- Key: IVYDE-157 URL: https://issues.apache.org/jira/browse/IVYDE-157 Project: IvyDE Issue Type: Improvement Components: classpath container Affects Versions: 2.0.0.beta1 Reporter: Xavier Hanin Assignee: Xavier Hanin In previous IvyDE version, on eclipse startup dependencies where not fully resolved, but the last resolve found in cache was used when available. This is not the case anymore, which causes very slow startup of eclipse on projects using Ivy extensively with a slow connection to repositories -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-1012) TTL does not work as expected
TTL does not work as expected - Key: IVY-1012 URL: https://issues.apache.org/jira/browse/IVY-1012 Project: Ivy Issue Type: Bug Affects Versions: 2.0 Reporter: Xavier Hanin Assignee: Xavier Hanin It seems that the TTL feature does not work as expected. I'm not even sure it works at all, it definetly needs some investigation. It could also be a good opportunity to deal with IVY-879. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1012) TTL does not work as expected
[ https://issues.apache.org/jira/browse/IVY-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-1012. --- Resolution: Fixed Fix Version/s: trunk I've done some investigation and figured out that TTL where only working with modules without module descriptor :-( This is fixed now on trunk, TTL work with modules with module descriptors, and also when a dynamic revision is resolved to the same revision after a TTL expiration. I'll make something for IVY-879 in a moment too. This should probably be merged to 2.0.x branch, but I had to change the RepositoryManager interface to make this work and one BasicResolver protected method, so it wold mean breaking API. TTL does not work as expected - Key: IVY-1012 URL: https://issues.apache.org/jira/browse/IVY-1012 Project: Ivy Issue Type: Bug Affects Versions: 2.0 Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: trunk It seems that the TTL feature does not work as expected. I'm not even sure it works at all, it definetly needs some investigation. It could also be a good opportunity to deal with IVY-879. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-879) Using ivy in offline mode
[
https://issues.apache.org/jira/browse/IVY-879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin reassigned IVY-879:
Assignee: Xavier Hanin
Using ivy in offline mode
-
Key: IVY-879
URL: https://issues.apache.org/jira/browse/IVY-879
Project: Ivy
Issue Type: Improvement
Components: Core
Reporter: Jean-Louis Boudart
Assignee: Xavier Hanin
I recently tried to use ivy in offline, everything is in ivy-cache, but ivy
seems to check dynamique revision all the time.
Exemple: Suppose you have this dependency on your project
dependency org=jasperreports name=jasperreports rev=2.0.5
conf=runtime-runtime/
Looking in the POM file
(http://repo1.maven.org/maven2/jasperreports/jasperreports/2.0.5/jasperreports-2.0.5.pom)
we can see that jasperreports depends on commons-logging#[1.0,)
This revision is evaluated on every resolve/retrieve.
I've tried to tune my cache with a large TTL, but the problem is still here.
My cache configuration :
caches default=mycache checkUpToDate=false
cache name=mycache basedir=${ivy.home.dir}/ivy-cache
defaultTTL=1d
ttl revision=latest.integration duration=1d /
/cache
/caches
Maybe there is a regression on my version?
Even if the TTL options seems to be interessant, i'm not so sure that this is
the best solution for working in offline mode.
It could be a nice improvement to reuse the cache even if TTL is expired when
repo are not reachable.
What do you think about it?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-879) Using ivy in offline mode
[
https://issues.apache.org/jira/browse/IVY-879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12666896#action_12666896
]
Xavier Hanin commented on IVY-879:
--
I've fixed the problem with TTL in IVY-1012, and also changed some tiny things
to make it more usable for offline mode: I've added the option to use 'eternal'
as ttl duration, and also changed when ttl is checked. So now if you don't have
any specific ttl in your Ivy settings, all you have to do when offline is to
set the property ivy.cache.ttl.default to eternal (with
-Divy.cache.ttl.default=eternal when calling ant for instance). If you set ttls
yourself, it's a bit more work to override the values in offline mode, but it's
still possible.
So IMO the current trunk version is enough for offline support. WDYT?
Using ivy in offline mode
-
Key: IVY-879
URL: https://issues.apache.org/jira/browse/IVY-879
Project: Ivy
Issue Type: Improvement
Components: Core
Reporter: Jean-Louis Boudart
Assignee: Xavier Hanin
I recently tried to use ivy in offline, everything is in ivy-cache, but ivy
seems to check dynamique revision all the time.
Exemple: Suppose you have this dependency on your project
dependency org=jasperreports name=jasperreports rev=2.0.5
conf=runtime-runtime/
Looking in the POM file
(http://repo1.maven.org/maven2/jasperreports/jasperreports/2.0.5/jasperreports-2.0.5.pom)
we can see that jasperreports depends on commons-logging#[1.0,)
This revision is evaluated on every resolve/retrieve.
I've tried to tune my cache with a large TTL, but the problem is still here.
My cache configuration :
caches default=mycache checkUpToDate=false
cache name=mycache basedir=${ivy.home.dir}/ivy-cache
defaultTTL=1d
ttl revision=latest.integration duration=1d /
/cache
/caches
Maybe there is a regression on my version?
Even if the TTL options seems to be interessant, i'm not so sure that this is
the best solution for working in offline mode.
It could be a nice improvement to reuse the cache even if TTL is expired when
repo are not reachable.
What do you think about it?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-1013) support resolve refresh in command line
support resolve refresh in command line --- Key: IVY-1013 URL: https://issues.apache.org/jira/browse/IVY-1013 Project: Ivy Issue Type: Improvement Reporter: Xavier Hanin Assignee: Xavier Hanin There's currently no option to run a resolve in refresh mode when used from command line -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1013) support resolve refresh in command line
[ https://issues.apache.org/jira/browse/IVY-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-1013. --- Resolution: Fixed Fix Version/s: trunk I've implemented this with -refresh argument support resolve refresh in command line --- Key: IVY-1013 URL: https://issues.apache.org/jira/browse/IVY-1013 Project: Ivy Issue Type: Improvement Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: trunk There's currently no option to run a resolve in refresh mode when used from command line -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-1014) add -version option on command line
add -version option on command line --- Key: IVY-1014 URL: https://issues.apache.org/jira/browse/IVY-1014 Project: Ivy Issue Type: Improvement Reporter: Xavier Hanin Assignee: Xavier Hanin Ivy always display its version information when performing almost anything, but there is no way to easily get only the version information on command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-996) Remove excessive HEAD requests for URL repository
[ https://issues.apache.org/jira/browse/IVY-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin reassigned IVY-996: Assignee: Xavier Hanin Remove excessive HEAD requests for URL repository - Key: IVY-996 URL: https://issues.apache.org/jira/browse/IVY-996 Project: Ivy Issue Type: Improvement Components: Core Affects Versions: 2.0-RC2 Reporter: Eric Anderson Assignee: Xavier Hanin h3. Fixing useless extra HEAD requests When searching for an artifact named project version 2.2.+ for organization org, Ivy attempts HEAD requests for completely not possible versions. IE: /org/project/0.9.2/ivy-0.9.2.xml This is not terribly painful unless you have thousands of builds and are not on the same network as your ivy server. h3. Are HEAD requests even necessary? Simply getting a directory listing should be good enough to determine if there is an artifact (for choosing latest-release). Now, after one is chosen, if no ivy.xml file exists, I could understand trying the next one, but trying all of them, just to select the latest one anyways seems like a complete waste. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-1014) add -version option on command line
[ https://issues.apache.org/jira/browse/IVY-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-1014. --- Resolution: Fixed Fix Version/s: trunk I've implemented this on trunk. add -version option on command line --- Key: IVY-1014 URL: https://issues.apache.org/jira/browse/IVY-1014 Project: Ivy Issue Type: Improvement Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: trunk Ivy always display its version information when performing almost anything, but there is no way to easily get only the version information on command line. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-996) Remove excessive HEAD requests for URL repository
[ https://issues.apache.org/jira/browse/IVY-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-996. -- Resolution: Fixed Fix Version/s: trunk I've made some modifications on trunk which should fix this as you asked: making head requests only for potential matches. I've made some testing in my environment, and it works well. I'd appreciate feedback though to know if it works for you too. Remove excessive HEAD requests for URL repository - Key: IVY-996 URL: https://issues.apache.org/jira/browse/IVY-996 Project: Ivy Issue Type: Improvement Components: Core Affects Versions: 2.0-RC2 Reporter: Eric Anderson Assignee: Xavier Hanin Fix For: trunk h3. Fixing useless extra HEAD requests When searching for an artifact named project version 2.2.+ for organization org, Ivy attempts HEAD requests for completely not possible versions. IE: /org/project/0.9.2/ivy-0.9.2.xml This is not terribly painful unless you have thousands of builds and are not on the same network as your ivy server. h3. Are HEAD requests even necessary? Simply getting a directory listing should be good enough to determine if there is an artifact (for choosing latest-release). Now, after one is chosen, if no ivy.xml file exists, I could understand trying the next one, but trying all of them, just to select the latest one anyways seems like a complete waste. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVYDE-146) source and javadoc attachment regression
source and javadoc attachment regression Key: IVYDE-146 URL: https://issues.apache.org/jira/browse/IVYDE-146 Project: IvyDE Issue Type: Bug Components: classpath container Affects Versions: 2.0.0.beta1 Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: 2.0.0.final In 2.0.0.beta1 version, the source and javadoc attachment does not work as well as before: only artifacts got when resolving dependencies are used to find source and javadoc attachments, while before IvyDE was looking for other artifacts declared by the module or even undeclared. Looking for undeclared artifacts shouldn't be necessary anymore since now Ivy detects source and javadoc artifacts on maven modules at parsing time, but requiring to actually resolve source and javadoc artifacts as part of the resolve process is cumbersome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVYDE-146) source and javadoc attachment regression
[ https://issues.apache.org/jira/browse/IVYDE-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVYDE-146. Resolution: Fixed I've fixed this issue, looking for source and javadoc artifacts in module descriptor again. In the mean time I've slightly changed the way project dependencies are discovered, according to my test it still works as before. source and javadoc attachment regression Key: IVYDE-146 URL: https://issues.apache.org/jira/browse/IVYDE-146 Project: IvyDE Issue Type: Bug Components: classpath container Affects Versions: 2.0.0.beta1 Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: 2.0.0.final In 2.0.0.beta1 version, the source and javadoc attachment does not work as well as before: only artifacts got when resolving dependencies are used to find source and javadoc attachments, while before IvyDE was looking for other artifacts declared by the module or even undeclared. Looking for undeclared artifacts shouldn't be necessary anymore since now Ivy detects source and javadoc artifacts on maven modules at parsing time, but requiring to actually resolve source and javadoc artifacts as part of the resolve process is cumbersome. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVYDE-144) NPE when a project:/// path is used and path does not exist
NPE when a project:/// path is used and path does not exist
---
Key: IVYDE-144
URL: https://issues.apache.org/jira/browse/IVYDE-144
Project: IvyDE
Issue Type: Bug
Components: classpath container
Affects Versions: 2.0.0.beta1
Reporter: Xavier Hanin
If IvyDE is misconfigured with a project:/// path for the settings which does
not correspond to an existing file, an NPE is thrown:
{noformat}
java.lang.NullPointerException
at
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration.getIvy(IvyClasspathContainerConfiguration.java:442)
at
org.apache.ivyde.eclipse.cpcontainer.IvyResolveJob.run(IvyResolveJob.java:195)
at
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer.launchResolve(IvyClasspathContainer.java:162)
at
org.apache.ivyde.eclipse.ui.actions.ResolveAllAction$1.run(ResolveAllAction.java:81)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVYDE-144) NPE when a project:/// path is used and path does not exist
[
https://issues.apache.org/jira/browse/IVYDE-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVYDE-144.
Resolution: Fixed
Fix Version/s: 2.0.0.final
Assignee: Xavier Hanin
I've fixed this problem, and also made a slight change to the way conf status
is updated, so that the more recent exception is shown instead of the oldest
one.
NPE when a project:/// path is used and path does not exist
---
Key: IVYDE-144
URL: https://issues.apache.org/jira/browse/IVYDE-144
Project: IvyDE
Issue Type: Bug
Components: classpath container
Affects Versions: 2.0.0.beta1
Reporter: Xavier Hanin
Assignee: Xavier Hanin
Fix For: 2.0.0.final
If IvyDE is misconfigured with a project:/// path for the settings which does
not correspond to an existing file, an NPE is thrown:
{noformat}
java.lang.NullPointerException
at
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainerConfiguration.getIvy(IvyClasspathContainerConfiguration.java:442)
at
org.apache.ivyde.eclipse.cpcontainer.IvyResolveJob.run(IvyResolveJob.java:195)
at
org.apache.ivyde.eclipse.cpcontainer.IvyClasspathContainer.launchResolve(IvyClasspathContainer.java:162)
at
org.apache.ivyde.eclipse.ui.actions.ResolveAllAction$1.run(ResolveAllAction.java:81)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVYDE-145) project://[projectname]/ scheme for settings only work with java projects, not simple projects
project://[projectname]/ scheme for settings only work with java projects, not simple projects -- Key: IVYDE-145 URL: https://issues.apache.org/jira/browse/IVYDE-145 Project: IvyDE Issue Type: Bug Components: classpath container Affects Versions: 2.0.0.beta1 Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: 2.0.0.final if the settings are in a simple eclipse project, not a java project, IvyDE complains that the project does not exist and thus is not able to load the settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVYDE-145) project://[projectname]/ scheme for settings only work with java projects, not simple projects
[ https://issues.apache.org/jira/browse/IVYDE-145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVYDE-145. Resolution: Fixed The project:// now works with any kind of project project://[projectname]/ scheme for settings only work with java projects, not simple projects -- Key: IVYDE-145 URL: https://issues.apache.org/jira/browse/IVYDE-145 Project: IvyDE Issue Type: Bug Components: classpath container Affects Versions: 2.0.0.beta1 Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: 2.0.0.final if the settings are in a simple eclipse project, not a java project, IvyDE complains that the project does not exist and thus is not able to load the settings. -- 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-tabpanelfocusedCommentId=12644090#action_12644090
]
Xavier Hanin commented on IVY-742:
--
That sounds like a much more flexible and interesting way to provide parent
import mechanism! While thinking about it, I'm wondering if using the parent
concept isn't limiting itself. Why wouldn't we call this import as the import
in Ant (or extends as we call it in EasyAnt)? Then we could imagine importing
multiple ivy files, controlling for each one what is really imported. More
flexible, and not really harder to implement and document if we fix what
happens when the same dependency is defined multiple times in imported modules
with different versions / conf mapping. I guess we could say that the last (or
first?) definition takes precedence.
WDYT?
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
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
ivy-module version=2.0
info organisation=${organization.name} module=$
{interface.jar.prefix}/
configurations
conf name=interface description=dependencies for
interface/
include file=path/to/included-configurations.xml/
/configurations
publications
artifact name=${interface.jar.prefix} type=jar
conf=interface ext=jar/
/publications
dependencies
dependency org=twc name=mas-core rev=${mas.version}
conf=interface-server/
/dependencies
/ivy-module
and I want them all to share an inherited configuration found in a
file: included-configurations.xml
configuration
conf name=test/
/configuration
dependencies
dependency name=testng rev=5.7 conf=test/
/dependencies
so in the inherited configurations file I'd also like to include a
dependency that goes along with that configuration.
Is something like this possible?
No, this is not possible in Ivy, but you can use text or xml processing
tools to recompose your Ivy file before asking Ivy to resolve the
dependencies of your module.
Alternatively, since what you ask is close to maven 2 parent mechanism, I
think it could be a nice addition to Ivy feature set. So feel free to open
an issue, and even provide a patch :-)
Xavier
Thanks,
Neil
--
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-931) Ivy badly attempt to locate a 'working@host' dependency revision when the dependency revision is not set in a pom
[ https://issues.apache.org/jira/browse/IVY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12637125#action_12637125 ] Xavier Hanin commented on IVY-931: -- I'm pretty sure it fails, but a try with the latest version would be nice. Ivy badly attempt to locate a 'working@host' dependency revision when the dependency revision is not set in a pom --- Key: IVY-931 URL: https://issues.apache.org/jira/browse/IVY-931 Project: Ivy Issue Type: Bug Affects Versions: 2.0-RC1 Reporter: Xavier Hanin If in a pom a dependency is declared without revision, Ivy interprets it as a 'working@host' revision, which is very confusing. This may happen for instance when Ivy cannot locate a parent pom which contains a dependencyManagement section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-933) Maven2 parser checks version in the POM with the expected version
[ https://issues.apache.org/jira/browse/IVY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636540#action_12636540 ] Xavier Hanin commented on IVY-933: -- Actually this behaviour is supported in Ivy, but it isn't the default : you just need to set checkconsistency=false on the resolver. Maybe we should make checkconsistency false by default on ibiblio resolver? Maven2 parser checks version in the POM with the expected version - Key: IVY-933 URL: https://issues.apache.org/jira/browse/IVY-933 Project: Ivy Issue Type: Bug Components: Maven Compatibility Affects Versions: 2.0-RC1 Reporter: Maarten Coene When Ivy downloads a POM, it checks if the version inside the POM is the same as the expected version. Maven2 doesn't check this. For instance: http://repo1.maven.org/maven2/jdo/jdo/2.0-beta/jdo-2.0-beta.pom Ivy will fail resolving this dependency, maven2 doesn't fail. Even more: maven2 will download the 2.0-beta jar, but inside the POM the version is 1.0.1, so it seems that maven2 uses the version from the URL instead of the version from the POM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-933) Maven2 parser checks version in the POM with the expected version
[ https://issues.apache.org/jira/browse/IVY-933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636598#action_12636598 ] Xavier Hanin commented on IVY-933: -- I think Ivy trust the dependency declaration, and not the pom information, so it behaves the same way as maven. And I think inconsistent groupId, artifactId and revision are supported. I may be wrong though, it's only from the top of my head. Maven2 parser checks version in the POM with the expected version - Key: IVY-933 URL: https://issues.apache.org/jira/browse/IVY-933 Project: Ivy Issue Type: Bug Components: Maven Compatibility Affects Versions: 2.0-RC1 Reporter: Maarten Coene When Ivy downloads a POM, it checks if the version inside the POM is the same as the expected version. Maven2 doesn't check this. For instance: http://repo1.maven.org/maven2/jdo/jdo/2.0-beta/jdo-2.0-beta.pom Ivy will fail resolving this dependency, maven2 doesn't fail. Even more: maven2 will download the 2.0-beta jar, but inside the POM the version is 1.0.1, so it seems that maven2 uses the version from the URL instead of the version from the POM. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-931) Ivy badly attempt to locate a 'working@host' dependency revision when the dependency revision is not set in a pom
[ https://issues.apache.org/jira/browse/IVY-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636595#action_12636595 ] Xavier Hanin commented on IVY-931: -- Indeed, maybe it's the best option, but if we want to go this way we have to release it before 2.0 because it will break backward compatibility. The other option is to break only if a dependency has no revision, and only warn when we can't locate the parent. I don't have a strong opinion on this, what do others think? Ivy badly attempt to locate a 'working@host' dependency revision when the dependency revision is not set in a pom --- Key: IVY-931 URL: https://issues.apache.org/jira/browse/IVY-931 Project: Ivy Issue Type: Bug Affects Versions: 2.0-RC1 Reporter: Xavier Hanin If in a pom a dependency is declared without revision, Ivy interprets it as a 'working@host' revision, which is very confusing. This may happen for instance when Ivy cannot locate a parent pom which contains a dependencyManagement section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-931) Ivy badly attempt to locate a 'working@host' dependency revision when the dependency revision is not set in a pom
Ivy badly attempt to locate a 'working@host' dependency revision when the dependency revision is not set in a pom --- Key: IVY-931 URL: https://issues.apache.org/jira/browse/IVY-931 Project: Ivy Issue Type: Bug Affects Versions: 2.0-RC1 Reporter: Xavier Hanin If in a pom a dependency is declared without revision, Ivy interprets it as a 'working@host' revision, which is very confusing. This may happen for instance when Ivy cannot locate a parent pom which contains a dependencyManagement section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-927) NullPointerException when Ivy cannot locate pom parent
NullPointerException when Ivy cannot locate pom parent
--
Key: IVY-927
URL: https://issues.apache.org/jira/browse/IVY-927
Project: Ivy
Issue Type: Bug
Components: Maven Compatibility
Affects Versions: 2.0-RC1
Reporter: Xavier Hanin
Assignee: Xavier Hanin
When Ivy cannot locate a pom parent, it results in a NullPointerException:
{noformat}
java.lang.NullPointerException at
org.apache.ivy.plugins.parser.m2.PomModuleDescriptorParser.parseDescriptor(PomModuleDescriptorParser.java:134)
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-928) NullPointerException in AbstractPatternsBasedResolver when organization is null
[
https://issues.apache.org/jira/browse/IVY-928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-928.
--
Resolution: Fixed
Fix Version/s: trunk
Assignee: Xavier Hanin
Fixed on trunk, still have to merge on 2.0.x branch
NullPointerException in AbstractPatternsBasedResolver when organization is
null
---
Key: IVY-928
URL: https://issues.apache.org/jira/browse/IVY-928
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0-RC1
Reporter: Xavier Hanin
Assignee: Xavier Hanin
Fix For: trunk
When a mrid organization is null (it can happen when there is no groupId in
m2 pom for instance), AbstractPatternsBasedResolver run into a
NullPointException:
{noformat}
java.lang.NullPointerException at
org.apache.ivy.plugins.resolver.AbstractPatternsBasedResolver.convertM2IdForResourceSearch(AbstractPatternsBasedResolver.java:441)
{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-906) Ability to grab non standardly placed artifacts from a local filesystem resolver without downloading to cache.
[ https://issues.apache.org/jira/browse/IVY-906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin updated IVY-906: - Fix Version/s: (was: unspecified) Ability to grab non standardly placed artifacts from a local filesystem resolver without downloading to cache. -- Key: IVY-906 URL: https://issues.apache.org/jira/browse/IVY-906 Project: Ivy Issue Type: Improvement Components: Core Affects Versions: 2.0.0-beta-2 Reporter: Alexander Foreman Ok, I see, this is not supported yet, so please file an improvement in JIRA. Xavier Thanks for the help. Alex Foreman Morgan Stanley | Technology 20 Cabot Square | Canary Wharf | Floor 06 London, E14 4QW Phone: +44 20 7677-5732 [EMAIL PROTECTED] -Original Message- From: Xavier Hanin [mailto:[EMAIL PROTECTED] Sent: 16 September 2008 17:36 To: [EMAIL PROTECTED] Subject: Re: URL= Behaviour On Tue, Sep 16, 2008 at 6:06 PM, Foreman, Alex (IT) [EMAIL PROTECTED] wrote: I have a feature request I asked about before but may have ben lost. If you have a url and its not in its place in its repository then Ivy will download it and ignore local='true' as it did not find it in the reolver correctly but elsewhere. This obiously can be anywhere as it's a URL and we want to consider it remote. Is there or can there be a way to force the resover to always be local. Eg even if it's a url use that location when using a cache path rarther than the local cache position. Maybe cache useOrigin=always / in ivy-settings. I have been considering doing this via a trigger but might be nice if Ivy supported it directly. The problem is that after resolve, Ivy requires all your artifacts to be accessible as java.io.File objects, so a URL is not possible, unless it's a file URL. Could you detail your use case? Xavier Many thanks, Alex Foreman Morgan Stanley | Technology 20 Cabot Square | Canary Wharf | Floor 06 London, E14 4QW Phone: +44 20 7677-5732 [EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-907) Environment properties in ivy settings are no longer resolved
[
https://issues.apache.org/jira/browse/IVY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632544#action_12632544
]
Xavier Hanin commented on IVY-907:
--
Maarten: do you mean JIRA lost sg from you? I only added a comment. BTW, I
think your fix is not enough. Well, it should work as long as you use Ivy from
Ant. But if you use Ivy standalone, you can still have the same problem. Maybe
we could do the variable substitution when we set a variable? WDYT?
Environment properties in ivy settings are no longer resolved
-
Key: IVY-907
URL: https://issues.apache.org/jira/browse/IVY-907
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0-RC1
Reporter: Erik-Berndt Scheper
Assignee: Maarten Coene
Fix For: 2.0.x
Attachments: IVY-907.zip, ivysettings.zip
I have an ivy.settings.xml file published on an intranet http server, which
includes a property file from the same http server. (see attached files).
This property file includes the property:
{code}ivy.cache.dir = ${env.IVY_CACHE_DIR}{code}
This environment based property is no longer resolved when I use the proposed
ivy-2.0.0-rc1.jar. This leads to the following error during resolve:
{noformat}
ivy.check:
ivy.init:
[mkdir] Created dir:
D:\ws\eclipse-3.4\AAD\AAD-domain-model\target\reports\ivy
ivy.resolve:
[ivy:resolve] :: Ivy 2.0.0-rc1 - 20080916082609 :: http://ant.apache.org/ivy/
::
:: loading settings :: url =
http://172.30.247.68/ivy-settings/ivy.settings.xml
BUILD FAILED
D:\ws\eclipse-3.4\AAD\build\build-ivy\build.ivy.xml:75:
java.lang.IllegalArgumentException: ivy.cache.dir must be absolute:
${env.IVY_CACHE_DIR}
Total time: 2 seconds
{noformat}
The same ivy settings files worked perfectly well with a previous ivy which I
built from trunk: org.apache.ivy_2.0.0.rc1_20080813101604.jar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-907) Environment properties in ivy settings are no longer resolved
[
https://issues.apache.org/jira/browse/IVY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632571#action_12632571
]
Xavier Hanin commented on IVY-907:
--
bq. Don't we already do a variable subsitution when we set a variable?
You're absolutely right! So the problem was *only* when used from Ant, and your
fix should be enough. Good job, sorry for the noise.
Environment properties in ivy settings are no longer resolved
-
Key: IVY-907
URL: https://issues.apache.org/jira/browse/IVY-907
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0-RC1
Reporter: Erik-Berndt Scheper
Assignee: Maarten Coene
Fix For: 2.0.x
Attachments: IVY-907.zip, ivysettings.zip
I have an ivy.settings.xml file published on an intranet http server, which
includes a property file from the same http server. (see attached files).
This property file includes the property:
{code}ivy.cache.dir = ${env.IVY_CACHE_DIR}{code}
This environment based property is no longer resolved when I use the proposed
ivy-2.0.0-rc1.jar. This leads to the following error during resolve:
{noformat}
ivy.check:
ivy.init:
[mkdir] Created dir:
D:\ws\eclipse-3.4\AAD\AAD-domain-model\target\reports\ivy
ivy.resolve:
[ivy:resolve] :: Ivy 2.0.0-rc1 - 20080916082609 :: http://ant.apache.org/ivy/
::
:: loading settings :: url =
http://172.30.247.68/ivy-settings/ivy.settings.xml
BUILD FAILED
D:\ws\eclipse-3.4\AAD\build\build-ivy\build.ivy.xml:75:
java.lang.IllegalArgumentException: ivy.cache.dir must be absolute:
${env.IVY_CACHE_DIR}
Total time: 2 seconds
{noformat}
The same ivy settings files worked perfectly well with a previous ivy which I
built from trunk: org.apache.ivy_2.0.0.rc1_20080813101604.jar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-907) Environment properties in ivy settings are no longer resolved
[
https://issues.apache.org/jira/browse/IVY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632573#action_12632573
]
Xavier Hanin commented on IVY-907:
--
Erik: if this doesn't go in rc1, it will go in 2.0 final only if another
blocking issue is found in rc1. Otherwise we will promote rc1 as 2.0 final. Bug
hunting is open!
That being said, it doesn't preclude releasing a 2.0.1 pretty quickly after
2.0.0, with this fix and others. But if we delay 2.0.0 with non blocking issues
it may last for too long.
Environment properties in ivy settings are no longer resolved
-
Key: IVY-907
URL: https://issues.apache.org/jira/browse/IVY-907
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0-RC1
Reporter: Erik-Berndt Scheper
Assignee: Maarten Coene
Fix For: 2.0.x
Attachments: IVY-907.zip, ivysettings.zip
I have an ivy.settings.xml file published on an intranet http server, which
includes a property file from the same http server. (see attached files).
This property file includes the property:
{code}ivy.cache.dir = ${env.IVY_CACHE_DIR}{code}
This environment based property is no longer resolved when I use the proposed
ivy-2.0.0-rc1.jar. This leads to the following error during resolve:
{noformat}
ivy.check:
ivy.init:
[mkdir] Created dir:
D:\ws\eclipse-3.4\AAD\AAD-domain-model\target\reports\ivy
ivy.resolve:
[ivy:resolve] :: Ivy 2.0.0-rc1 - 20080916082609 :: http://ant.apache.org/ivy/
::
:: loading settings :: url =
http://172.30.247.68/ivy-settings/ivy.settings.xml
BUILD FAILED
D:\ws\eclipse-3.4\AAD\build\build-ivy\build.ivy.xml:75:
java.lang.IllegalArgumentException: ivy.cache.dir must be absolute:
${env.IVY_CACHE_DIR}
Total time: 2 seconds
{noformat}
The same ivy settings files worked perfectly well with a previous ivy which I
built from trunk: org.apache.ivy_2.0.0.rc1_20080813101604.jar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-907) Environment properties in ivy settings are no longer resolved
[
https://issues.apache.org/jira/browse/IVY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12632394#action_12632394
]
Xavier Hanin commented on IVY-907:
--
Ok, I think I've found the problem: the default cache location is initialized
by default using the value of the ivy.cache.dir variable. The problem is that
during this initialization, variable substitution is not done. In your case you
set this variable to ${env.IVY_CACHE_DIR}, which is not expanded by Ivy and
thus lead to a non absolute path.
With the old version it works because you actually never use the default cache
location, since you explicitly set the repository cache dir and the resolution
cache dir. But if you run with the old version in verbose mode, you will see in
the dumped settings that ${env.IVY_CACHE_DIR} is not expanded either.
So the fix is too expand variables values when using the ivy.cache.dir variable
to set the default cache dir value.
The workaround is to use another variable as basis for your cache, since you
don't actually want to set the default cache with that. Or you can also
explicitly set the defaultCacheDir=${ivy.cache.dir} in your caches settings,
since this one will expand the variables values.
To conclude, since there is a workaround, and the bug case is not too frequent
(you need to set ivy.cache.dir to a value with a variable) I don't think this
is a blocking issue for 2.0-rc1 or 2.0-final either.
Environment properties in ivy settings are no longer resolved
-
Key: IVY-907
URL: https://issues.apache.org/jira/browse/IVY-907
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0-RC1
Reporter: Erik-Berndt Scheper
Assignee: Maarten Coene
Fix For: 2.0.x
Attachments: IVY-907.zip, ivysettings.zip
I have an ivy.settings.xml file published on an intranet http server, which
includes a property file from the same http server. (see attached files).
This property file includes the property:
{code}ivy.cache.dir = ${env.IVY_CACHE_DIR}{code}
This environment based property is no longer resolved when I use the proposed
ivy-2.0.0-rc1.jar. This leads to the following error during resolve:
{noformat}
ivy.check:
ivy.init:
[mkdir] Created dir:
D:\ws\eclipse-3.4\AAD\AAD-domain-model\target\reports\ivy
ivy.resolve:
[ivy:resolve] :: Ivy 2.0.0-rc1 - 20080916082609 :: http://ant.apache.org/ivy/
::
:: loading settings :: url =
http://172.30.247.68/ivy-settings/ivy.settings.xml
BUILD FAILED
D:\ws\eclipse-3.4\AAD\build\build-ivy\build.ivy.xml:75:
java.lang.IllegalArgumentException: ivy.cache.dir must be absolute:
${env.IVY_CACHE_DIR}
Total time: 2 seconds
{noformat}
The same ivy settings files worked perfectly well with a previous ivy which I
built from trunk: org.apache.ivy_2.0.0.rc1_20080813101604.jar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-907) Environment properties in ivy settings are no longer resolved
[
https://issues.apache.org/jira/browse/IVY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12631837#action_12631837
]
Xavier Hanin commented on IVY-907:
--
Are you sure it worked with the previous version? I mean, did it really expand
the variable? Is the variable set? I've made a test on my windows box with the
first attempt for 2.0 rc1, and it works without any problem:
{code:title=ivysettings.xml}
ivysettings
properties environment=env /
properties file=${ivy.settings.dir}/ivysettings.properties /
settings defaultResolver=chain/
caches defaultCacheDir=${ivy.cache.dir} /
resolvers
chain name=chain returnFirst=true
filesystem name=local checkconsistency=false
ivy pattern=${ivy.settings.dir}/local/[module]/ivy.xml /
artifact pattern=${ivy.settings.dir}/local/[module]/[artifact].[ext]
/
/filesystem
filesystem name=shared
ivy pattern=${ivy.settings.dir}/shared/[module]/[revision]/ivy.xml /
artifact
pattern=${ivy.settings.dir}/shared/[module]/[revision]/[artifact].[ext] /
/filesystem
/chain
/resolvers
/ivysettings
{code}
{code:title=ivysettings.properties}
ivy.cache.dir = ${env.IVY_CACHE_DIR}
{code}
{code:title=console}
E:\temp\ivy\test-simpleecho %IVY_CACHE_DIR%
e:\temp\ivy\test-simple\ivy-cache
E:\temp\ivy\test-simpleant
Buildfile: build.xml
resolve:
[delete] Deleting directory E:\temp\ivy\test-simple\ivy-retrieve
[delete] Deleting directory E:\temp\ivy\test-simple\ivy-cache
No ivy:settings found for the default reference 'ivy.instance'. A default
instance will be used
[ivy:retrieve] :: Ivy 2.0.0-rc1 - 20080916082609 :: http://ant.apache.org/ivy/
::
:: loading settings :: file = E:\temp\ivy\test-simple\ivysettings.xml
[ivy:retrieve] :: resolving dependencies :: test#test-local;[EMAIL PROTECTED]
[ivy:retrieve] confs: [default]
[ivy:retrieve] found test#B;1.0 in shared
[ivy:retrieve] found test#C;1.0 in shared
[ivy:retrieve] downloading E:\temp\ivy\test-simple\shared\B\1.0\B.txt ...
[ivy:retrieve] .. (0kB)
[ivy:retrieve] [SUCCESSFUL ] test#B;1.0!B.txt (0ms)
[ivy:retrieve] downloading E:\temp\ivy\test-simple\shared\C\1.0\C.txt ...
[ivy:retrieve] .. (0kB)
[ivy:retrieve] [SUCCESSFUL ] test#C;1.0!C.txt (0ms)
[ivy:retrieve] :: resolution report :: resolve 156ms :: artifacts dl 16ms
-
| |modules|| artifacts |
| conf | number| search|dwnlded|evicted|| number|dwnlded|
-
| default | 2 | 2 | 2 | 0 || 2 | 2 |
-
[ivy:retrieve] :: retrieving :: test#test-local
[ivy:retrieve] confs: [default]
[ivy:retrieve] 2 artifacts copied, 0 already retrieved (0kB/16ms)
BUILD SUCCESSFUL
Total time: 0 seconds
{code}
Environment properties in ivy settings are no longer resolved
-
Key: IVY-907
URL: https://issues.apache.org/jira/browse/IVY-907
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0-RC1
Reporter: Erik-Berndt Scheper
Fix For: 2.0-RC1
Attachments: ivysettings.zip
I have an ivy.settings.xml file published on an intranet http server, which
includes a property file from the same http server. (see attached files).
This property file includes the property:
{code}ivy.cache.dir = ${env.IVY_CACHE_DIR}{code}
This environment based property is no longer resolved when I use the proposed
ivy-2.0.0-rc1.jar. This leads to the following error during resolve:
{noformat}
ivy.check:
ivy.init:
[mkdir] Created dir:
D:\ws\eclipse-3.4\AAD\AAD-domain-model\target\reports\ivy
ivy.resolve:
[ivy:resolve] :: Ivy 2.0.0-rc1 - 20080916082609 :: http://ant.apache.org/ivy/
::
:: loading settings :: url =
http://172.30.247.68/ivy-settings/ivy.settings.xml
BUILD FAILED
D:\ws\eclipse-3.4\AAD\build\build-ivy\build.ivy.xml:75:
java.lang.IllegalArgumentException: ivy.cache.dir must be absolute:
${env.IVY_CACHE_DIR}
Total time: 2 seconds
{noformat}
The same ivy settings files worked perfectly well with a previous ivy which I
built from trunk: org.apache.ivy_2.0.0.rc1_20080813101604.jar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-904) support ant properties propagation to ant build with ant-build trigger
[
https://issues.apache.org/jira/browse/IVY-904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin updated IVY-904:
-
Fix Version/s: (was: 2.0-RC1)
support ant properties propagation to ant build with ant-build trigger
--
Key: IVY-904
URL: https://issues.apache.org/jira/browse/IVY-904
Project: Ivy
Issue Type: Improvement
Components: Ant
Affects Versions: 2.0-RC1
Reporter: Steve Benigan
An ant-build trigger calls a target in an ant build file but does not
propogate properties to the ant build.
ant-call does propogate them - well I'm not sure it's doing anything special
but b/c it's calling a target within the current ant build they are
propogated by the nature of ant.
If possible, some ivy properties should be propogated such as the
ivy.cache.dir.${settingsRef} properties as well as all of the other
properties set in the current build due to settings, resolve, etc.
Otherwise, the ant-build trigger is limited in what it can do based on the
context in which it was called.
The workaround is to use ant-call and then within the called target use ant
task to call the desired target in an external ant file. This is not ideal
since it means this target needs to be in every build file or at least in an
imported build file.
PS This may be a Change Request rather than an actual bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-891) Change 'alwaysUseExactRevision' default value to false
[ https://issues.apache.org/jira/browse/IVY-891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-891. -- Resolution: Fixed I've already implemented this, just forgot to mark it as resolved Change 'alwaysUseExactRevision' default value to false -- Key: IVY-891 URL: https://issues.apache.org/jira/browse/IVY-891 Project: Ivy Issue Type: Improvement Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: 2.0-RC1 As discussed on the mailing list, the default value for alwaysUseExactRevision should be false rather than true -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-900) Parsing of m2 pom does not handle properties correctly.
[ https://issues.apache.org/jira/browse/IVY-900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12629728#action_12629728 ] Xavier Hanin commented on IVY-900: -- Thanks for your contribution Kevin, but could you be more precise when you say they aren't fixed? And what exactly your attached file fixes? Something like a junit test failing without the patch and passing with the patch would be helpful. Indeed properties are actually loaded in current code, including default properties (but not the exact same ones as you do, some are missing in your code, some may be missing in current code). The main difference I see is the time at which properties are loaded. In current code, loading and setting properties is done after pom coordinates are loaded, so I suspect some cases will fail, for instance when a project.groupId is used to define the artifactId. But we need to be careful also with inherited parent properties, and which one takes precendence. I guess the properties defined in the child should take precedence, but it does not seem to be the case in current Ivy code. In your code, changing getPomProperties() implementation has a side effect which may have bad consequence on this too. So I think properties loading needs to be reviewed, but your patch is not enough, we need to review how properties are loaded and set more globally. Parsing of m2 pom does not handle properties correctly. --- Key: IVY-900 URL: https://issues.apache.org/jira/browse/IVY-900 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0.0-beta-2 Reporter: Kevin Brockhoff Attachments: PomReader.java There are a bunch of issues (IVY-512, IVY-550, IVY-620, IVY-637) that are marked fixed that are not fixed. The attached file will actually fix these issues. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-896) Add GDF as a report output format
[ https://issues.apache.org/jira/browse/IVY-896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628846#action_12628846 ] Xavier Hanin commented on IVY-896: -- Hi Nascif, Thanks for sharing this with Ivy community! I like the power this tool gives to dependency analysis. I also like the original graph image, I may do a t-shirt with it :-) Add GDF as a report output format - Key: IVY-896 URL: https://issues.apache.org/jira/browse/IVY-896 Project: Ivy Issue Type: New Feature Components: Core Affects Versions: 2.0.0-beta-1 Reporter: Nascif Abousalh-Neto Priority: Minor Fix For: unspecified Attachments: gdf.xsl, j1.jpg, sp.jpg We have been dealing with some very large graphs here (thousands of nodes, tens of thousands of edges) and the information density is so high that the graph visualization tools supported by Ivy, GraphViz and yED, were not up to the task. Then we found out about GUESS (http://graphexploration.cond.org/), which takes a novel approach which combines visualization support (using JUNG, an excellent library in itself) with a DSL for graph manipulation based on Jython. This way a user can issue commands and run scripts that manipulate the graph contents with immediate visual feedback. We have been using it and has proven to be a great match for our use cases. GUESS claims to suport graphml but it was not able to parse the graphml report generated by Ivy. So I coded an XSL that creates GDF from the Ivy resolution report XML. Besides working :-) this method keeps the relevant (but non-visual) attributes from the original report in the GDF as well. These can be later used in GUESS to group nodes, create convex hulls, calculate metrics, and so on. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-897) Add VPF as a report output format
[
https://issues.apache.org/jira/browse/IVY-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628847#action_12628847
]
Xavier Hanin commented on IVY-897:
--
Nice trick, thanks for sharing! I'm not sure how to include it though, maybe it
would better be kept as a resource for those who want to achieve the same
thing. Therefore maybe a short article on the wiki would be better for the
benefit of the community?
Add VPF as a report output format
-
Key: IVY-897
URL: https://issues.apache.org/jira/browse/IVY-897
Project: Ivy
Issue Type: New Feature
Components: Core
Affects Versions: 2.0.0-beta-1
Reporter: Nascif Abousalh-Neto
Priority: Minor
Fix For: unspecified
Attachments: vpf.xsl
One of the best practices in the use of Ivy for large organizations is to
replace all the revision values in the ivy.xml files with properties.
dependency name=my.module revision=${my.module.revision} ... /
This approach allows an administrator to control all revisions values used by
all modules in one single place - a Version Property File (or VPF for short).
This way versions can be controlled in a uniform way, with minimum
maintenance and reduced chance of error. For example, you can upgrade all
your modules dependencies from Log4J 3.5 to 4.0 with one single line change -
and be sure that you didn't forget any of them behind.
Creating and maintaining VPFs is not trival though. One way to automate the
process is to harvest the module names and their latest versions from the
repository, using the repreport task to create a resolution report for the
entire repo and then converting it to a property file format using a XSL
spreadsheet (attached).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-874) can't use gotoNode with a node which has not been visited yet
[
https://issues.apache.org/jira/browse/IVY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-874.
--
Resolution: Fixed
Well, actually this is not a bug, at least from what I reproduce on my own. The
point is that Ivy does dependency resolution per configuration. Each
configuration is isolated from the others. So in the runtime conf, you only
have hibernate 3.2.6.ga, and thus end up with commons-collections 2.1.1. In
default conf, with both hibernate and commons-collections 3.2.1,
commons-collections 2.1.1 is evicted and not part of the conf. If you really
want to always evict commons-collections 2.1.1, I suggest to put your
commons-collections 3.2.1 dependency in your runtime conf.
And if I've misinterpreted the bug, do not hesitate to reopen once again.
can't use gotoNode with a node which has not been visited yet
-
Key: IVY-874
URL: https://issues.apache.org/jira/browse/IVY-874
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0-RC1
Environment: 2.0.0-rc1-local-20080805174033 (built from trunk);
checked using Eclipse 3.3 under Windows XP; Ant 1.7.0; jdk1.5.0_05
Reporter: rednix
Assignee: Xavier Hanin
Fix For: 2.0-RC1
Attachments:
hibernate-3.2.6.ga.and.commons-collections-3.2.1_trunk-2008-09-03.log,
ivy-bug-log-2008-08-06.txt, Test-test-default.png
While using the latest version of Ivy built from the trunk
(2.0.0-rc1-local-20080805174033) I can't resolve hibernate 3.2.6 GA and
commons-collection 3.2.1 together. Hibernate 3.2.6ga has a dependency on
commons-collection 2.1.1 - but I want to include the latest revision 3.2.1 in
my project. Using the fairly old ivy-2.0.0-alpha2-incubating.jar there is not
such a problem.
The configuration and error logs are as follows:
ivy.xml:
ivy-module version=1.0
info organisation=Test module=test/
configurations
conf name=default visibility=public description=runtime
dependencies and master artifact can be used with this conf
extends=runtime,master/
conf name=master visibility=public description=contains
only the artifact published by this module itself, with no transitive
dependencies/
conf name=compile visibility=public description=this is
the default scope, used if none is specified. Compile dependencies are
available in all classpaths./
conf name=provided visibility=public description=this
is much like compile, but indicates you expect the JDK or a container to
provide it. It is only available on the compilation classpath, and is not
transitive./
conf name=runtime visibility=public description=this
scope indicates that the dependency is not required for compilation, but is
for execution. It is in the runtime and test classpaths, but not the compile
classpath. extends=compile/
conf name=test visibility=private description=this
scope indicates that the dependency is not required for normal use of the
application, and is only available for the test compilation and execution
phases./
conf name=system visibility=public description=this
scope is similar to provided except that you have to provide the JAR which
contains it explicitly. The artifact is always available and is not looked up
in a repository./
conf name=optional visibility=public
description=contains all optional dependencies /
/configurations
dependencies
dependency org=commons-collections name=commons-collections
rev=3.2.1 conf=default /
dependency org=org.hibernate name=hibernate rev=3.2.6.ga
conf=runtime-runtime,master /
/dependencies
/ivy-module
ivysettings.xml:
ivysettings
settings defaultResolver=shared /
property name=ivy.shared.default.root
value=https://[removed]; override=false/
property name=ivy.shared.default.ivy.pattern
value=[organisation]/[module]/[revision]/[module]-ivy.xml override=false/
property name=ivy.shared.default.artifact.pattern
value=[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]
override=false/
resolvers
url name=shared
ivy
pattern=${ivy.shared.default.root}/${ivy.shared.default.ivy.pattern} /
artifact
pattern=${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern}
/
/url
/resolvers
/ivysettings
Error-Log:
...
[ivy:retrieve] == resolving dependencies
org.hibernate#hibernate;3.2.6.ga-commons-collections#commons-collections;2.1.1
[compile-compile(*)]
[ivy:retrieve] ERROR: You can't use gotoNode with a node which has not been
visited yet.
[ivy:retrieve] Given node id=commons-collections#commons-collections;3.2.1
[jira] Commented: (IVY-874) can't use gotoNode with a node which has not been visited yet
[
https://issues.apache.org/jira/browse/IVY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628119#action_12628119
]
Xavier Hanin commented on IVY-874:
--
Well, I don't know exactly why it was different in alpha2... maybe it was a
bug, because configuration isolation is in Ivy design since day 1. But anyway,
if you manage to get it working as you want it's fine.
can't use gotoNode with a node which has not been visited yet
-
Key: IVY-874
URL: https://issues.apache.org/jira/browse/IVY-874
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0-RC1
Environment: 2.0.0-rc1-local-20080805174033 (built from trunk);
checked using Eclipse 3.3 under Windows XP; Ant 1.7.0; jdk1.5.0_05
Reporter: rednix
Assignee: Xavier Hanin
Fix For: 2.0-RC1
Attachments:
hibernate-3.2.6.ga.and.commons-collections-3.2.1_trunk-2008-09-03.log,
ivy-bug-log-2008-08-06.txt, Test-test-default.png
While using the latest version of Ivy built from the trunk
(2.0.0-rc1-local-20080805174033) I can't resolve hibernate 3.2.6 GA and
commons-collection 3.2.1 together. Hibernate 3.2.6ga has a dependency on
commons-collection 2.1.1 - but I want to include the latest revision 3.2.1 in
my project. Using the fairly old ivy-2.0.0-alpha2-incubating.jar there is not
such a problem.
The configuration and error logs are as follows:
ivy.xml:
ivy-module version=1.0
info organisation=Test module=test/
configurations
conf name=default visibility=public description=runtime
dependencies and master artifact can be used with this conf
extends=runtime,master/
conf name=master visibility=public description=contains
only the artifact published by this module itself, with no transitive
dependencies/
conf name=compile visibility=public description=this is
the default scope, used if none is specified. Compile dependencies are
available in all classpaths./
conf name=provided visibility=public description=this
is much like compile, but indicates you expect the JDK or a container to
provide it. It is only available on the compilation classpath, and is not
transitive./
conf name=runtime visibility=public description=this
scope indicates that the dependency is not required for compilation, but is
for execution. It is in the runtime and test classpaths, but not the compile
classpath. extends=compile/
conf name=test visibility=private description=this
scope indicates that the dependency is not required for normal use of the
application, and is only available for the test compilation and execution
phases./
conf name=system visibility=public description=this
scope is similar to provided except that you have to provide the JAR which
contains it explicitly. The artifact is always available and is not looked up
in a repository./
conf name=optional visibility=public
description=contains all optional dependencies /
/configurations
dependencies
dependency org=commons-collections name=commons-collections
rev=3.2.1 conf=default /
dependency org=org.hibernate name=hibernate rev=3.2.6.ga
conf=runtime-runtime,master /
/dependencies
/ivy-module
ivysettings.xml:
ivysettings
settings defaultResolver=shared /
property name=ivy.shared.default.root
value=https://[removed]; override=false/
property name=ivy.shared.default.ivy.pattern
value=[organisation]/[module]/[revision]/[module]-ivy.xml override=false/
property name=ivy.shared.default.artifact.pattern
value=[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]
override=false/
resolvers
url name=shared
ivy
pattern=${ivy.shared.default.root}/${ivy.shared.default.ivy.pattern} /
artifact
pattern=${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern}
/
/url
/resolvers
/ivysettings
Error-Log:
...
[ivy:retrieve] == resolving dependencies
org.hibernate#hibernate;3.2.6.ga-commons-collections#commons-collections;2.1.1
[compile-compile(*)]
[ivy:retrieve] ERROR: You can't use gotoNode with a node which has not been
visited yet.
[ivy:retrieve] Given node id=commons-collections#commons-collections;3.2.1
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] WARNINGS
[ivy:retrieve] Error while parsing configuration resolve report C:\Documents
and Settings\[removed]\.ivy2\cache\Test-test-default.xml
[ivy:retrieve] ERRORS
[ivy:retrieve] You can't use gotoNode with a node which has not been visited
yet.
[ivy:retrieve] Given node id=commons-collections#commons-collections;3.2.1
[ivy:retrieve]
[ivy:retrieve]
[jira] Updated: (IVY-387) Better and more homogeneous relative paths handling
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin updated IVY-387: - Issue Type: Improvement (was: Bug) Summary: Better and more homogeneous relative paths handling (was: Absolute and relative path) Better and more homogeneous relative paths handling --- Key: IVY-387 URL: https://issues.apache.org/jira/browse/IVY-387 Project: Ivy Issue Type: Improvement Affects Versions: 1.4.1 Reporter: Gilles Scokart Assignee: Xavier Hanin Fix For: 2.0-RC1 There are a few of issues in Jira concerning absolute and relative path. Currently all the path are resolved relatively to the execution. The different issues are : - includes in the ivyconf files (IVY-372) - properties in the ivyconf files (IVY-89) - include configurations in the ivy files (IVY-347) In all case, the path should be resolved relatively to the including file, and not relatively to the current execution task. There is also at least an other issue concerning the path resulutiion in ant task parameter (IVY-232). I think all those problems should be fixed together in order to keep ivy more consistent. However, there is a backward compatibility issue: some projects (for which it is required to launch the build from the base directory) rely on the fact that ivy use path relative to the current execution directory. And if they reference files that are not in the base directory, the change will break their build. The first project in that case is ivy itself! Try 'ant -f ivy/build.xml test' and you will see plenty of test failing. Comment from Xavier on the mailing list : What could be done is have a single setting somewhere saying if relative paths resolution should be done in backward compatible mode, or new mode. The default could even be new mode, if it's clearly documented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-387) Better and more homogeneous relative paths handling
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-387. -- Resolution: Fixed I've implemented what Gilles suggested: now relative paths in settings files are allowed for properties and settings inclusion only. I had to update a lot of unit tests, which were using relative paths. Now it should work well, and behave more consistently. I've also documented relative paths handling on the main concept page. Better and more homogeneous relative paths handling --- Key: IVY-387 URL: https://issues.apache.org/jira/browse/IVY-387 Project: Ivy Issue Type: Improvement Affects Versions: 1.4.1 Reporter: Gilles Scokart Assignee: Xavier Hanin Fix For: 2.0-RC1 There are a few of issues in Jira concerning absolute and relative path. Currently all the path are resolved relatively to the execution. The different issues are : - includes in the ivyconf files (IVY-372) - properties in the ivyconf files (IVY-89) - include configurations in the ivy files (IVY-347) In all case, the path should be resolved relatively to the including file, and not relatively to the current execution task. There is also at least an other issue concerning the path resulutiion in ant task parameter (IVY-232). I think all those problems should be fixed together in order to keep ivy more consistent. However, there is a backward compatibility issue: some projects (for which it is required to launch the build from the base directory) rely on the fact that ivy use path relative to the current execution directory. And if they reference files that are not in the base directory, the change will break their build. The first project in that case is ivy itself! Try 'ant -f ivy/build.xml test' and you will see plenty of test failing. Comment from Xavier on the mailing list : What could be done is have a single setting somewhere saying if relative paths resolution should be done in backward compatible mode, or new mode. The default could even be new mode, if it's clearly documented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-349) Endless recursion in Report
[ https://issues.apache.org/jira/browse/IVY-349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-349. -- Resolution: Cannot Reproduce Fix Version/s: (was: 2.0-RC1) No news on this issue, so I mark it as Cannot Reproduce. Please reopen with more details if you reproduce the problem. Endless recursion in Report --- Key: IVY-349 URL: https://issues.apache.org/jira/browse/IVY-349 Project: Ivy Issue Type: Bug Affects Versions: 1.4.1 Environment: W2kpro, jdk1.5.0_06 Reporter: Jan Koops Priority: Minor Attachments: tkeasy-app-zahnersatz-binaries.xml Endless recursion while generating report via XSLT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (IVY-855) Overuse of XML attributes where subelements would be more appropriate
[
https://issues.apache.org/jira/browse/IVY-855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin updated IVY-855:
-
Issue Type: Improvement (was: Bug)
Overuse of XML attributes where subelements would be more appropriate
-
Key: IVY-855
URL: https://issues.apache.org/jira/browse/IVY-855
Project: Ivy
Issue Type: Improvement
Components: Core
Affects Versions: 2.0.0-beta-2
Reporter: Sakari Maaranen
Priority: Minor
Ivy uses XML attributes all too often. Many information elements, especially
potential multiline text items should be possible to specify as XML elements
instead of attributes.
Probably the best examples are various description-items, e.g. module
configuration descriptions. Currently one must specify: {{conf
name=example description=WENDY /}}
It would be better to do it like so:
{{conf name=example}}
{{ description}}
{{WELCOME TO MIAMI BEACH.}}
{{HAVE A NICE DAY!}}
{{ /description}}
{{/conf}}
At least potentially long data elements like descriptions should be made
sub-elements instead of attributes. Of course both could be allowed like Ant
often does.
This should also be promoted as a design principle, and not just an
individual bug. Always supports XML element notation when some information
element is potentially long, multiline, or structural. Both the attribute and
the element notation should be supported when an item can be either small or
large (multiple lines / structured).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-875) post-download-artifact trigger file.property points to cache location
[ https://issues.apache.org/jira/browse/IVY-875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-875. -- Resolution: Invalid This is actually the expected behaviour. Indeed files are downloaded to Ivy cache before being copied at retrieve time. This is explained in how it works page of the documentation, and since retrieve is not mandatory, I don't see how post-download-artifact file attribute could point to sg different. Now you may want to open an issue to ask for a new event triggered after an artifact is retrieved. In this case the file location would obviously be the retrieved location. post-download-artifact trigger file.property points to cache location - Key: IVY-875 URL: https://issues.apache.org/jira/browse/IVY-875 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0.0-beta-2, 2.0 Reporter: Ross Camara The file property provided by the post-download-artifact trigger points to a file within the cache and not to the actually file in specified retrieve location. The description of the the trigger does not indicate if the file should already be in place however I believe this is a reasonable expectation. This would allow users of this trigger perform actions on the downloaded artifact. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-874) can't use gotoNode with a node which has not been visited yet
[
https://issues.apache.org/jira/browse/IVY-874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-874.
--
Resolution: Fixed
I've reproduced the bug in a unit test, and fixed the problem. Thanks for
reporting!
can't use gotoNode with a node which has not been visited yet
-
Key: IVY-874
URL: https://issues.apache.org/jira/browse/IVY-874
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0-RC1
Environment: 2.0.0-rc1-local-20080805174033 (built from trunk);
checked using Eclipse 3.3 under Windows XP; Ant 1.7.0; jdk1.5.0_05
Reporter: rednix
Assignee: Xavier Hanin
Fix For: 2.0-RC1
Attachments: ivy-bug-log-2008-08-06.txt
While using the latest version of Ivy built from the trunk
(2.0.0-rc1-local-20080805174033) I can't resolve hibernate 3.2.6 GA and
commons-collection 3.2.1 together. Hibernate 3.2.6ga has a dependency on
commons-collection 2.1.1 - but I want to include the latest revision 3.2.1 in
my project. Using the fairly old ivy-2.0.0-alpha2-incubating.jar there is not
such a problem.
The configuration and error logs are as follows:
ivy.xml:
ivy-module version=1.0
info organisation=Test module=test/
configurations
conf name=default visibility=public description=runtime
dependencies and master artifact can be used with this conf
extends=runtime,master/
conf name=master visibility=public description=contains
only the artifact published by this module itself, with no transitive
dependencies/
conf name=compile visibility=public description=this is
the default scope, used if none is specified. Compile dependencies are
available in all classpaths./
conf name=provided visibility=public description=this
is much like compile, but indicates you expect the JDK or a container to
provide it. It is only available on the compilation classpath, and is not
transitive./
conf name=runtime visibility=public description=this
scope indicates that the dependency is not required for compilation, but is
for execution. It is in the runtime and test classpaths, but not the compile
classpath. extends=compile/
conf name=test visibility=private description=this
scope indicates that the dependency is not required for normal use of the
application, and is only available for the test compilation and execution
phases./
conf name=system visibility=public description=this
scope is similar to provided except that you have to provide the JAR which
contains it explicitly. The artifact is always available and is not looked up
in a repository./
conf name=optional visibility=public
description=contains all optional dependencies /
/configurations
dependencies
dependency org=commons-collections name=commons-collections
rev=3.2.1 conf=default /
dependency org=org.hibernate name=hibernate rev=3.2.6.ga
conf=runtime-runtime,master /
/dependencies
/ivy-module
ivysettings.xml:
ivysettings
settings defaultResolver=shared /
property name=ivy.shared.default.root
value=https://[removed]; override=false/
property name=ivy.shared.default.ivy.pattern
value=[organisation]/[module]/[revision]/[module]-ivy.xml override=false/
property name=ivy.shared.default.artifact.pattern
value=[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]
override=false/
resolvers
url name=shared
ivy
pattern=${ivy.shared.default.root}/${ivy.shared.default.ivy.pattern} /
artifact
pattern=${ivy.shared.default.root}/${ivy.shared.default.artifact.pattern}
/
/url
/resolvers
/ivysettings
Error-Log:
...
[ivy:retrieve] == resolving dependencies
org.hibernate#hibernate;3.2.6.ga-commons-collections#commons-collections;2.1.1
[compile-compile(*)]
[ivy:retrieve] ERROR: You can't use gotoNode with a node which has not been
visited yet.
[ivy:retrieve] Given node id=commons-collections#commons-collections;3.2.1
[ivy:retrieve] :: problems summary ::
[ivy:retrieve] WARNINGS
[ivy:retrieve] Error while parsing configuration resolve report C:\Documents
and Settings\[removed]\.ivy2\cache\Test-test-default.xml
[ivy:retrieve] ERRORS
[ivy:retrieve] You can't use gotoNode with a node which has not been visited
yet.
[ivy:retrieve] Given node id=commons-collections#commons-collections;3.2.1
[ivy:retrieve]
[ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
BUILD FAILED
C:\workspaces\eclipseEuropa\Test\build.xml:433: impossible to resolve
dependencies:
java.lang.IllegalArgumentException: You can't use gotoNode with a
node which has not
[jira] Commented: (IVY-387) Absolute and relative path
[ https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12627415#action_12627415 ] Xavier Hanin commented on IVY-387: -- Your proposition makes sense. We can allow relative paths in settings only for properties and file inclusion. All other paths (in resolvers, cache, or wherever) must be absolute, we fail settings loading if they aren't. If a plugin really wants to accept relative path, it will have to use a String attribute instead of a File attribute, and convert it to a File itself. What do other think of this solution? Absolute and relative path -- Key: IVY-387 URL: https://issues.apache.org/jira/browse/IVY-387 Project: Ivy Issue Type: Bug Affects Versions: 1.4.1 Reporter: Gilles Scokart Assignee: Gilles Scokart Fix For: 2.0-RC1 There are a few of issues in Jira concerning absolute and relative path. Currently all the path are resolved relatively to the execution. The different issues are : - includes in the ivyconf files (IVY-372) - properties in the ivyconf files (IVY-89) - include configurations in the ivy files (IVY-347) In all case, the path should be resolved relatively to the including file, and not relatively to the current execution task. There is also at least an other issue concerning the path resulutiion in ant task parameter (IVY-232). I think all those problems should be fixed together in order to keep ivy more consistent. However, there is a backward compatibility issue: some projects (for which it is required to launch the build from the base directory) rely on the fact that ivy use path relative to the current execution directory. And if they reference files that are not in the base directory, the change will break their build. The first project in that case is ivy itself! Try 'ant -f ivy/build.xml test' and you will see plenty of test failing. Comment from Xavier on the mailing list : What could be done is have a single setting somewhere saying if relative paths resolution should be done in backward compatible mode, or new mode. The default could even be new mode, if it's clearly documented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-887) HelloWorld chainedresolvers tutorial broken on trunk
[ https://issues.apache.org/jira/browse/IVY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin reassigned IVY-887: Assignee: Xavier Hanin HelloWorld chainedresolvers tutorial broken on trunk Key: IVY-887 URL: https://issues.apache.org/jira/browse/IVY-887 Project: Ivy Issue Type: Bug Affects Versions: 2.0 Reporter: Don Ferguson Assignee: Xavier Hanin One of the resolvers downloads the wrong jar file (such as the source, or the javadoc) which is deposited in the lib directory. The javac then fails. For example: Run ant src/example/chained-resolvers/chainedresolvers-project/build.xml doc/tutorial/log/chained-resolvers.txt Buildfile: src/example/chained-resolvers/chainedresolvers-project/build.xml resolve: [ivy:retrieve] :: Ivy 2.0.0-rc1-local-20080829125259 - 20080829125259 :: http://ant.apache.org/ivy/ :: :: loading settings :: file = /apps/src/ivy/trunk/src/example/chained-resolvers/settings/ivysettings.xml [ivy:retrieve] :: resolving dependencies :: org.apache#chained-resolvers;[EMAIL PROTECTED] [ivy:retrieve] confs: [default] [ivy:retrieve] found commons-lang#commons-lang;2.0 in ibiblio [ivy:retrieve] found org.apache#test;1.0 in libraries [ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-sources.jar ... [ivy:retrieve] [ivy:retrieve] ... (245kB) [ivy:retrieve] .. (0kB) [ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar(source) (2250ms) [ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-javadoc.jar ... [ivy:retrieve] .. [ivy:retrieve] .. (467kB) [ivy:retrieve] .. (0kB) [ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar(javadoc) (3598ms) [ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar ... [ivy:retrieve] ... (165kB) [ivy:retrieve] .. (0kB) [ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar (1698ms) [ivy:retrieve] downloading /apps/src/ivy/trunk/src/example/chained-resolvers/settings/repository/test-1.0.jar ... [ivy:retrieve] .. (1kB) [ivy:retrieve] [SUCCESSFUL ] org.apache#test;1.0!test.jar (2ms) [ivy:retrieve] :: resolution report :: resolve 1719ms :: artifacts dl 7555ms - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | default | 2 | 2 | 1 | 0 || 4 | 4 | - [ivy:retrieve] :: retrieving :: org.apache#chained-resolvers [ivy:retrieve] confs: [default] [ivy:retrieve] conflict on /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/lib/commons-lang-2.0.jar in [default]: 2.0 won [ivy:retrieve] 2 artifacts copied, 0 already retrieved (246kB/12ms) run: [mkdir] Created dir: /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build [javac] Compiling 1 source file to /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build [javac] /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:20: package org.apache.commons.lang does not exist [javac] import org.apache.commons.lang.WordUtils; [javac]^ [javac] /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:29: cannot find symbol [javac] symbol : class WordUtils [javac] location: class example.Hello [javac] System.out.println(capitalized by + WordUtils.class.getName() [javac]^ [javac] /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:30: cannot find symbol [javac]
[jira] Resolved: (IVY-887) HelloWorld chainedresolvers tutorial broken on trunk
[ https://issues.apache.org/jira/browse/IVY-887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-887. -- Resolution: Fixed Fix Version/s: 2.0-RC1 I've fixed the problem, thanks for reporting! HelloWorld chainedresolvers tutorial broken on trunk Key: IVY-887 URL: https://issues.apache.org/jira/browse/IVY-887 Project: Ivy Issue Type: Bug Affects Versions: 2.0 Reporter: Don Ferguson Assignee: Xavier Hanin Fix For: 2.0-RC1 One of the resolvers downloads the wrong jar file (such as the source, or the javadoc) which is deposited in the lib directory. The javac then fails. For example: Run ant src/example/chained-resolvers/chainedresolvers-project/build.xml doc/tutorial/log/chained-resolvers.txt Buildfile: src/example/chained-resolvers/chainedresolvers-project/build.xml resolve: [ivy:retrieve] :: Ivy 2.0.0-rc1-local-20080829125259 - 20080829125259 :: http://ant.apache.org/ivy/ :: :: loading settings :: file = /apps/src/ivy/trunk/src/example/chained-resolvers/settings/ivysettings.xml [ivy:retrieve] :: resolving dependencies :: org.apache#chained-resolvers;[EMAIL PROTECTED] [ivy:retrieve] confs: [default] [ivy:retrieve] found commons-lang#commons-lang;2.0 in ibiblio [ivy:retrieve] found org.apache#test;1.0 in libraries [ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-sources.jar ... [ivy:retrieve] [ivy:retrieve] ... (245kB) [ivy:retrieve] .. (0kB) [ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar(source) (2250ms) [ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0-javadoc.jar ... [ivy:retrieve] .. [ivy:retrieve] .. (467kB) [ivy:retrieve] .. (0kB) [ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar(javadoc) (3598ms) [ivy:retrieve] downloading http://repo1.maven.org/maven2/commons-lang/commons-lang/2.0/commons-lang-2.0.jar ... [ivy:retrieve] ... (165kB) [ivy:retrieve] .. (0kB) [ivy:retrieve] [SUCCESSFUL ] commons-lang#commons-lang;2.0!commons-lang.jar (1698ms) [ivy:retrieve] downloading /apps/src/ivy/trunk/src/example/chained-resolvers/settings/repository/test-1.0.jar ... [ivy:retrieve] .. (1kB) [ivy:retrieve] [SUCCESSFUL ] org.apache#test;1.0!test.jar (2ms) [ivy:retrieve] :: resolution report :: resolve 1719ms :: artifacts dl 7555ms - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | default | 2 | 2 | 1 | 0 || 4 | 4 | - [ivy:retrieve] :: retrieving :: org.apache#chained-resolvers [ivy:retrieve] confs: [default] [ivy:retrieve] conflict on /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/lib/commons-lang-2.0.jar in [default]: 2.0 won [ivy:retrieve] 2 artifacts copied, 0 already retrieved (246kB/12ms) run: [mkdir] Created dir: /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build [javac] Compiling 1 source file to /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/build [javac] /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:20: package org.apache.commons.lang does not exist [javac] import org.apache.commons.lang.WordUtils; [javac]^ [javac] /apps/src/ivy/trunk/src/example/chained-resolvers/chainedresolvers-project/src/example/Hello.java:29: cannot find symbol [javac] symbol : class WordUtils [javac] location: class example.Hello [javac] System.out.println(capitalized by + WordUtils.class.getName() [javac]^ [javac]
[jira] Commented: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626874#action_12626874 ] Xavier Hanin commented on IVY-232: -- Absolutely! Incorrect directory path resolve when running from a different directory Key: IVY-232 URL: https://issues.apache.org/jira/browse/IVY-232 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 1.3-RC2 Environment: Windows 2000 (probably Unix also. Didn't check that) Reporter: easyproglife Assignee: Xavier Hanin Fix For: 2.0-RC1 Attachments: ivy-232-patch.txt Suppose you have two projects in two directories: /projA /projB Each one of them have its own build.xml. When you run Ant on /projA/build.xml from /projA evrything is ok. When you run from /projB ant -f ..\projA\build.xml relative pathes are based on projB by Ivy, whereas the correct way (as Ant and Maven works) is to use projA as the base directory (assuming /projA/build.xml has basedir attribute: .) In other words, Ivy should take the base directory as specified in the build.xml file in project tag in basedir attribute, and calculate it based on the location of the build.xml file; not based on the current directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-849) undeprecate configure task
[ https://issues.apache.org/jira/browse/IVY-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12627010#action_12627010 ] Xavier Hanin commented on IVY-849: -- This has already been discussed on the dev mailing list if I remember correctly. Moreover, the method you're referring has been introduced much more recently than what you think, in beta2 I think. Finally with Ivy 2.0, we do not pretend to be backward compatible at API level. So we accept that we break some code with this change. undeprecate configure task -- Key: IVY-849 URL: https://issues.apache.org/jira/browse/IVY-849 Project: Ivy Issue Type: Improvement Components: Ant Reporter: Xavier Hanin Assignee: Maarten Coene Fix For: 2.0-RC1 As we have agreed on mailing list, we should undeprecate the configure task, since using a data type to load settings is not user friendly enough. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-232. -- Resolution: Fixed I've resolved this issue, now all relative files should be relative to the base directory set in IvySettings, which defaults to current directory, except when used from Ant, in which case it's the Ant basedir which is used. I say all, but it's not true. Indeed, some work has already been done in the settings parsing to handle properties file and settings inclusion path specifically. I will discuss that on IVY-387, since this is not only related to this issue but is more general about absolute and relative paths. Incorrect directory path resolve when running from a different directory Key: IVY-232 URL: https://issues.apache.org/jira/browse/IVY-232 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 1.3-RC2 Environment: Windows 2000 (probably Unix also. Didn't check that) Reporter: easyproglife Assignee: Xavier Hanin Fix For: 2.0-RC1 Attachments: ivy-232-patch.txt Suppose you have two projects in two directories: /projA /projB Each one of them have its own build.xml. When you run Ant on /projA/build.xml from /projA evrything is ok. When you run from /projB ant -f ..\projA\build.xml relative pathes are based on projB by Ivy, whereas the correct way (as Ant and Maven works) is to use projA as the base directory (assuming /projA/build.xml has basedir attribute: .) In other words, Ivy should take the base directory as specified in the build.xml file in project tag in basedir attribute, and calculate it based on the location of the build.xml file; not based on the current directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-387) Absolute and relative path
[
https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12627028#action_12627028
]
Xavier Hanin commented on IVY-387:
--
I've just resolved IVY-232, but I'm not happy of how we handle relative paths
globally. With current trunk we have:
* relative paths for properties and settings file in a settings file are
relative to the settings file itself (see IVY-372 and IVY-89)
* relative paths for configurations inclusion are relative to the Ivy file
defining the inclusion
* all other paths are relative to what is called Ivy settings basedir, which is
by default the current execution directory, except when run from Ant, where it
is the Ant basedir
This means that relative paths for File attributes on resolvers and caches, for
instance, are relative to the basedir, not the settings file.
So if you have:
{code}
ivysettings
include file=relative/path/to/ivysettings2.xml /
caches repositoryCacheDir=relative/path/to/repository /
/ivysettings
{code}
Then the first relative path is relative to the settings file, the second is
relative to the basedir. While I first considered unifying this by making all
paths in settings file relative to the settings file itself, I realized this is
not possible, because the settings can be loaded using an URL. To load
properties or other settings it's not a problem because we can actually load
them using an URL, but this is not possible to convert a generic URL to a File.
So I don't know what's the best solution. IMO, the easiest to implement and the
most uniform would be to make all paths in the settings relative to the
basedir. In this case people who want to use paths relative to the settings
file have to explicitly put ${ivy.settings.dir} before their path. This is
slightly less user friendly.
Another solution is to keep things as is, but I really don't like it.
Yet another solution is to make all paths in settings file relative to the
settings file as long as the settings are loaded as a file. In other cases, it
would be relative to basedir. I don't like this solution either, because the
behavior then depend on how you load your settings.
So I'm definitely in favor of #1, but maybe some have other ideas or other
opinion.
Absolute and relative path
--
Key: IVY-387
URL: https://issues.apache.org/jira/browse/IVY-387
Project: Ivy
Issue Type: Bug
Affects Versions: 1.4.1
Reporter: Gilles Scokart
Assignee: Gilles Scokart
Fix For: 2.0-RC1
There are a few of issues in Jira concerning absolute and relative path.
Currently all the path are resolved relatively to the execution.
The different issues are :
- includes in the ivyconf files (IVY-372)
- properties in the ivyconf files (IVY-89)
- include configurations in the ivy files (IVY-347) In all case, the path
should be resolved relatively to the including file, and not relatively to
the current execution task.
There is also at least an other issue concerning the path resulutiion in ant
task parameter (IVY-232).
I think all those problems should be fixed together in order to keep ivy more
consistent. However, there is a backward compatibility issue: some projects
(for which it is required to launch the build from the base directory) rely
on the fact that ivy use path relative to the current execution directory.
And if they reference files that are not in the base directory, the change
will break their build.
The first project in that case is ivy itself! Try 'ant -f ivy/build.xml test'
and you will see plenty of test failing.
Comment from Xavier on the mailing list :
What could be done is have a single setting somewhere saying if relative
paths resolution should be done in backward compatible mode, or new mode. The
default could even be new mode, if it's clearly documented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-387) Absolute and relative path
[
https://issues.apache.org/jira/browse/IVY-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12627073#action_12627073
]
Xavier Hanin commented on IVY-387:
--
bq. if an ivy settings is served by http, using relative path would make no
sense and things should blows up
Well, it depends. If what you need is an URL like for properties loading or
settings inclusion, it doesn't need to blow up. But I agree that from a user
point of view having paths in a settings file relative to the settings file
itself is more obvious. What I dislike is having the same settings file blowing
up in one case and not in the other case.
We also need to be very careful if we choose to make paths relative to the
settings file. Indeed, if we can pretty easily handle this for resolvers using
a File attribute, the case is different for resolvers which takes a String,
which is later converted to a File. For instance a filesystem resolver takes an
Ivy pattern. The pattern is a String, which the resolver has to convert to a
File at resolution time. But currently the resolver has no idea of which
settings file was used to define it. So to resolve the pattern as relative to
the settings file, we'd need to keep this information, even for included
settings. This leads also to problems with macros. Which settings file should
be considered, the one in which the macro is defined, or the one in which the
resolver based on this macro is defined?
The more I think about it, the more I think trying to make paths relative to
the settings file is error prone. So I think I still prefer to keep it simple,
users still have the option to use ${ivy.settings.dir} to make their paths
relative to the current settings file. That being said, I won't veto if the
majority agree to have paths relative to settings file by default.
Absolute and relative path
--
Key: IVY-387
URL: https://issues.apache.org/jira/browse/IVY-387
Project: Ivy
Issue Type: Bug
Affects Versions: 1.4.1
Reporter: Gilles Scokart
Assignee: Gilles Scokart
Fix For: 2.0-RC1
There are a few of issues in Jira concerning absolute and relative path.
Currently all the path are resolved relatively to the execution.
The different issues are :
- includes in the ivyconf files (IVY-372)
- properties in the ivyconf files (IVY-89)
- include configurations in the ivy files (IVY-347) In all case, the path
should be resolved relatively to the including file, and not relatively to
the current execution task.
There is also at least an other issue concerning the path resulutiion in ant
task parameter (IVY-232).
I think all those problems should be fixed together in order to keep ivy more
consistent. However, there is a backward compatibility issue: some projects
(for which it is required to launch the build from the base directory) rely
on the fact that ivy use path relative to the current execution directory.
And if they reference files that are not in the base directory, the change
will break their build.
The first project in that case is ivy itself! Try 'ant -f ivy/build.xml test'
and you will see plenty of test failing.
Comment from Xavier on the mailing list :
What could be done is have a single setting somewhere saying if relative
paths resolution should be done in backward compatible mode, or new mode. The
default could even be new mode, if it's clearly documented.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626489#action_12626489 ] Xavier Hanin commented on IVY-232: -- Matt, do you have a patch for this? I can try to review and test it if you attach it to this issue. Incorrect directory path resolve when running from a different directory Key: IVY-232 URL: https://issues.apache.org/jira/browse/IVY-232 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 1.3-RC2 Environment: Windows 2000 (probably Unix also. Didn't check that) Reporter: easyproglife Assignee: Gilles Scokart Fix For: 2.0-RC1 Suppose you have two projects in two directories: /projA /projB Each one of them have its own build.xml. When you run Ant on /projA/build.xml from /projA evrything is ok. When you run from /projB ant -f ..\projA\build.xml relative pathes are based on projB by Ivy, whereas the correct way (as Ant and Maven works) is to use projA as the base directory (assuming /projA/build.xml has basedir attribute: .) In other words, Ivy should take the base directory as specified in the build.xml file in project tag in basedir attribute, and calculate it based on the location of the build.xml file; not based on the current directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVYDE-117) same jar files get downloaded 3 times (binary, javadoc and sources jar files are identical)
[
https://issues.apache.org/jira/browse/IVYDE-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin reassigned IVYDE-117:
--
Assignee: Xavier Hanin
same jar files get downloaded 3 times (binary, javadoc and sources jar files
are identical)
---
Key: IVYDE-117
URL: https://issues.apache.org/jira/browse/IVYDE-117
Project: IvyDE
Issue Type: Bug
Components: classpath container
Affects Versions: 2.0.0.alpha1
Environment: Eclipse 3.3.2, Java 1.6.0_06, Ubuntu 8.04
Reporter: Lari Hotari
Assignee: Xavier Hanin
same jar files get downloaded 3 times (binary, javadoc and sources jar files
are identical)
ivysettings.xml:
ivysettings
property name=ibiblio-maven2-root
value=http://mirrors.ibiblio.org/pub/mirrors/maven2/; override=false /
property name=maven2.pattern
value=[organisation]/[module]/[revision]/[module]-[revision].[ext] /
conf defaultResolver='maven2' /
resolvers
ibiblio name=maven2 root=${ibiblio-maven2-root}
pattern=${maven2.pattern} m2compatible=true usepoms=false/
/resolvers
/ivysettings
ivy.xml:
ivy-module version=1.0
info
organisation=
module=MyExample
status=integration
/info
dependencies
dependency org=jaxen name=jaxen rev=1.1.1/
/dependencies
/ivy-module
by looking at the code in
http://svn.apache.org/viewvc/ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyResolveJob.java?view=markup
I found a workaround (by adding ([classifier]) to the pattern):
property name=maven2.pattern
value=[organisation]/[module]/[revision]/[module]-[revision]([classifier]).[ext]
/
This prevents downloading javadoc and source jars, but doesn't fix the
problem.
Console log that shows the problem:
checking source for jaxen#jaxen;1.1.1!jaxen.jar
trying
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
tried
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
...
maven2: downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
to
/home/lari/.ivy2/cache/jaxen/jaxen/sources/jaxen-1.1.1.jar.part
sha1 file found for
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar:
checking...
maven2: downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar.sha1
to /tmp/ivytmp51367sha1
sha1 OK for
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
[SUCCESSFUL ] jaxen#jaxen;1.1.1!jaxen.jar(source) (2044ms)
checking javadoc for jaxen#jaxen;1.1.1!jaxen.jar
trying
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
tried
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
...
maven2: downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
to
/home/lari/.ivy2/cache/jaxen/jaxen/javadocs/jaxen-1.1.1.jar.part
sha1 file found for
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar:
checking...
maven2: downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar.sha1
to /tmp/ivytmp51368sha1
sha1 OK for
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVYDE-117) same jar files get downloaded 3 times (binary, javadoc and sources jar files are identical)
[
https://issues.apache.org/jira/browse/IVYDE-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVYDE-117.
Resolution: Fixed
Fix Version/s: 2.0
I've easily reproduced the problem, and fixed it, with both patterns. It
actually involved more Ivy changes than IvyDE, but it's fixed in trunk now.
Thanks for reporting!
same jar files get downloaded 3 times (binary, javadoc and sources jar files
are identical)
---
Key: IVYDE-117
URL: https://issues.apache.org/jira/browse/IVYDE-117
Project: IvyDE
Issue Type: Bug
Components: classpath container
Affects Versions: 2.0.0.alpha1
Environment: Eclipse 3.3.2, Java 1.6.0_06, Ubuntu 8.04
Reporter: Lari Hotari
Assignee: Xavier Hanin
Fix For: 2.0
same jar files get downloaded 3 times (binary, javadoc and sources jar files
are identical)
ivysettings.xml:
ivysettings
property name=ibiblio-maven2-root
value=http://mirrors.ibiblio.org/pub/mirrors/maven2/; override=false /
property name=maven2.pattern
value=[organisation]/[module]/[revision]/[module]-[revision].[ext] /
conf defaultResolver='maven2' /
resolvers
ibiblio name=maven2 root=${ibiblio-maven2-root}
pattern=${maven2.pattern} m2compatible=true usepoms=false/
/resolvers
/ivysettings
ivy.xml:
ivy-module version=1.0
info
organisation=
module=MyExample
status=integration
/info
dependencies
dependency org=jaxen name=jaxen rev=1.1.1/
/dependencies
/ivy-module
by looking at the code in
http://svn.apache.org/viewvc/ant/ivy/ivyde/trunk/org.apache.ivyde.eclipse/src/java/org/apache/ivyde/eclipse/cpcontainer/IvyResolveJob.java?view=markup
I found a workaround (by adding ([classifier]) to the pattern):
property name=maven2.pattern
value=[organisation]/[module]/[revision]/[module]-[revision]([classifier]).[ext]
/
This prevents downloading javadoc and source jars, but doesn't fix the
problem.
Console log that shows the problem:
checking source for jaxen#jaxen;1.1.1!jaxen.jar
trying
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
tried
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
...
maven2: downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
to
/home/lari/.ivy2/cache/jaxen/jaxen/sources/jaxen-1.1.1.jar.part
sha1 file found for
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar:
checking...
maven2: downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar.sha1
to /tmp/ivytmp51367sha1
sha1 OK for
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
[SUCCESSFUL ] jaxen#jaxen;1.1.1!jaxen.jar(source) (2044ms)
checking javadoc for jaxen#jaxen;1.1.1!jaxen.jar
trying
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
tried
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
...
maven2: downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
to
/home/lari/.ivy2/cache/jaxen/jaxen/javadocs/jaxen-1.1.1.jar.part
sha1 file found for
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar:
checking...
maven2: downloading
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar.sha1
to /tmp/ivytmp51368sha1
sha1 OK for
http://mirrors.ibiblio.org/pub/mirrors/maven2/jaxen/jaxen/1.1.1/jaxen-1.1.1.jar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin reassigned IVY-232: Assignee: Xavier Hanin (was: Gilles Scokart) Incorrect directory path resolve when running from a different directory Key: IVY-232 URL: https://issues.apache.org/jira/browse/IVY-232 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 1.3-RC2 Environment: Windows 2000 (probably Unix also. Didn't check that) Reporter: easyproglife Assignee: Xavier Hanin Fix For: 2.0-RC1 Attachments: ivy-232-patch.txt Suppose you have two projects in two directories: /projA /projB Each one of them have its own build.xml. When you run Ant on /projA/build.xml from /projA evrything is ok. When you run from /projB ant -f ..\projA\build.xml relative pathes are based on projB by Ivy, whereas the correct way (as Ant and Maven works) is to use projA as the base directory (assuming /projA/build.xml has basedir attribute: .) In other words, Ivy should take the base directory as specified in the build.xml file in project tag in basedir attribute, and calculate it based on the location of the build.xml file; not based on the current directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626633#action_12626633 ] Xavier Hanin commented on IVY-232: -- Indeed, it's the good approach, the only problem is that we have a lot of places where we instantiate File objects, and we have to do the change every where. I'll take care of that, thanks for your help! Incorrect directory path resolve when running from a different directory Key: IVY-232 URL: https://issues.apache.org/jira/browse/IVY-232 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 1.3-RC2 Environment: Windows 2000 (probably Unix also. Didn't check that) Reporter: easyproglife Assignee: Gilles Scokart Fix For: 2.0-RC1 Attachments: ivy-232-patch.txt Suppose you have two projects in two directories: /projA /projB Each one of them have its own build.xml. When you run Ant on /projA/build.xml from /projA evrything is ok. When you run from /projB ant -f ..\projA\build.xml relative pathes are based on projB by Ivy, whereas the correct way (as Ant and Maven works) is to use projA as the base directory (assuming /projA/build.xml has basedir attribute: .) In other words, Ivy should take the base directory as specified in the build.xml file in project tag in basedir attribute, and calculate it based on the location of the build.xml file; not based on the current directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12626641#action_12626641 ] Xavier Hanin commented on IVY-232: -- Yes, except that I'll introduce a new property on the settings, probably basedir, since default user dir is used for default cache location. I think I'll also add a File resolveFile(String) method on IvySettings, which will do a similar work as Project#resolveFile(String) in Ant. The time consuming work is to locate every File object instantiation and replace them by a call to this method. Incorrect directory path resolve when running from a different directory Key: IVY-232 URL: https://issues.apache.org/jira/browse/IVY-232 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 1.3-RC2 Environment: Windows 2000 (probably Unix also. Didn't check that) Reporter: easyproglife Assignee: Xavier Hanin Fix For: 2.0-RC1 Attachments: ivy-232-patch.txt Suppose you have two projects in two directories: /projA /projB Each one of them have its own build.xml. When you run Ant on /projA/build.xml from /projA evrything is ok. When you run from /projB ant -f ..\projA\build.xml relative pathes are based on projB by Ivy, whereas the correct way (as Ant and Maven works) is to use projA as the base directory (assuming /projA/build.xml has basedir attribute: .) In other words, Ivy should take the base directory as specified in the build.xml file in project tag in basedir attribute, and calculate it based on the location of the build.xml file; not based on the current directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-745) Unwanted eviction of dependencies when optional attributes in dependency and info tags are in consistent
[
https://issues.apache.org/jira/browse/IVY-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin reassigned IVY-745:
Assignee: Xavier Hanin
Unwanted eviction of dependencies when optional attributes in dependency and
info tags are in consistent
--
Key: IVY-745
URL: https://issues.apache.org/jira/browse/IVY-745
Project: Ivy
Issue Type: Improvement
Environment: Fedora 7 (i386), Java 1.5.0_10, apache-ivy-2.0.0-beta1,
Ant 1.6.5
Reporter: Vasco Lemoine
Assignee: Xavier Hanin
Priority: Minor
Fix For: 2.0-RC1
I introduced a extra attribute which I am using for building of
submodules.
foo-ivy.xml:
ivy-module version='2.0'
info organisation='foo' module='foo' revision='1' /
configurations
include file='${build_home}/etc/ivy/ivy-configurations.xml' /
/configurations
publications /
dependencies
dependency org='bar' name='bar' rev='trunk' submodule='bar' /
/dependencies
/ivy-module
bar-ivy.xml:
ivy-module version='2.0'
info organisation='bar' module='bar' revision='1' /
configurations
include file='${build_home}/etc/ivy/ivy-configurations.xml' /
/configurations
publications /
dependencies
dependency org='foobar' name='foobar' rev='1' /
/dependencies
/ivy-module
Because the submodule attribute was missing in the bar-ivy.xml info
tag. The foobar dependency gets evicted. I'm not sure this is expected
behavior. If not it is probably a bug or at least the provided
information is not clear enough to troubleshoot. Of course the work
around is adding the extra attribute to the info tag:
ivy-module version='2.0'
info organisation='bar' module='bar' revision='1' submodule='bar' /
configurations
include file='${build_home}/etc/ivy/ivy-configurations.xml' /
/configurations
publications /
dependencies
dependency org='foobar' name='foobar' rev='1' /
/dependencies
/ivy-module
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-745) Unwanted eviction of dependencies when optional attributes in dependency and info tags are in consistent
[
https://issues.apache.org/jira/browse/IVY-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-745.
--
Resolution: Fixed
I've fixed the problem and added unit tests for two things. Now if extra
attributes in dependency declaration is inconsistent with module descriptor,
then:
* it will raise an error during consistency check, so that a clear error
message is displayed
* with consistency checking disabled, it works without any strange eviction or
module not found
Unwanted eviction of dependencies when optional attributes in dependency and
info tags are in consistent
--
Key: IVY-745
URL: https://issues.apache.org/jira/browse/IVY-745
Project: Ivy
Issue Type: Improvement
Environment: Fedora 7 (i386), Java 1.5.0_10, apache-ivy-2.0.0-beta1,
Ant 1.6.5
Reporter: Vasco Lemoine
Assignee: Xavier Hanin
Priority: Minor
Fix For: 2.0-RC1
I introduced a extra attribute which I am using for building of
submodules.
foo-ivy.xml:
ivy-module version='2.0'
info organisation='foo' module='foo' revision='1' /
configurations
include file='${build_home}/etc/ivy/ivy-configurations.xml' /
/configurations
publications /
dependencies
dependency org='bar' name='bar' rev='trunk' submodule='bar' /
/dependencies
/ivy-module
bar-ivy.xml:
ivy-module version='2.0'
info organisation='bar' module='bar' revision='1' /
configurations
include file='${build_home}/etc/ivy/ivy-configurations.xml' /
/configurations
publications /
dependencies
dependency org='foobar' name='foobar' rev='1' /
/dependencies
/ivy-module
Because the submodule attribute was missing in the bar-ivy.xml info
tag. The foobar dependency gets evicted. I'm not sure this is expected
behavior. If not it is probably a bug or at least the provided
information is not clear enough to troubleshoot. Of course the work
around is adding the extra attribute to the info tag:
ivy-module version='2.0'
info organisation='bar' module='bar' revision='1' submodule='bar' /
configurations
include file='${build_home}/etc/ivy/ivy-configurations.xml' /
/configurations
publications /
dependencies
dependency org='foobar' name='foobar' rev='1' /
/dependencies
/ivy-module
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-440) Failure to transitively install Maven2 artifacts with namespace
[
https://issues.apache.org/jira/browse/IVY-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin reassigned IVY-440:
Assignee: Xavier Hanin
Failure to transitively install Maven2 artifacts with namespace
---
Key: IVY-440
URL: https://issues.apache.org/jira/browse/IVY-440
Project: Ivy
Issue Type: Bug
Components: Ant, Core
Affects Versions: 1.4.1
Reporter: easyproglife
Assignee: Xavier Hanin
Priority: Minor
Fix For: 2.0-RC1
I have Maven2 style repository with namespace elements in ivyconf.xml as in
the examples coming with ivy. The namespaces mainly deal with apache
namespace organisation/module pairs, e.g. converts
commons-logging/commons-logging to apache/commons-logging.
In normal operation the namespace conversion works fine.
The problem is in ivy:install when I request transitive='true'.
The debug log I get is:
[ivy:install] WARN: ::
[ivy:install] WARN: :: UNRESOLVED DEPENDENCIES ::
[ivy:install] WARN: ::
[ivy:install] WARN: :: [ axis | axis | 1.1 ]: inconsistent module
descriptor file found in
'/home/ivy-repository/thirdparty-maven-style/axis/axis/1.1/axis- 1.1.pom':
bad organisation: expected='axis' found='apache';
[ivy:install] WARN: ::
The POM header is:
project
modelVersion 4.0.0/modelVersion
groupIdaxis/groupId
artifactIdaxis/artifactId
version1.1/version
...
The ivyconf.xml section is:
resolvers
filesystem name=thirdparty
ivy
pattern=${ivy.thirdparty.default.root}/${ivy.thirdparty.default.ivy.pattern}
/
artifact pattern=${
ivy.thirdparty.default.root}/${ivy.thirdparty.default.artifact.pattern} /
/filesystem
filesystem name=thirdparty-maven m2compatible=yes
namespace=ibiblio-maven2
ivy
pattern=${ivy.thirdparty-maven.default.root}/${ivy.thirdparty-maven.default.ivy.pattern}
/
artifact
pattern=${ivy.thirdparty-maven.default.root}/${ivy.thirdparty-maven.default.artifact.pattern
} /
/filesystem
/resolvers
namespaces
namespace name=ibiblio-maven2
rule!-- imported apache maven1 projects --
fromsystem
src org=apache module=.+/
dest org=$m0 module=$m0/
/fromsystem
tosystem
src org=commons-.+ module=commons-.+ /
src org=axis module=axis /
...
src org=xmlrpc module=xmlrpc /
dest org=apache module=$m0/
/tosystem
/rule
rule !-- new apache projects --
fromsystem
src org=apache /
dest org= org.apache/
/fromsystem
tosystem
src org=org.apache /
dest org=apache /
/tosystem
/rule
/namespace
/namespaces
As I understand, Ivy already translated axis/axis to apache/axis and it now
cannot understand the POM and therefore cannot define its transitive
dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-440) Failure to transitively install Maven2 artifacts with namespace
[
https://issues.apache.org/jira/browse/IVY-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-440.
--
Resolution: Fixed
I've added a unit test and fixed the bug. To be clear, I think the bug was only
in the case you want to install a set of modules from a resolver in one
namespace. Indeed, in this case the listing feature was listing the modules in
the target namespace instead of system namespace, then trying to install the
modules and leading to the message about inconsistent information found. Now if
you try to install one particular module and give the information in the target
namespace information, then you'll still have the message about inconsistency,
but I don't think this is a bug, since you're not using system coordinates as
you should.
Failure to transitively install Maven2 artifacts with namespace
---
Key: IVY-440
URL: https://issues.apache.org/jira/browse/IVY-440
Project: Ivy
Issue Type: Bug
Components: Ant, Core
Affects Versions: 1.4.1
Reporter: easyproglife
Assignee: Xavier Hanin
Priority: Minor
Fix For: 2.0-RC1
I have Maven2 style repository with namespace elements in ivyconf.xml as in
the examples coming with ivy. The namespaces mainly deal with apache
namespace organisation/module pairs, e.g. converts
commons-logging/commons-logging to apache/commons-logging.
In normal operation the namespace conversion works fine.
The problem is in ivy:install when I request transitive='true'.
The debug log I get is:
[ivy:install] WARN: ::
[ivy:install] WARN: :: UNRESOLVED DEPENDENCIES ::
[ivy:install] WARN: ::
[ivy:install] WARN: :: [ axis | axis | 1.1 ]: inconsistent module
descriptor file found in
'/home/ivy-repository/thirdparty-maven-style/axis/axis/1.1/axis- 1.1.pom':
bad organisation: expected='axis' found='apache';
[ivy:install] WARN: ::
The POM header is:
project
modelVersion 4.0.0/modelVersion
groupIdaxis/groupId
artifactIdaxis/artifactId
version1.1/version
...
The ivyconf.xml section is:
resolvers
filesystem name=thirdparty
ivy
pattern=${ivy.thirdparty.default.root}/${ivy.thirdparty.default.ivy.pattern}
/
artifact pattern=${
ivy.thirdparty.default.root}/${ivy.thirdparty.default.artifact.pattern} /
/filesystem
filesystem name=thirdparty-maven m2compatible=yes
namespace=ibiblio-maven2
ivy
pattern=${ivy.thirdparty-maven.default.root}/${ivy.thirdparty-maven.default.ivy.pattern}
/
artifact
pattern=${ivy.thirdparty-maven.default.root}/${ivy.thirdparty-maven.default.artifact.pattern
} /
/filesystem
/resolvers
namespaces
namespace name=ibiblio-maven2
rule!-- imported apache maven1 projects --
fromsystem
src org=apache module=.+/
dest org=$m0 module=$m0/
/fromsystem
tosystem
src org=commons-.+ module=commons-.+ /
src org=axis module=axis /
...
src org=xmlrpc module=xmlrpc /
dest org=apache module=$m0/
/tosystem
/rule
rule !-- new apache projects --
fromsystem
src org=apache /
dest org= org.apache/
/fromsystem
tosystem
src org=org.apache /
dest org=apache /
/tosystem
/rule
/namespace
/namespaces
As I understand, Ivy already translated axis/axis to apache/axis and it now
cannot understand the POM and therefore cannot define its transitive
dependencies.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-708) Circular Dependency messages in a resolve do not reflect the configuration used during the resolve
[ https://issues.apache.org/jira/browse/IVY-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin reassigned IVY-708: Assignee: Xavier Hanin Circular Dependency messages in a resolve do not reflect the configuration used during the resolve -- Key: IVY-708 URL: https://issues.apache.org/jira/browse/IVY-708 Project: Ivy Issue Type: Bug Components: Core Affects Versions: 2.0.0-beta-1 Environment: unix Reporter: Jim Adams Assignee: Xavier Hanin Fix For: 2.0-RC1 We have a dependency chain that has several configurations. We use compile and runtime configurations. We have no circular dependencies in the compile configuration but we do in the runtime configuration. During the resolve with the compile configuration we are getting circular dependency warnings which, when examined, follow the runtime configuration. It looks like the method CollectionOfModulesToSort.getModuleDesciptorDependency() does not look at the configuration. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-675) Wrong graph of nodes is logged when circular dependency is detected
[
https://issues.apache.org/jira/browse/IVY-675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625730#action_12625730
]
Xavier Hanin commented on IVY-675:
--
I've try to review the code handling circular dependencies, double checked our
current unit tests on circular dependency management, but I don't see how this
can happen. I guess you don't have access to the environment in which you got
this error, so I'm not sure we will be able to reproduce it, if it still exists
in current trunk in which callers management has changed since beta1. So,
Maarten, any objection if we resolve this issue as cannot reproduce?
Wrong graph of nodes is logged when circular dependency is detected
---
Key: IVY-675
URL: https://issues.apache.org/jira/browse/IVY-675
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-beta-1
Reporter: Maarten Coene
Fix For: 2.0-RC1
I have a circular dependency. The nodes causing the loop are logged. However,
the information logged is incorrect.
For instance:
{code}
[ivy:resolve] :: problems summary ::
[ivy:resolve] ERRORS
[ivy:resolve]
LCMT#commons;2.8.4-LCMB#sparadmwebservice;1.0.3-LCMT#parameter
manager;3.2.1-...
[ivy:resolve]
[ivy:resolve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS
BUILD FAILED
C:\working\repository\commons\lcm\ant_build\targets\common-targets-1.0.0.xml:390
: impossible to resolve dependencies:
org.apache.ivy.plugins.circular.CircularDependencyException:
LCMT#common
s;2.8.4-LCMB#sparadmwebservice;1.0.3-LCMT#parametermanager;3.2.1-...
{code}
Howver, my commons-2.8.4 module doesn't has a dependency on sparadmwebservice:
{code}
?xml version=1.0 encoding=UTF-8?
ivy-module version=1.0
info organisation=LCMT module=commons revision=2.8.4
status=release publication=20070313105450/
configurations
conf name=default description=For default usage./
conf name=j2ee extends=default description=For usage
inside an application server./
conf name=standalone extends=default description=For
usage in a standalone application (e.g. batch)./
conf name=compile extends=*(public) visibility=private
transitive=false/
conf name=test visibility=private transitive=false/
conf name=runtest extends=test,compile
visibility=private/
conf name=minimal extends=default description=For minimal
usage, e.g. in the client API of a system./
/configurations
dependencies
defaultconfmapping=runtest-standalone(default);default,compile,test-default;standalone-[org=LCMB]client(default),[org!=LCMB]standalone(default);%-#(default);
confmappingoverride=true
!-- J2EE dependencies --
dependency org=J2EE name=ejb rev= conf=compile/
dependency org=J2EE name=jms rev= conf=standalone/
dependency org=J2EE name=jta rev= conf=test/
!-- technical dependencies --
dependency org=LCMT name=daohelper rev=1.+
conf=j2ee;standalone/
dependency org=LCMT name=openutm rev=2.+ conf=compile/
dependency org=LCMT name=parametermanager rev=3.+ conf=j2ee/
dependency org=OTHER name=commons-beanutils rev=1.7.0
conf=compile/
dependency org=OTHER name=commons-discovery rev=0.2
conf=j2ee;standalone/
dependency org=OTHER name=commons-logging rev=1.0.3
conf=default/
dependency org=OTHER name=commons-lang rev=2.0.0
conf=default/
dependency org=OTHER name=commons-validator rev=1.1.4
conf=j2ee;standalone/
dependency org=OTHER name=jakarta-regexp rev=1.4
conf=default/
!-- Test dependencies --
dependency org=LCMT name=commons-test rev=1.+ conf=test
exclude module=commons/
/dependency
dependency org=OTHER name=junit rev=3.8.1 conf=test/
dependency org=OTHER name=mockejb rev=0.5 conf=test/
dependency org=OTHER name=mockobjects rev=0.09 conf=test/
dependency org=OTHER name=dbunit rev=2.1.0 conf=test/
dependency org=OTHER name=ojdbc rev=9.2.0.5 conf=test/
/dependencies
/ivy-module
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-886) Ivy#listTokenValues(String, Map) does not filter returned values, and does not use maven-metadata.xml files with IBiblio resolver
Ivy#listTokenValues(String, Map) does not filter returned values, and does not use maven-metadata.xml files with IBiblio resolver - Key: IVY-886 URL: https://issues.apache.org/jira/browse/IVY-886 Project: Ivy Issue Type: Bug Components: Core, Maven Compatibility Reporter: Xavier Hanin Assignee: Xavier Hanin Fix For: 2.0-RC1 Currently the implementation of Ivy#listTokenValues(String, Map) does not filter returned values, and does not use maven-metadata.xml files with IBiblio resolver, while other listing methods do. This method is used in IvyDE for code completion, and as such is buggy and does not benefit from maven-metadata.xml file handling. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-115) Resolve all open ivy projects/classpath-containers found in the workspace
[ https://issues.apache.org/jira/browse/IVYDE-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12625265#action_12625265 ] Xavier Hanin commented on IVYDE-115: I think it already exists: there is a resolve all action, available through a button in the toolbar, with Ivy logo and yellow refresh arrows. Any problem with it, or did you simply miss it? Resolve all open ivy projects/classpath-containers found in the workspace - Key: IVYDE-115 URL: https://issues.apache.org/jira/browse/IVYDE-115 Project: IvyDE Issue Type: New Feature Components: classpath container Affects Versions: 2.0.0.alpha1 Reporter: Barry Kaplan For teams that work with a lot of projects (myself of course) its a real pain to have to click on every project to ensure the dependencies are resolved. Some type of global action that scans the workspace and does a resolve for all projects would be a big help. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-707) Deliver delivers the wrong version when a dynamic revision is evicted before being resolved
[ https://issues.apache.org/jira/browse/IVY-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin reassigned IVY-707: Assignee: Xavier Hanin Deliver delivers the wrong version when a dynamic revision is evicted before being resolved --- Key: IVY-707 URL: https://issues.apache.org/jira/browse/IVY-707 Project: Ivy Issue Type: Bug Affects Versions: 2.0.0-beta-1 Environment: Unix Reporter: Jim Adams Assignee: Xavier Hanin Fix For: 2.0-RC1 Attachments: testIvy.zip I have 3 modules A, B, and C. C-B-A. These are in the repo with version 1.0.0. I then have an ivy.xml for the module test which has dependencies of A(latest.integration), C(latest.integration) and B(latest.integration) in that order. Order seems to change the outcome. During the resolve I see messages when resolving each of the modules that seems incorrect but that may only be a symptom of the real problem. A resolves to a version, C resolves and brings in B. B resolves A again but instead of listing the version number in the repo for A it lists latest.integration. In this case that will return the correct version but it seems wrong to see latest.integration and not 1.0.0. In any case the resolve finishes and we deliver the ivy.xml file and publish it. What gets published includes a list of dependencies that includes latest.integration for the resolved version. This is clearly wrong and is causing us lots of pain in our environment. If we move to latest-revision as the conflict manager then the problem goes away. Here are the 3 ivy files from the repo: ?xml version=1.0 encoding=UTF-8? ivy-module version=1.3 info organisation=SAS module=a revision=1.0.0.aaa_a status=integration publication=20080117045213/ configurations conf name=compile/ /configurations publications/ dependencies /dependencies /ivy-module ?xml version=1.0 encoding=UTF-8? ivy-module version=1.3 info organisation=SAS module=b revision=1.0.0.bbb_b status=integration publication=20080117045213/ configurations conf name=compile/ /configurations publications/ dependencies dependency name=a rev=1.0.0.aaa_a org=SAS conf=compile/ /dependencies /ivy-module ?xml version=1.0 encoding=UTF-8? ivy-module version=1.3 info organisation=SAS module=c revision=1.0.0.ccc_c status=integration publication=20080117045213/ configurations conf name=compile/ /configurations publications/ dependencies dependency name=b rev=1.0.0.bbb_b org=SAS conf=compile/ /dependencies /ivy-module Here is the source ivy.xml file: ?xml version='1.0' encoding='UTF-8'? ivy-module version='1.3' info status='integration' module='test' organisation='SAS' ivyauthor name='SAS Build Technologies Team' url='http://bt.unx.sas.com'/ descriptionPlease describe sas.svc.sec.login here./description /info configurations conf name='compile'/ !--conf name='runtime'-- /configurations publications /publications dependencies dependency name='a' rev='latest.integration' org='SAS' conf='compile'/ dependency name='c' rev='latest.integration' org='SAS' conf='compile'/ dependency name='b' rev='latest.integration' org='SAS' conf='compile'/ /dependencies /ivy-module and here is the published ivy file ?xml version=1.0 encoding=UTF-8? ivy-module version=1.3 info organisation=SAS module=test revision=20080117162421 status=integration publication=20080117162421 ivyauthor name=SAS Build Technologies Team url=http://bt.unx.sas.com/ descriptionPlease describe sas.svc.sec.login here./description /info configurations conf name=compile/ !--conf name='runtime'-- /configurations publications /publications dependencies dependency name=a rev=1.0.0.aaa_a org=SAS conf=compile/ dependency name=c rev=1.0.0.ccc_c org=SAS conf=compile/ dependency name=b rev=latest.integration org=SAS conf=compile/ /dependencies /ivy-module Here is the resolve portion of the log: [ivy:resolve] parameter found as ivy variable: ivy.configurations=* [ivy:resolve] parameter found as ivy variable: ivy.resolve.default.type.filter=* [ivy:resolve] using ivy parser to parse file:/sasusr/u/sasjaa/testIvy/ivy.xml [ivy:resolve] post 1.3 ivy file: using exact as default matcher [ivy:resolve] :: resolving dependencies :: SAS#test;[EMAIL PROTECTED] [ivy:resolve] confs: [compile] [ivy:resolve] validate = true [ivy:resolve] resolving dependencies for configuration 'compile' [ivy:resolve] == resolving dependencies for SAS#test;[EMAIL PROTECTED] [compile] [ivy:resolve] loadData of SAS#test;[EMAIL PROTECTED] of rootConf=compile
[jira] Resolved: (IVY-707) Deliver delivers the wrong version when a dynamic revision is evicted before being resolved
[ https://issues.apache.org/jira/browse/IVY-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin resolved IVY-707. -- Resolution: Fixed I've fixed this as I suggested: now direct dynamic dependencies are always resolved, so deliver can do its job properly for any dependency, whatever the order of dependencies is. Deliver delivers the wrong version when a dynamic revision is evicted before being resolved --- Key: IVY-707 URL: https://issues.apache.org/jira/browse/IVY-707 Project: Ivy Issue Type: Bug Affects Versions: 2.0.0-beta-1 Environment: Unix Reporter: Jim Adams Assignee: Xavier Hanin Fix For: 2.0-RC1 Attachments: testIvy.zip I have 3 modules A, B, and C. C-B-A. These are in the repo with version 1.0.0. I then have an ivy.xml for the module test which has dependencies of A(latest.integration), C(latest.integration) and B(latest.integration) in that order. Order seems to change the outcome. During the resolve I see messages when resolving each of the modules that seems incorrect but that may only be a symptom of the real problem. A resolves to a version, C resolves and brings in B. B resolves A again but instead of listing the version number in the repo for A it lists latest.integration. In this case that will return the correct version but it seems wrong to see latest.integration and not 1.0.0. In any case the resolve finishes and we deliver the ivy.xml file and publish it. What gets published includes a list of dependencies that includes latest.integration for the resolved version. This is clearly wrong and is causing us lots of pain in our environment. If we move to latest-revision as the conflict manager then the problem goes away. Here are the 3 ivy files from the repo: ?xml version=1.0 encoding=UTF-8? ivy-module version=1.3 info organisation=SAS module=a revision=1.0.0.aaa_a status=integration publication=20080117045213/ configurations conf name=compile/ /configurations publications/ dependencies /dependencies /ivy-module ?xml version=1.0 encoding=UTF-8? ivy-module version=1.3 info organisation=SAS module=b revision=1.0.0.bbb_b status=integration publication=20080117045213/ configurations conf name=compile/ /configurations publications/ dependencies dependency name=a rev=1.0.0.aaa_a org=SAS conf=compile/ /dependencies /ivy-module ?xml version=1.0 encoding=UTF-8? ivy-module version=1.3 info organisation=SAS module=c revision=1.0.0.ccc_c status=integration publication=20080117045213/ configurations conf name=compile/ /configurations publications/ dependencies dependency name=b rev=1.0.0.bbb_b org=SAS conf=compile/ /dependencies /ivy-module Here is the source ivy.xml file: ?xml version='1.0' encoding='UTF-8'? ivy-module version='1.3' info status='integration' module='test' organisation='SAS' ivyauthor name='SAS Build Technologies Team' url='http://bt.unx.sas.com'/ descriptionPlease describe sas.svc.sec.login here./description /info configurations conf name='compile'/ !--conf name='runtime'-- /configurations publications /publications dependencies dependency name='a' rev='latest.integration' org='SAS' conf='compile'/ dependency name='c' rev='latest.integration' org='SAS' conf='compile'/ dependency name='b' rev='latest.integration' org='SAS' conf='compile'/ /dependencies /ivy-module and here is the published ivy file ?xml version=1.0 encoding=UTF-8? ivy-module version=1.3 info organisation=SAS module=test revision=20080117162421 status=integration publication=20080117162421 ivyauthor name=SAS Build Technologies Team url=http://bt.unx.sas.com/ descriptionPlease describe sas.svc.sec.login here./description /info configurations conf name=compile/ !--conf name='runtime'-- /configurations publications /publications dependencies dependency name=a rev=1.0.0.aaa_a org=SAS conf=compile/ dependency name=c rev=1.0.0.ccc_c org=SAS conf=compile/ dependency name=b rev=latest.integration org=SAS conf=compile/ /dependencies /ivy-module Here is the resolve portion of the log: [ivy:resolve] parameter found as ivy variable: ivy.configurations=* [ivy:resolve] parameter found as ivy variable: ivy.resolve.default.type.filter=* [ivy:resolve] using ivy parser to parse file:/sasusr/u/sasjaa/testIvy/ivy.xml [ivy:resolve] post 1.3 ivy file: using exact as default matcher [ivy:resolve] :: resolving dependencies :: SAS#test;[EMAIL PROTECTED] [ivy:resolve] confs: [compile] [ivy:resolve] validate = true [ivy:resolve] resolving dependencies for configuration
[jira] Commented: (IVY-885) Invalid URL when using dynamic ranges
[
https://issues.apache.org/jira/browse/IVY-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12624663#action_12624663
]
Xavier Hanin commented on IVY-885:
--
You can bypass the attempt to reach the bad URL by setting
alwaysCheckExactRevision=false on your resolver. BTW, I think this should be
the default in 2.0, since I guess very few people actually use the litteral
requested revision when it's dynamic.
Invalid URL when using dynamic ranges
-
Key: IVY-885
URL: https://issues.apache.org/jira/browse/IVY-885
Project: Ivy
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-beta-1
Reporter: Jim Bonanno
Sorry to have two url issues in one day.
We are using ivy's ranges to resolve our modules. Ivy first tries to see if
the specified version exists before listing the repository. The issue that we
hit was when using the range [1,2[. The first request is
http://myhost/my-repo/org/module/ivys/ivy-[1,2[.xml.
This URL is not properly escaped, but apache apparently is very forgiving.
When we hosted the ivy repository with another web server that validated the
urls the returned status code was not a 404.
We are working around the problem by again using URI to build the URL so it
gets properly escaped. There seems to be some tricks to using the URI class.
For example, the constructor that takes a string requires the string is
already rfc 2396 compliant. The other constructors will actually escape the
URL.
Here is the modifications we made to the BasicURLHandler.
if ( url.getProtocol() == http || url.getProtocol() == https) {
try {
URI uri = new URI(url.getProtocol(), null, url.getHost(),
url.getPort(), url.getPath(), null, null);
url = uri.toURL();
}
catch ( URISyntaxException e ) {
IOException ioe = new IOException(Couldn't open connection
to ' + url.toString() + ');
ioe.initCause(e);
throw ioe;
}
}
con = url.openConnection();
which results in a request
http://myhost/my-repo/org/module/ivys/ivy-%5B1,2%5B.xml.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-677) ivy:publish ignores error when ant runs with -quiet
[
https://issues.apache.org/jira/browse/IVY-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-677.
--
Resolution: Fixed
I've tried to reproduce this bug on my ubuntu box without success:
{code}
[EMAIL PROTECTED]:~/tmp/ivy/test-local$ ant -quiet publish
BUILD FAILED
/home/xavier/tmp/ivy/test-local/build.xml:10: impossible to publish artifacts
for test#test-local;[EMAIL PROTECTED]: java.io.IOException: file copy not done
from /home/xavier/tmp/ivy/test-local/distrib/ivys/ivy-20080822174447.xml to
/home/xavier/tmp/ivy/test-local/local/test-local/ivy.xml: destination already
exists and overwrite is false
Total time: 1 second
[EMAIL PROTECTED]:~/tmp/ivy/test-local$ echo $?
1
{code}
I've done this test with a build from svn trunk made last july. So I guess we
can consider this problem as fixed. Feel free to reopen if you still have the
same problem with trunk version.
ivy:publish ignores error when ant runs with -quiet
-
Key: IVY-677
URL: https://issues.apache.org/jira/browse/IVY-677
Project: Ivy
Issue Type: Bug
Components: Ant
Affects Versions: 2.0.0-beta-1
Environment: Linux, JDK 1.4.2
Reporter: Henning Schmiedehausen
Fix For: 2.0-RC1
I deploy artifacts into a repository using ivy:publish ... overwrite=false.
When running a regular build using ant and I have already deployed an
artifact, it reports correctly
[ivy:publish] publish aborted: deleted /home/henning/
BUILD FAILED
... impossible to publish artifacts for myorg#mymodule;version:
java.io.IOException: file copy not done from xxx to yyy: destination probably
exists and overwrite is false.
and echo $? (return code from ant) is 1.
When I run ant -quiet:
BUILD SUCCESSFUL
and echo $? returns 0.
Looks bad to me. If my build is not able to publish an artifact because I
disallowed overwrite, this IMHO is a build failure and should not be ignored
when running quiet.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (IVY-667) Inconsistency with multi-project tutorial
[
https://issues.apache.org/jira/browse/IVY-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Xavier Hanin resolved IVY-667.
--
Resolution: Fixed
I've fixed the problem following your suggestion. Thanks for reporting the
problem!
Inconsistency with multi-project tutorial
---
Key: IVY-667
URL: https://issues.apache.org/jira/browse/IVY-667
Project: Ivy
Issue Type: Bug
Components: Documentation
Reporter: Phillip Rhodes
Assignee: Xavier Hanin
Priority: Minor
Fix For: 2.0-RC1
I've noticed what seems to be a discrepancy with the
multi-project tutorial. If I do a publish-local in one of
the projects (say, sizewhere the place where the artifacts
are published looks like this:
multi-project/repository/local/org.apache.ivy.example/sizewhere
note that the organisation is part of the path that gets created.
But, in the common.xml, in the clean-local task, the delete
doesn't specify the organisation as part of the path, so nothing
is ever deleted on a clean-local (since the actual path that it's
trying to delete doesn't exist):
target name=clean-local description=-- cleans the local repository
for the current module
delete dir=${ivy.local.default.root}/${ant.project.name}/
/target
I modified my copy of common.xml as follows and this seems to work. Not
sure if this was what was intended to be in the tutorial or not, but
this works:
target name=clean-local description=-- cleans the local repository
for the current module
ivy:info file=${basedir}/ivy.xml /
delete
dir=${ivy.local.default.root}/${ivy.organisation}/${ant.project.name}/
/target
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-349) Endless recursion in Report
[ https://issues.apache.org/jira/browse/IVY-349?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12624892#action_12624892 ] Xavier Hanin commented on IVY-349: -- I've tested the attached xml report, processed it with the trunk xsl using firefox, and had no problem. What is strange is that the xsl hasn't changed much since 2.0 beta 1, so maybe Nascif your reproduced the problem in another case or environment? Could you let me know if you are able to reproduce the problem with trunk version? And then provide details on your environment, and the report causing problem? Endless recursion in Report --- Key: IVY-349 URL: https://issues.apache.org/jira/browse/IVY-349 Project: Ivy Issue Type: Bug Affects Versions: 1.4.1 Environment: W2kpro, jdk1.5.0_06 Reporter: Jan Koops Priority: Minor Fix For: 2.0-RC1 Attachments: tkeasy-app-zahnersatz-binaries.xml Endless recursion while generating report via XSLT -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-50) IvyDE does not honor useOrigin
[ https://issues.apache.org/jira/browse/IVYDE-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623300#action_12623300 ] Xavier Hanin commented on IVYDE-50: --- I think this has been fixed with the new management of useOrigin in Ivy itself, and the new cache architecture. So I think we can mark this issue as resolved now that you have done some tests. IvyDE does not honor useOrigin -- Key: IVYDE-50 URL: https://issues.apache.org/jira/browse/IVYDE-50 Project: IvyDE Issue Type: Improvement Environment: Any Reporter: Eric Crahen Builds run from IvyDE do not honor the useOrigin tag. This results in custom resolvers who purposely keep artifacts _out_ of the cache from failing to do so correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-37) Add option to use the useOrigin-feature from Ivy
[ https://issues.apache.org/jira/browse/IVYDE-37?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623301#action_12623301 ] Xavier Hanin commented on IVYDE-37: --- At the time this issue was created, it wasn't possible to change this in the settings. Now that the useOrigin mode is configured for each cache, I think it doesn't make sense any more to provide this option in IvyDE. Add option to use the useOrigin-feature from Ivy -- Key: IVYDE-37 URL: https://issues.apache.org/jira/browse/IVYDE-37 Project: IvyDE Issue Type: Improvement Components: classpath container Affects Versions: 1.1.0 Reporter: Maarten Coene Assignee: Xavier Hanin The performance of the resolve could be drastically improved if ivyDE would use the useOrigin functionality of Ivy when doing a resolve. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVYDE-78) Add errors marker to the Ivy container
[ https://issues.apache.org/jira/browse/IVYDE-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12623302#action_12623302 ] Xavier Hanin commented on IVYDE-78: --- Excellent! Add errors marker to the Ivy container -- Key: IVYDE-78 URL: https://issues.apache.org/jira/browse/IVYDE-78 Project: IvyDE Issue Type: Improvement Components: classpath container Affects Versions: 2.0.0.alpha1 Reporter: Nicolas Lalevée Assignee: Nicolas Lalevée Priority: Minor Fix For: 2.0 It should be nice to use Eclipse error markers to show that the last resolution on the Ivy container failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-232) Incorrect directory path resolve when running from a different directory
[
https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620536#action_12620536
]
Xavier Hanin commented on IVY-232:
--
So Adrian, if you are so unhappy, provide a patch to fix this. When you say
that using absolute paths is unacceptable for you, you don't explain why. All
you need is add ${basedir}/ at the beginning of all the paths. I believe that
if this isn't fixed yet, it's because everybody realized that it was faster to
do this than to implement the fix and provide a patch.
Incorrect directory path resolve when running from a different directory
Key: IVY-232
URL: https://issues.apache.org/jira/browse/IVY-232
Project: Ivy
Issue Type: Bug
Components: Ant
Affects Versions: 1.3-RC2
Environment: Windows 2000 (probably Unix also. Didn't check that)
Reporter: easyproglife
Assignee: Gilles Scokart
Fix For: 2.0-RC1
Suppose you have two projects in two directories:
/projA
/projB
Each one of them have its own build.xml.
When you run Ant on /projA/build.xml from /projA evrything is ok.
When you run from /projB ant -f ..\projA\build.xml relative pathes are
based on projB by Ivy, whereas the correct way (as Ant and Maven works) is
to use projA as the base directory (assuming /projA/build.xml has
basedir attribute: .)
In other words, Ivy should take the base directory as specified in the
build.xml file in project tag in basedir attribute, and calculate it
based on the location of the build.xml file; not based on the current
directory where Ant was invoced from.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-232) Incorrect directory path resolve when running from a different directory
[ https://issues.apache.org/jira/browse/IVY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620544#action_12620544 ] Xavier Hanin commented on IVY-232: -- Fixing this is not complex, it's only time consuming to go through all the code to make sure we don't forget any single case. And when I talk about absolute paths, I'm actually talking about paths relative to a directory which has an absolute path, like path relative to basedir or settings dir. For a first reference to this trick, see [this comment|https://issues.apache.org/jira/browse/IVY-232?focusedCommentId=12453138#action_12453138] Incorrect directory path resolve when running from a different directory Key: IVY-232 URL: https://issues.apache.org/jira/browse/IVY-232 Project: Ivy Issue Type: Bug Components: Ant Affects Versions: 1.3-RC2 Environment: Windows 2000 (probably Unix also. Didn't check that) Reporter: easyproglife Assignee: Gilles Scokart Fix For: 2.0-RC1 Suppose you have two projects in two directories: /projA /projB Each one of them have its own build.xml. When you run Ant on /projA/build.xml from /projA evrything is ok. When you run from /projB ant -f ..\projA\build.xml relative pathes are based on projB by Ivy, whereas the correct way (as Ant and Maven works) is to use projA as the base directory (assuming /projA/build.xml has basedir attribute: .) In other words, Ivy should take the base directory as specified in the build.xml file in project tag in basedir attribute, and calculate it based on the location of the build.xml file; not based on the current directory where Ant was invoced from. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (IVY-869) Bootstrapping ivy instruction
[
https://issues.apache.org/jira/browse/IVY-869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619630#action_12619630
]
Xavier Hanin commented on IVY-869:
--
I think we already have similar instructions here:
http://ant.apache.org/ivy/history/latest-milestone/install.html
Is there sg to add or update?
Bootstrapping ivy instruction
-
Key: IVY-869
URL: https://issues.apache.org/jira/browse/IVY-869
Project: Ivy
Issue Type: Improvement
Affects Versions: 2.0.0-beta-2
Reporter: Stepan Koltsov
I use following code to bootstrap ivy:
{code}
available property=ivy.available file=lib/ivy/ivy-2.0.0-beta2.jar/
target name=download-ivy unless=ivy.available
mkdir dir=lib/ivy/
echoDownloading ivy/echo
get
src=http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.0.0-beta2/ivy-2.0.0-beta2.jar;
dest=lib/ivy/ivy-2.0.0-beta2.jar/
/target
target name=resolve depends=download-ivy
taskdef resource=org/apache/ivy/ant/antlib.xml
uri=antlib:org.apache.ivy.ant
classpath
fileset dir=lib/ivy includes=*.jar/
/classpath
/taskdef
ivy:retrieve
pattern=lib/dep/[organisation]-[artifact]-[revision].[ext] sync=true/
/target
{code}
This should be possibly included into the documentation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (IVY-871) test and document PatternVersionMatcher
test and document PatternVersionMatcher
---
Key: IVY-871
URL: https://issues.apache.org/jira/browse/IVY-871
Project: Ivy
Issue Type: Improvement
Components: Core
Reporter: Xavier Hanin
There is a powerful version matcher in Ivy code base called
PatternVersionMatcher. Unfortunately, this matcher is not documented, not
tested, and not declared in the default typedef.properties. Nobody remembers
where it comes from, but code analysis should be enough to understand how it
works and what it can achieve.
Here's what I understand from a quick analysis:
{code:title=settings.xml}
pattern-vm
match revision=micro pattern=${major}\.${minor}\.\d+ args=major, minor
matcher=regexp /
/pattern-vm
{code}
{code:title=ivy.xml}
dependency org=acme name=foo rev=micro(1, 3) /
{code}
If I understand correctly the code, this will match any revision like 1.3.any
number.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (IVY-803) Cache can't distinguish artifacts with classifiers
[ https://issues.apache.org/jira/browse/IVY-803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xavier Hanin reassigned IVY-803: Assignee: Xavier Hanin Cache can't distinguish artifacts with classifiers -- Key: IVY-803 URL: https://issues.apache.org/jira/browse/IVY-803 Project: Ivy Issue Type: Bug Components: Maven Compatibility Affects Versions: 2.0.0-beta-2 Reporter: James P. White Assignee: Xavier Hanin Attachments: ivy803patch.txt Once an artifact with a Maven classifier is in the cache, then that will match any classifier value. Presumably the fix is to include the classifier in the artifact pattern for the cache. But this seems a little obnoxious since AFAICT this problem may exist with all artifact patterns. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
