ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée (JIRA) <>
Subject [jira] Commented: (IVYDE-187) Allow workspace resolver to skip version matcher
Date Sun, 13 Sep 2009 12:37:58 GMT


Nicolas Lalevée commented on IVYDE-187:

@Jeffrey: the workaround I was talking about what on the ant side. If you have some $version
in you ivy.xml, it means that you do some processing in ant in order to properly publish you
ivy.xml, right? So the workaround would be to use the ivy ant task to do that job and not
specify any revision in you ivy.xml.
Then about the buildlist ant task. I dig a little bit into its code and did some tests. The
buildlist task is not ignoring the revisions. And actually if there some missmatch between
the revision, there are some warnings (which are displayed only with the -v option... weird...).
So for me the workspace resolver works today like the buildlist task do (with the fix IVYDE-186).
The point here is that in your use case there is a revision specified in your ivy.xml: $version.
And you obviously want to make IvyDE ignore it. But you should know that the buildlist task
doesn't ignore it. It maybe be a coincidence it orders it correctly.

Here is an exemple of the current behaviour with missmatched revision:
* project 1: rev=${version}
* project 2: rev=${version} , depends on project 1 rev=1.2
* project 3: rev= , depends on project 2 rev=1.4

The result for a buildlist with root="p3":
[ivy:buildlist] WARN: Non matching revision detected when sorting.  com.acme#p2 depends on
com.acme#p1;1.2, doesn't match com.acme#p1;${version}
[ivy:buildlist] WARN: Non matching revision detected when sorting.  com.acme#p3 depends on
com.acme#p2;1.4, doesn't match com.acme#p2;${version}
[echo] buildlist result: /Users/hibou/dev/ivy/tmp/p2/build.xml:/Users/hibou/dev/ivy/tmp/p1/build.xml:/Users/hibou/dev/ivy/tmp/p3/build.xml

@Matt: well, it may be a solution, but as Ivy is a dependency manager, we should use it to
resolve our dependency issues :)

@Jon: I think that the behaviour you are expecting of IvyDE is already working, with the fix
IVYDE-186. Here is what should be working:
|| A dependency on B || B declared revision || result ||
| latest.integration | 1.2 | B wired on A |
| 1.2 | 1.2 | B wired on A |
| [1.2,1.3) | 1.2 | B wired on A |
| 1.0 | 1.2 | no project wiring |
| latest.integration | _none_ | B wired on A |
| 1.2 | _none_ | B wired on A |
| [1.2,1.3) | _none_ | B wired on A |
| latest.integration | $version | no project wiring |
| 1.2 | $version | no project wiring |
| [1.2,1.3) | $version | no project wiring |

So as far as I understand the use case your presented, IvyDE should work correctly. So only
issue is about the $version.

> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>                 Key: IVYDE-187
>                 URL:
>             Project: IvyDE
>          Issue Type: Improvement
>          Components: workspace resolver
>    Affects Versions:
>            Reporter: Phillip Webb
>         Attachments: ivyde-workspaceignoreversion.patch
> The workspace resolver version matcher sometimes gets in the way.  I would like to suggest
an option that will allow a workspace project to be used when the organization and module
ID match, regardless of the version.  
> The DocComment on WorkspaceResolver seems to imply that this was the original intent:
>   * Since the resolver is not aware which module revision a project is publishing, it
>   * matches any revision of the module.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message