You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@ant.apache.org by "Dan Diodati (JIRA)" <ji...@apache.org> on 2010/01/07 22:15:08 UTC
[jira] Updated: (IVY-1157) buildnumber does not work when there is
a dependency referenced by the same ivy file.
[ https://issues.apache.org/jira/browse/IVY-1157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dan Diodati updated IVY-1157:
-----------------------------
Description:
I ran into a case where I resolve one ivy file that references a artifact called tools. Then later I try to get a new build number of the tools artifact and it acts as if it does not exist and starts at 1.
This seems to occur because in the IvyBuildNumber it uses a ModuleId object which does some caching of the module information and then does object comparisions in the getMatcher method.
In my case the String object ends up changing and so it thinks there is not an existing artifact giving me the 1.0 version instead of the correct one.
I have some test build to simulate the problem and would attach it if I could. You can ping me and I can send it to you.
Note the second output will be: [echo] tool current revision is: working@sfdanmac.local; new revision is: 1.0
Since there is a tools artifact with 1.1.0 it should return a result of 1.2 and not 1.0.
I found the fix was to modify the IvyBuildNumber to do String comparisons using the equals operator instead of the ==. Here is the diff that fixes the issue:
{noformat}
Index: src/java/org/apache/ivy/ant/IvyBuildNumber.java
===================================================================
--- src/java/org/apache/ivy/ant/IvyBuildNumber.java (revision 888715)
+++ src/java/org/apache/ivy/ant/IvyBuildNumber.java (working copy)
@@ -165,9 +165,9 @@
private PatternMatcher regexp = new ExactOrRegexpPatternMatcher();
public Matcher getMatcher(String expression) {
- if ((expression == organisation)
- || (expression == module)
- || (expression == branch)) {
+ if ((expression.equals(organisation))
+ || (expression.equals(module))
+ || (expression.equals(branch))) {
return exact.getMatcher(expression);
}
return regexp.getMatcher(expression);
{noformat}
was:
I ran into a case where I resolve one ivy file that references a artifact called tools. Then later I try to get a new build number of the tools artifact and it acts as if it does not exist and starts at 1.
This seems to occur because in the IvyBuildNumber it uses a ModuleId object which does some caching of the module information and then does object comparisions in the getMatcher method.
In my case the String object ends up changing and so it thinks there is not an existing artifact giving me the 1.0 version instead of the correct one.
I have some test build to simulate the problem and would attach it if I could. You can ping me and I can send it to you.
Note the second output will be: [echo] tool current revision is: working@sfdanmac.local; new revision is: 1.0
Since there is a tools artifact with 1.1.0 it should return a result of 1.2 and not 1.0.
I found the fix was to modify the IvyBuildNumber to do String comparisons using the equals operator instead of the ==. Here is the diff that fixes the issue:
Index: src/java/org/apache/ivy/ant/IvyBuildNumber.java
===================================================================
--- src/java/org/apache/ivy/ant/IvyBuildNumber.java (revision 888715)
+++ src/java/org/apache/ivy/ant/IvyBuildNumber.java (working copy)
@@ -165,9 +165,9 @@
private PatternMatcher regexp = new ExactOrRegexpPatternMatcher();
public Matcher getMatcher(String expression) {
- if ((expression == organisation)
- || (expression == module)
- || (expression == branch)) {
+ if ((expression.equals(organisation))
+ || (expression.equals(module))
+ || (expression.equals(branch))) {
return exact.getMatcher(expression);
}
return regexp.getMatcher(expression);
> buildnumber does not work when there is a dependency referenced by the same ivy file.
> -------------------------------------------------------------------------------------
>
> Key: IVY-1157
> URL: https://issues.apache.org/jira/browse/IVY-1157
> Project: Ivy
> Issue Type: Bug
> Components: Ant
> Affects Versions: 2.1.0
> Environment: MacOSX, IVY 2.1.0
> Reporter: Dan Diodati
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I ran into a case where I resolve one ivy file that references a artifact called tools. Then later I try to get a new build number of the tools artifact and it acts as if it does not exist and starts at 1.
> This seems to occur because in the IvyBuildNumber it uses a ModuleId object which does some caching of the module information and then does object comparisions in the getMatcher method.
> In my case the String object ends up changing and so it thinks there is not an existing artifact giving me the 1.0 version instead of the correct one.
> I have some test build to simulate the problem and would attach it if I could. You can ping me and I can send it to you.
> Note the second output will be: [echo] tool current revision is: working@sfdanmac.local; new revision is: 1.0
> Since there is a tools artifact with 1.1.0 it should return a result of 1.2 and not 1.0.
> I found the fix was to modify the IvyBuildNumber to do String comparisons using the equals operator instead of the ==. Here is the diff that fixes the issue:
> {noformat}
> Index: src/java/org/apache/ivy/ant/IvyBuildNumber.java
> ===================================================================
> --- src/java/org/apache/ivy/ant/IvyBuildNumber.java (revision 888715)
> +++ src/java/org/apache/ivy/ant/IvyBuildNumber.java (working copy)
> @@ -165,9 +165,9 @@
> private PatternMatcher regexp = new ExactOrRegexpPatternMatcher();
>
> public Matcher getMatcher(String expression) {
> - if ((expression == organisation)
> - || (expression == module)
> - || (expression == branch)) {
> + if ((expression.equals(organisation))
> + || (expression.equals(module))
> + || (expression.equals(branch))) {
> return exact.getMatcher(expression);
> }
> return regexp.getMatcher(expression);
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.