You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Phillip Webb (JIRA)" <ji...@apache.org> on 2009/07/07 10:14:16 UTC
[jira] Created: (IVYDE-187) Allow workspace resolver to skip
version matcher
Allow workspace resolver to skip version matcher
------------------------------------------------
Key: IVYDE-187
URL: https://issues.apache.org/jira/browse/IVYDE-187
Project: IvyDE
Issue Type: Improvement
Components: workspace resolver
Affects Versions: 2.0.0.final
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 optimistically
* 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.
[jira] Commented: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Nicolas Lalevée (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12754684#action_12754684 ]
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":
{noformat}
[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
{noformat}
@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: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Issue Comment Edited: (IVYDE-187) Allow workspace resolver
to skip version matcher
Posted by "Jon Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753596#action_12753596 ]
Jon Schneider edited comment on IVYDE-187 at 9/10/09 5:51 AM:
--------------------------------------------------------------
Nicolas,
I do believe we should make this have a project level override. But in general, I think a typical developer would assume that if project A depends on B, both A and B are in the workspace, and both open, then B's code is being used. I can imagine a developer, not seeing the difference in revision being confused as to why a breakpoint in B is not getting hit. Now in general, I think Ivy is intended to be used like this:
1. the info element in an ivy file has a status of "integration", no revision attribute, and no publication date until an artifact is actually published to the repository
2. if A depends on B, in general the revision dependency will be latest.integration until publish time.
At least that is the assumption that IvyDE is making right now. The real trouble comes into play with fix branches themselves. Say A and B each have revisions 1.0.final and 1.1.1. Now development on the main branch along the previously described lines works with IvyDE today. When we adjust our version control snapshot to point at 1.0.final all the code is reverted to 1.0.final. In my workspace latest.integration (which was the same revision I was using when I was doing 1.0.x coding) resolves to the project reference. What happens when we close project B in the workspace? A resolve is performed and latest.integration pulls in the 1.1.1 B jar. Now the 1.0.final A project has a 1.1.1 B dependency. This behavior is unacceptable.
The only way I can see around it is to change the B dependency revision in A to 1.0.+ while I am coding 1.0.x code and then after 1.0.final is built, change the dependency to 1.1.+ . But even though 1.1.+ = latest.integration in this context, IvyDE does not interpret the dependency as a project reference. This is also unacceptable.
With the default behavior of ignoring revisions, when we revert to 1.0.final the project reference is pulled in because the revision is ignored anyway. And when we close B, 1.0.+ resolves to 1.0.final and the 1.0.final A code correctly depends on 1.0.final B jar from the repository.
Your further input is welcome.
Thanks!
was (Author: jkschneider):
Nicolas,
I do believe we should make this have a project level override. But in general, I think a typical developer would assume that if project A depends on B, both A and B are in the workspace, and both open, then B's code is being used. I can imagine a developer, not seeing the difference in revision being confused as to why a breakpoint in B is not getting hit. Now in general, I think Ivy is intended to be used like this:
1. the info element in an ivy file has a status of "integration", no revision attribute, and no publication date until an artifact is actually published to the repository
2. if A depends on B, in general the revision dependency will be latest.integration until publish time.
At least that is the assumption that IvyDE is making right now. The real trouble comes into play with fix branches themselves. Say A and B each have revisions 1.0.final and 1.1.1. Now development on the main branch along the previously described lines works with IvyDE today. When we adjust our version control snapshot to point at 1.0.final all the code is reverted to 1.0.final. In my workspace latest.integration (which was the same revision I was using when I was doing 1.0.x coding) resolves to the project reference. What happens when we close project B in the workspace? A resolve is performed and latest.integration pulls in the 1.1.1 B jar. Now the 1.0.final A project has a 1.1.1 B dependency. This behavior is unacceptable.
The only way I can see around it is to change the B dependency revision in A to 1.0.+ while I am coding 1.0.x code and then after 1.0.final is built, change the dependency to 1.1.+. But even though 1.1.+ = latest.integration in this context, IvyDE does not interpret the dependency as a project reference. This is also unacceptable.
With the default behavior of ignoring revisions, when we revert to 1.0.final the project reference is pulled in because the revision is ignored anyway. And when we close B, 1.0.+ resolves to 1.0.final and the 1.0.final A code correctly depends on 1.0.final B jar from the repository.
Your further input is welcome.
Thanks!
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Commented: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Jon Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753596#action_12753596 ]
Jon Schneider commented on IVYDE-187:
-------------------------------------
Nicolas,
I do believe we should make this have a project level override. But in general, I think a typical developer would assume that if project A depends on B and both A and B are in the workspace and both open, then B's code is being used. I can see a developer, not seeing the difference in revision being confused as to why a breakpoint in B is not getting hit. Now in general, I think Ivy is intended to be used like this:
1. the info element in an ivy file has a status of "integration", no revision attribute, and no publication date until an artifact is actually published to the repository
2. if A depends on B, in general the revision dependency will be latest.integration until publish time.
At least that is the assumption that IvyDE is making right now. The real trouble comes into play with fix branches themselves. Say A and B each have revisions 1.0.final and 1.1.1. Now development on the main branch along the previously described lines works with IvyDE today. But when we adjust our version control snapshot to point at 1.0.final all the code is reverted. In my workspace latest.integration resolves to the project reference. What happens when we close project B in the workspace? A resolve is performed and latest.integration pulls in the 1.1.1 B jar. This behavior is unacceptable.
The only way I can see around it is to change the B dependency revision in A to 1.0.+ and then when 1.0.final is built, change the dependency to 1.1.+. But even though 1.1.+ = latest.integration in this context, IvyDE does not interpret the dependency as a project reference. This is also unacceptable.
Your further input is welcome.
Thanks!
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Commented: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Nicolas Lalevée (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750874#action_12750874 ]
Nicolas Lalevée commented on IVYDE-187:
---------------------------------------
does this issue related to IVYDE-187 ? What is your use case that don't work with the current implementation ?
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Commented: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Phillip Webb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750907#action_12750907 ]
Phillip Webb commented on IVYDE-187:
------------------------------------
I think the problem was that I do not assign version numbers to projects until the build process. I think that most of my ivy files had ${version} variables. I also seem to recall that this related to transitive dependencies in the workspace and using latest.integration as the dependency version. To be honest this was a little while ago and I have forgotten the exact cause of the problem, but I do remember stepping though the plug-in and this was the only option that I could find to fix my issue.
I also think that it is quite a useful addition. |My guess is that it is a fairly common use case to only have one project inside eclipse for a given dependency. Not having to worry about version numbers makes life easier, especially as a failure on the resolve is sometimes hard to track down.
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Commented: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Nicolas Lalevée (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750991#action_12750991 ]
Nicolas Lalevée commented on IVYDE-187:
---------------------------------------
Effectively with some ${version} it doesn't work.
And about use cases, sometimes I have to open an old version of a project (usualy a bug fix in the branch), so this can be quite error prone or painfull to make IvyDE ignore project's versions, as the new option you suggest is global to the workspace. So I think that this option might be harmful, but you use case is perfectly valid. I think I will probably integrate your patch and add a warning about its use in the global preference page.
Note that as a workaround, Ivy can set the published version: see the use of the attribute pubrevision in the [deliver|http://ant.apache.org/ivy/history/latest-milestone/use/deliver.html] ant task
But you might then hit IVYDE-186
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Commented: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Jeffrey Sinclair (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753238#action_12753238 ]
Jeffrey Sinclair commented on IVYDE-187:
----------------------------------------
Nicolas, I don't understand your workaround because I'm under the impression that IvyDE uses the source Ivy file which is never run through the delivery mechanism when resolving in Eclipse. I agree with Jon that this is a critical improvement to IvyDE that needs to be addressed. My view is that out of the box, the workspace resolver should behave like the built-in 'buildlist' Ivy Ant task which will ignore the rev attribute in dependency resolution if the module descriptor for that dependency is in the build list without a revision specified.
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Commented: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Matt Goldspink (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753549#action_12753549 ]
Matt Goldspink commented on IVYDE-187:
--------------------------------------
I understand the concern about having 2 projects in your workspace for different revisions of the same project, but could that not also be solved with a dialog box from IvyDE when hits this case. It should only pop that up if there is no version match and multiple projects are found. I know popping up dailog boxes isn't everyone's cup of tea, so maybe the way to deal with revisions in the workspace resolver is to offer 3 choices when dealing with this situation:
1) fail fast
2) open a selection dialog box with the choices
3) always choose the first match (not sure if this is the best approach, but at least it will keep things working in the workspace and people don't have to be hassled with a dialog box)
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Resolved: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Nicolas Lalevée (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nicolas Lalevée resolved IVYDE-187.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.1.0
Assignee: Nicolas Lalevée
patched applied. I added a warning about its use.
Thanks for the patch Phillip Webb.
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> Reporter: Phillip Webb
> Assignee: Nicolas Lalevée
> Fix For: 2.1.0
>
> 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 optimistically
> * 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.
[jira] Commented: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Jon Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12750624#action_12750624 ]
Jon Schneider commented on IVYDE-187:
-------------------------------------
If I remember correctly, we depend on the publish task to assign the revision id to a module descriptor. I see this patch as a critical improvement.
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Issue Comment Edited: (IVYDE-187) Allow workspace resolver
to skip version matcher
Posted by "Jon Schneider (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753596#action_12753596 ]
Jon Schneider edited comment on IVYDE-187 at 9/10/09 5:48 AM:
--------------------------------------------------------------
Nicolas,
I do believe we should make this have a project level override. But in general, I think a typical developer would assume that if project A depends on B, both A and B are in the workspace, and both open, then B's code is being used. I can imagine a developer, not seeing the difference in revision being confused as to why a breakpoint in B is not getting hit. Now in general, I think Ivy is intended to be used like this:
1. the info element in an ivy file has a status of "integration", no revision attribute, and no publication date until an artifact is actually published to the repository
2. if A depends on B, in general the revision dependency will be latest.integration until publish time.
At least that is the assumption that IvyDE is making right now. The real trouble comes into play with fix branches themselves. Say A and B each have revisions 1.0.final and 1.1.1. Now development on the main branch along the previously described lines works with IvyDE today. When we adjust our version control snapshot to point at 1.0.final all the code is reverted to 1.0.final. In my workspace latest.integration (which was the same revision I was using when I was doing 1.0.x coding) resolves to the project reference. What happens when we close project B in the workspace? A resolve is performed and latest.integration pulls in the 1.1.1 B jar. Now the 1.0.final A project has a 1.1.1 B dependency. This behavior is unacceptable.
The only way I can see around it is to change the B dependency revision in A to 1.0.+ while I am coding 1.0.x code and then after 1.0.final is built, change the dependency to 1.1.+. But even though 1.1.+ = latest.integration in this context, IvyDE does not interpret the dependency as a project reference. This is also unacceptable.
With the default behavior of ignoring revisions, when we revert to 1.0.final the project reference is pulled in because the revision is ignored anyway. And when we close B, 1.0.+ resolves to 1.0.final and the 1.0.final A code correctly depends on 1.0.final B jar from the repository.
Your further input is welcome.
Thanks!
was (Author: jkschneider):
Nicolas,
I do believe we should make this have a project level override. But in general, I think a typical developer would assume that if project A depends on B and both A and B are in the workspace and both open, then B's code is being used. I can see a developer, not seeing the difference in revision being confused as to why a breakpoint in B is not getting hit. Now in general, I think Ivy is intended to be used like this:
1. the info element in an ivy file has a status of "integration", no revision attribute, and no publication date until an artifact is actually published to the repository
2. if A depends on B, in general the revision dependency will be latest.integration until publish time.
At least that is the assumption that IvyDE is making right now. The real trouble comes into play with fix branches themselves. Say A and B each have revisions 1.0.final and 1.1.1. Now development on the main branch along the previously described lines works with IvyDE today. But when we adjust our version control snapshot to point at 1.0.final all the code is reverted. In my workspace latest.integration resolves to the project reference. What happens when we close project B in the workspace? A resolve is performed and latest.integration pulls in the 1.1.1 B jar. This behavior is unacceptable.
The only way I can see around it is to change the B dependency revision in A to 1.0.+ and then when 1.0.final is built, change the dependency to 1.1.+. But even though 1.1.+ = latest.integration in this context, IvyDE does not interpret the dependency as a project reference. This is also unacceptable.
Your further input is welcome.
Thanks!
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.
[jira] Updated: (IVYDE-187) Allow workspace resolver to skip
version matcher
Posted by "Phillip Webb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/IVYDE-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Phillip Webb updated IVYDE-187:
-------------------------------
Attachment: ivyde-workspaceignoreversion.patch
Attached a patch
> Allow workspace resolver to skip version matcher
> ------------------------------------------------
>
> Key: IVYDE-187
> URL: https://issues.apache.org/jira/browse/IVYDE-187
> Project: IvyDE
> Issue Type: Improvement
> Components: workspace resolver
> Affects Versions: 2.0.0.final
> 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 optimistically
> * 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.