ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lucas Lech (JIRA)" <j...@apache.org>
Subject [jira] Issue Comment Edited: (IVY-1120) IvyBuildNumber non-deterministic behaviour
Date Fri, 11 Sep 2009 08:55:58 GMT

    [ https://issues.apache.org/jira/browse/IVY-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12753852#action_12753852
] 

Lucas Lech edited comment on IVY-1120 at 9/11/09 1:54 AM:
----------------------------------------------------------

I've been running two parallel debugging sessions - the ant task that was invoking *ivy:buildnumber*
was in first session executed directly and in another one it was executed as dependency of
some other task (somewhere down the line of dependency graph) - few other ivy tasks, like
ivy:publish have been executed before

so in both sessions *ivy:buildnumber* has been fed with exactly the same attributes

session invoking the ivy:buildnumber "directly" got the exact matcher while the one invoking
it indirectly got the regexp one\\
on both occasions _expression_ was equal to _organisation_ string-wise; in second session
it wasn't equal address-wise though

clearly the comparison in the matcher is broken (unless you're purposely comparing address
values and I'm missing something here)
after replacing == with .equals & rebuilding ivy, this task started working properly

what's the reason for comparing references (ref) ant not values (*ref) ?


      was (Author: gibffe):
    I've been running two parallel debugging sessions - the ant task that was invoking *ivy:buildnumber*
was in first session executed directly and in another one it was executed as dependency of
some other task (somewhere down the line of dependency graph) - few other ivy tasks, like
ivy:publish have been executed before

so in both sessions *ivy:buildnumber* has been fed with exactly the same attributes

session invoking the ivy:buildnumber "directly" got the exact matcher while the one invoking
it indirectly got the regexp one\\
on both occasions _expression_ was equal to _organisation_ string-wise; in second session
it wasn't equal address-wise though

clearly the comparison in the matcher is broken (unless you're purposely comparing address
values and I'm missing here)
after replacing == with .equals & rebuilding ivy, this task started working properly

what's the reason for comparing references (ref) ant not values (*ref) ?

  
> IvyBuildNumber non-deterministic behaviour
> ------------------------------------------
>
>                 Key: IVY-1120
>                 URL: https://issues.apache.org/jira/browse/IVY-1120
>             Project: Ivy
>          Issue Type: Bug
>          Components: Ant
>    Affects Versions: 2.1.0-RC2
>         Environment: ant 1.7.1,  windows xp
>            Reporter: Lucas Lech
>
> IvyBuildNumber.java -> doExecute()
> creates an inline patternMatcher with this method:
> {code:title=IvyBuildNumber.java|borderStyle=solid}
> public Matcher getMatcher(String expression) {
>                 if ((expression == organisation)
>                         || (expression == module)
>                         || (expression == branch)) {
>                     return exact.getMatcher(expression);
>                 }
>                 return regexp.getMatcher(expression);
>             }
> {code}
> I'm guessing the == comparison is a typo ? Shouldn't it be saying *.equals* ?
> I've been having issues with this task - non-deterministic results - I got down in my
debug to this place where I get wrong matcher when 
> *reference address comparison* fails.

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


Mime
View raw message