http://nagoya.apache.org/bugzilla/show_bug.cgi?id=2584
*** shadow/2584 Wed Jul 11 11:57:59 2001 --- shadow/2584.tmp.17498 Wed Jul 11 23:10:52 2001 *************** *** 2,9 **** | target if attribute doesn't understand multiple properties | +----------------------------------------------------------------------------+ | Bug #: 2584 Product: Ant | ! | Status: NEW Version: 1.3 | ! | Resolution: Platform: All | | Severity: Enhancement OS/Version: Other | | Priority: Other Component: Core | +----------------------------------------------------------------------------+ --- 2,9 ---- | target if attribute doesn't understand multiple properties | +----------------------------------------------------------------------------+ | Bug #: 2584 Product: Ant | ! | Status: RESOLVED Version: 1.3 | ! | Resolution: WONTFIX Platform: All | | Severity: Enhancement OS/Version: Other | | Priority: Other Component: Core | +----------------------------------------------------------------------------+ *************** *** 11,17 **** | Reported By: [EMAIL PROTECTED] | | CC list: Cc: | +----------------------------------------------------------------------------+ ! | URL: http://http:// | +============================================================================+ | DESCRIPTION | It would be nice to have a dependency on multiple properties, something like --- 11,17 ---- | Reported By: [EMAIL PROTECTED] | | CC list: Cc: | +----------------------------------------------------------------------------+ ! | URL: | +============================================================================+ | DESCRIPTION | It would be nice to have a dependency on multiple properties, something like *************** *** 43,46 **** "JMXRI.present,JMXTOOLS.present" is taken literally as a property name. The fix is simple, question is: has this issue been brought up before and ! rejected or implemented in one of the branches? If not, I can submit the patch. --- 43,74 ---- "JMXRI.present,JMXTOOLS.present" is taken literally as a property name. The fix is simple, question is: has this issue been brought up before and ! rejected or implemented in one of the branches? If not, I can submit the patch. ! ! ------- Additional Comments From [EMAIL PROTECTED] 2001-07-11 23:10 ------- ! Yes, it has been requested and declined more than once, hust search the mailing ! list archives. ! ! There are several reasons to not do it - at least not the way you describe it. ! One of the biggest reasons IMHO is that using comma as a separator is highly ! ambiguous - do you want to AND or to OR the two existance of the two properties? ! In your case, AND is the answer, but there are several valid use-cases for OR. ! Using || and && would be too Java/C centric for easy build files and would sure ! lead us down a road where target and include and .... have to support the whole ! slew of operators scripting languages support (you'll sure need test for ! in/equality, comaparisons, set membership ...) - if not you, someone else is ! going to request it. ! ! What we have projected for Ant2 is a <condition> task and it may very well be ! available in the Ant1 series - view this as "available-enhanced", you would do ! something like ! ! <condition property="jmx.supported"> ! <and> ! <available class="javax.management.loading.DefaultLoaderRepository" /> ! <available class="com.sun.jdmk.comm.Enumerated" /> ! </and> ! </condition> ! ! which moves the logic into a single task or the custom conditions that can ! be children of that task.
