[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-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=12636552#action_12636552 ] Maarten Coene commented on IVY-931: --- Maybe we should throw an error if the parent pom couldn't be located? 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=12636551#action_12636551 ] Maarten Coene commented on IVY-933: --- I don't think that will be enough, if the version is different, maven2 will use the version definied in the filename, not in the POM. I think Ivy will always use the version from the POM? And maybe we should see what maven does when groupId and artifactId is also inconsistent in this case? 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-925) ivy:settings doesn't work if id is a property
[
https://issues.apache.org/jira/browse/IVY-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12636571#action_12636571
]
Jean-Louis Boudart commented on IVY-925:
It works with trunk head revision
Thanks maarten
ivy:settings doesn't work if id is a property
-
Key: IVY-925
URL: https://issues.apache.org/jira/browse/IVY-925
Project: Ivy
Issue Type: Bug
Components: Ant
Affects Versions: 2.0-RC1
Reporter: Jean-Louis Boudart
Assignee: Maarten Coene
Priority: Minor
Fix For: trunk
Attachments: test-ivyInstance.tar.gz
It seems that using ivy;settings or ivy:configure task when you havn't
initialized ivy.instance property doesn't work
Here is my ivy:configure
{noformat}
ivy:configure settingsId=ivy.instance.project
file=${common.dir}/ivysettings.xml /
{noformat}
I'm using my own ivysettings.properties instead of the one given by ivy. My
ivysettings.properties doesn't contains ivy.instance property.
Here is part of my ivysettings.xml
{noformat}
ivysettings
properties file=${common.dir}/ivysettings.properties
override=false/
...
/ivysettings
{noformat}
And running this in debug mode i can see Skipped because property
'ivy.instance' not set.
Consequences are, when i'm trying to use any ivy task that use this instance,
i have a build failed with a message like Reference ivy.instance.project not
found.
Exemple try to use ivy:resolve
{noformat}
ivy:resolve file=${ivy.file} useCacheOnly=${ivy.use.cache.only}
settingsRef=ivy.instance.project/
{noformat}
The result is :
{noformat}
BUILD FAILED
/home/neoverflow/work/sg/sogera-git/common/common.xml:124: Reference
ivy.instance.project not found.
at
org.apache.tools.ant.types.Reference.getReferencedObject(Reference.java:115)
at org.apache.ivy.ant.IvyTask.getIvyInstance(IvyTask.java:76)
at org.apache.ivy.ant.IvyTask.prepareTask(IvyTask.java:256)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:276)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:288)
at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:105)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:357)
at org.apache.tools.ant.Target.performTasks(Target.java:385)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1329)
at org.apache.tools.ant.Project.executeTarget(Project.java:1298)
at
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1181)
at org.apache.tools.ant.Main.runBuild(Main.java:698)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:257)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)
{noformat}
Adding this property to my own ivysettings.properties, everything seems ok.
I think that when you give an settingsId (in ivy:configure) or an id in
(ivy:instance) you doesn't need to use ivy.instance property.
--
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-934) ivy:buildnumber Task can cause ivy:resolve to 'hang' forever
ivy:buildnumber Task can cause ivy:resolve to 'hang' forever
Key: IVY-934
URL: https://issues.apache.org/jira/browse/IVY-934
Project: Ivy
Issue Type: Bug
Affects Versions: 2.0-RC1
Environment: fedora-core 9, jdk1.6..11, ant 1.7.0
Reporter: Hans Lund
if the ivy:buildnumber ant task fails (when a module has not been published
-yet ) later ivy:resolve ant tasks that do not have an explicit revision hangs
forever.
preconditions: resolving over http to single repository.
Steps to reproduce:
ivy.xml with some dependencies like:
dependencies
dependency org=junit name=junit rev=3.8.2 conf=test-default/
dependency org=org.mortbay.jetty name=jetty rev=6.+
conf=default-default /
/dependencies
buildfile with:
target name=ivy-buildnumber-resolve-bug depends=init-ivy
ivy:buildnumber organisation=org.bug
module=bug /
ivy:resolve /
ivy:retrieve sync=true pattern=${ivy.lib.dir}/[artifact].[ext]/
/target
target name=resolve-dependencies depends=init-ivy
ivy:resolve /
ivy:retrieve sync=true pattern=${ivy.lib.dir}/[artifact].[ext]/
/target
now ant - verbose ivy-buildnumber-resolve-bug gives to following stacktrace:
[ivy:resolve] using ivy parser to parse file:/home/halu/IvyBug/ivy.xml
[ivy:resolve] :: resolving dependencies :: org.bug#ivybuildnumberbug;[EMAIL
PROTECTED]
[ivy:resolve] confs: [default, master, compile, provided, runtime, test,
system, optional]
[ivy:resolve] validate = true
[ivy:resolve] refresh = false
[ivy:resolve] resolving dependencies for configuration 'default'
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [default]
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [runtime]
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [compile]
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [master]
[ivy:resolve] == resolving dependencies org.bug#ivybuildnumberbug;[EMAIL
PROTECTED]org.mortbay.jetty#jetty;6.+ [default-default]
[ivy:resolve] : Checking cache for: dependency: org.mortbay.jetty#jetty;6.+
{default=[default]}
[ivy:resolve] no cached resolved revision for org.mortbay.jetty#jetty;6.+
[ivy:resolve] no cached resolved revision for org.mortbay.jetty#jetty;6.+
[ivy:resolve] tried
http://localhost/repository/org.mortbay.jetty/jetty/ivys/ivy-[revision].xml
freeze ... ctrl+c
C[ivy:resolve] WARN: problem while listing resources in
http://localhost/repository/org.mortbay.jetty/jetty/ivys with local-repo:
[ivy:resolve] WARN: java.lang.IllegalStateException Connection factory has
been shutdown.
[ivy:resolve] tried
http://localhost/repository/org.mortbay.jetty/jetty/jars/jetty-[revision].jar
[ivy:resolve] WARN: problem while listing resources in
http://hudson.msrd.multi-support.com/repository/org.mortbay.jetty/jetty/jars
with local-repo:
[ivy:resolve] WARN: java.lang.IllegalStateException Connection factory has
been shutdown.
[ivy:resolve] Multisupport-IvyRepository: no ivy file nor artifact found for
org.mortbay.jetty#jetty;6.+
[ivy:resolve] WARN: module not found: org.mortbay.jetty#jetty;6.+
[ivy:resolve] WARN: local-repo: tried
[ivy:resolve] WARN:
http://localhost/repository/org.mortbay.jetty/jetty/ivys/ivy-[revision].xml
[ivy:resolve] WARN: -- artifact org.mortbay.jetty#jetty;6.+!jetty.jar:
[ivy:resolve] WARN:
http://localhost/repository/org.mortbay.jetty/jetty/jars/jetty-[revision].jar
[ivy:resolve] resolving dependencies for configuration 'master'
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [master]
[ivy:resolve] resolving dependencies for configuration 'compile'
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [compile]
[ivy:resolve] resolving dependencies for configuration 'provided'
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [provided]
[ivy:resolve] resolving dependencies for configuration 'runtime'
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [runtime]
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [compile]
[ivy:resolve] resolving dependencies for configuration 'test'
[ivy:resolve] == resolving dependencies for org.bug#ivybuildnumberbug;[EMAIL
PROTECTED] [test]
[ivy:resolve] == resolving dependencies org.bug#ivybuildnumberbug;[EMAIL
PROTECTED]junit#junit;3.8.2 [test-default]
[ivy:resolve] : Checking cache for: dependency: junit#junit;3.8.2
{test=[default]}
--
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=12636756#action_12636756 ] Maarten Coene commented on IVY-933: --- ok, I'll check which version Ivy will take... If it does trust the dependency declaration, I'll set the checkconsistency property to false by default on the ibiblio resolver as you suggested. Ok? 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=12636758#action_12636758 ] Maarten Coene commented on IVY-931: --- Maybe we should behave the same as maven does in this situation. So the question is: how does maven behave when the parent pom cannot be found? 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.
