[
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.
