Re: Artima SuiteRunner Task
On Wed, 26 Mar 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Do we have a real-world candidate for antlib resource=.. classpathref=.. / ant-contrib's cpptasks, this includes custom tasks and types. Stefan
Re: Artima SuiteRunner Task
Costin Manolache wrote: I would include filters, mappers, conditions and selectors to the list. I would exclude them :-) Taks, types, mappers, filters, whatever are just ant components - and they shouldn't need a special syntax from user perspective. That is what I meant to say. We shouldn't treat them ( or types, tasks ) as special - just plain components that happen to perform different functions in the build file. agreed.. A relatively simple mod to the core ant makes this possible (bugzilla 17199) basically get ConditionBase.java, AbstractFileSet, FilterChain implement DynamicConfigurator. and get UnknownElement (bugzilla 18312) call setProject earlier on created children. Mappers are a little different, I implemented a new attribute to handle this. That's a possible solution, I'll take a look ( in few weeks unfortunately..., hopefully this will be resolved by than by others :-). From the point of view of the reader ( assuming we go with the SAX2 ProjectHelperImpl ) - it really doesn't matter what the component does. The only problem in the current code is the TaskAdapter - which doesn't know about types and other components, and tries to wrap everything. This does not seem to matter (if use is made of dynconfigurator). The only change I had to do was to get UnknownElement to call setProject on created objects. (my original mod to TaskAdapter was not sufficient) Peter.
Re: Artima SuiteRunner Task
Stefan Bodewig wrote: On Wed, 26 Mar 2003, Nicola Ken Barozzi [EMAIL PROTECTED] wrote: Do we have a real-world candidate for antlib resource=.. classpathref=.. / ant-contrib's cpptasks, this includes custom tasks and types. though in that particular example, it'd be nice if the types were also accessible to the .net tasks, that have their own concepts of libraries and definitions
Artima SuiteRunner Task
Hi All, (Please forgive my newbie-ness). I have developed an Ant Task for the Artima SuiteRunner and I'd like to submit it. Perhaps a Committer might a respond directly and I'll e-mail them a zip file containing the code? (Didn't want to send a zip file to a few hundred people...!) Thanks, Adam Duffy Crypto Group Computer Science Dept NUI Maynooth
RE: Artima SuiteRunner Task
Hi, Myself and Leigh Ishikawa (Adding 'setName' support to the xmljunitresultformatter.java) have not received any response to our contributions. Can someone please advise? Cheers, Adam -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: 26 March 2003 11:09 To: Ant Developers List Subject: Artima SuiteRunner Task Hi All, (Please forgive my newbie-ness). I have developed an Ant Task for the Artima SuiteRunner and I'd like to submit it. Perhaps a Committer might a respond directly and I'll e-mail them a zip file containing the code? (Didn't want to send a zip file to a few hundred people...!) Thanks, Adam Duffy Crypto Group Computer Science Dept NUI Maynooth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Artima SuiteRunner Task
Could someone please explain me what SuiteRunner brings to the table that JUnit doesn't I've looked at it quite a bit, and maybe beside better reporting, I don't see anything compelling about it compared to JUnit, and even loose the built-in assert methods of TestCase (thru Assert)... I'd be interested in knowing what other see in it. Thanks, --DD -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 5:09 AM To: Ant Developers List Subject: Artima SuiteRunner Task Hi All, (Please forgive my newbie-ness). I have developed an Ant Task for the Artima SuiteRunner and I'd like to submit it. Perhaps a Committer might a respond directly and I'll e-mail them a zip file containing the code? (Didn't want to send a zip file to a few hundred people...!) Thanks, Adam Duffy Crypto Group Computer Science Dept NUI Maynooth
RE: Artima SuiteRunner Task
Hi Dominique, I would like to know what other people think too. If at the end of the day, the developers of Ant do not wish to use the code I have written, that is fine with me. I only want to contribute to the development of Ant - which I am really fond of. As does Leigh Ishikawa. Any advice on that matter? Thanks, Adam -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: 26 March 2003 15:20 To: 'Ant Developers List' Subject: RE: Artima SuiteRunner Task Could someone please explain me what SuiteRunner brings to the table that JUnit doesn't I've looked at it quite a bit, and maybe beside better reporting, I don't see anything compelling about it compared to JUnit, and even loose the built-in assert methods of TestCase (thru Assert)... I'd be interested in knowing what other see in it. Thanks, --DD -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 5:09 AM To: Ant Developers List Subject: Artima SuiteRunner Task Hi All, (Please forgive my newbie-ness). I have developed an Ant Task for the Artima SuiteRunner and I'd like to submit it. Perhaps a Committer might a respond directly and I'll e-mail them a zip file containing the code? (Didn't want to send a zip file to a few hundred people...!) Thanks, Adam Duffy Crypto Group Computer Science Dept NUI Maynooth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Artima SuiteRunner Task
Thanks Dominique, I wasn't aware of that policy regarding 'external' tasks (since I only started subscribing recently). I'll ask Artima.com to see if their interested. :) Thanks again, Adam -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: 26 March 2003 15:37 To: 'Ant Developers List' Subject: RE: Artima SuiteRunner Task Sorry, I didn't mean at all to put down your contribution. I was more asking an off topic question about SuiteRunner. My personal opinion on SuiteRunner is not binding in any way the Ant community at large, or the committers ;-) As a note, past comments indicate that Task should ideally live within the tool they Ant-enable (and depend on), so your contribution maybe should also be made (or instead) to the Artima.com SuiteRunner community. --DD -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 9:36 AM To: Ant Developers List Subject: RE: Artima SuiteRunner Task Hi Dominique, I would like to know what other people think too. If at the end of the day, the developers of Ant do not wish to use the code I have written, that is fine with me. I only want to contribute to the development of Ant - which I am really fond of. As does Leigh Ishikawa. Any advice on that matter? Thanks, Adam -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: 26 March 2003 15:20 To: 'Ant Developers List' Subject: RE: Artima SuiteRunner Task Could someone please explain me what SuiteRunner brings to the table that JUnit doesn't I've looked at it quite a bit, and maybe beside better reporting, I don't see anything compelling about it compared to JUnit, and even loose the built-in assert methods of TestCase (thru Assert)... I'd be interested in knowing what other see in it. Thanks, --DD -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 5:09 AM To: Ant Developers List Subject: Artima SuiteRunner Task Hi All, (Please forgive my newbie-ness). I have developed an Ant Task for the Artima SuiteRunner and I'd like to submit it. Perhaps a Committer might a respond directly and I'll e-mail them a zip file containing the code? (Didn't want to send a zip file to a few hundred people...!) Thanks, Adam Duffy Crypto Group Computer Science Dept NUI Maynooth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Artima SuiteRunner Task
On Wed, 26 Mar 2003, Adam Duffy [EMAIL PROTECTED] wrote: Myself and Leigh Ishikawa (Adding 'setName' support to the xmljunitresultformatter.java) have not received any response to our contributions. Can someone please advise? First advice would be to be more patient, four hours isn't that much 8-) Looking into contributions is something that takes time and all of us here are volunteers. It is not unusual to get no response for days, and I'll admit that occasionally there will be no response at all. In your case, I have no idea what Artima SuiteRunner is, so a contribution that focusses on it will not catch my attention. It will go into a queue of mails and I'll hope that another committer - somebody who knows what you are talking about ;-) - will get to it first. Dominique's comments suggest that it is some kind of testing tool, nice. So now the more general response: For quite some time we've become very reluctant to add new tasks. Especially tasks that are tied to third party products - we generally prefer to see them outside of Ant and with this product. The reason is that Ant already contains far too many tasks that no committer can really test and support - this leaves us in a position where we are not doing any good to our users, nor to ourselves. Tasks have to be supported. If no committer is able to support it directly, we have to rely on people less tightly connected to Ant. In many cases the original authors of a task have disappeared and when we receive patches for their tasks, reviewing those patches becomes painful. Cheers Stefan
RE: Artima SuiteRunner Task
That said (by Erik and myself), if SuiteRunner becomes popular enough (like JUnit), and even though it's an 'external' task, there would be a good possibility that it could be incorporated in ant-optional.jar, simply to help and evangelize Unit Testing in general, which is a best practice. That said (one more ;-), if Ant ever comes up with an easier way to integrate third party tasks (and their dependencies) using an AntLib mechanism, maybe it would not make it to Ant, just because it would be so easy to integrate anyhow. I hope this helps, --DD -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 10:00 AM To: Ant Developers List Subject: RE: Artima SuiteRunner Task Thanks Dominique, I wasn't aware of that policy regarding 'external' tasks (since I only started subscribing recently). I'll ask Artima.com to see if their interested. :) Thanks again, Adam -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: 26 March 2003 15:37 To: 'Ant Developers List' Subject: RE: Artima SuiteRunner Task Sorry, I didn't mean at all to put down your contribution. I was more asking an off topic question about SuiteRunner. My personal opinion on SuiteRunner is not binding in any way the Ant community at large, or the committers ;-) As a note, past comments indicate that Task should ideally live within the tool they Ant-enable (and depend on), so your contribution maybe should also be made (or instead) to the Artima.com SuiteRunner community. --DD -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 9:36 AM To: Ant Developers List Subject: RE: Artima SuiteRunner Task Hi Dominique, I would like to know what other people think too. If at the end of the day, the developers of Ant do not wish to use the code I have written, that is fine with me. I only want to contribute to the development of Ant - which I am really fond of. As does Leigh Ishikawa. Any advice on that matter? Thanks, Adam -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: 26 March 2003 15:20 To: 'Ant Developers List' Subject: RE: Artima SuiteRunner Task Could someone please explain me what SuiteRunner brings to the table that JUnit doesn't I've looked at it quite a bit, and maybe beside better reporting, I don't see anything compelling about it compared to JUnit, and even loose the built-in assert methods of TestCase (thru Assert)... I'd be interested in knowing what other see in it. Thanks, --DD -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 5:09 AM To: Ant Developers List Subject: Artima SuiteRunner Task Hi All, (Please forgive my newbie-ness). I have developed an Ant Task for the Artima SuiteRunner and I'd like to submit it. Perhaps a Committer might a respond directly and I'll e-mail them a zip file containing the code? (Didn't want to send a zip file to a few hundred people...!) Thanks, Adam Duffy Crypto Group Computer Science Dept NUI Maynooth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Artima SuiteRunner Task
On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: That said (one more ;-), if Ant ever comes up with an easier way to integrate third party tasks Easier than taskdef resource=...classpath ...//taskdef? Almost impossible. Stefan
RE: Artima SuiteRunner Task
Hu, not totally. If the AntLib also uses types, you need another typedef, which should also probably needs a loaderref. Since you now use twice the classpath, if needs to be outside and refid'd. And what about the junit task? I'd like to not have setup my classpath outside of Ant and build.xml, and avoid having to dump everything in AntLib. I believe it can and should be easier and more flexible. --DD -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: Artima SuiteRunner Task On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: That said (one more ;-), if Ant ever comes up with an easier way to integrate third party tasks Easier than taskdef resource=...classpath ...//taskdef? Almost impossible. Stefan
RE: Artima SuiteRunner Task
I meant ANT_HOME/lib. --DD -Original Message- From: Dominique Devienne [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 10:37 AM To: 'Ant Developers List' Subject: RE: Artima SuiteRunner Task Hu, not totally. If the AntLib also uses types, you need another typedef, which should also probably needs a loaderref. Since you now use twice the classpath, if needs to be outside and refid'd. And what about the junit task? I'd like to not have setup my classpath outside of Ant and build.xml, and avoid having to dump everything in ANT_HOME/lib I believe it can and should be easier and more flexible. --DD -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: Artima SuiteRunner Task On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: That said (one more ;-), if Ant ever comes up with an easier way to integrate third party tasks Easier than taskdef resource=...classpath ...//taskdef? Almost impossible. Stefan
Re: Artima SuiteRunner Task
On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: Hu, not totally. Did I forget to put that smiley in? Since you now use twice the classpath, if needs to be outside and refid'd. No, you'll need to use the loaderref attribute. And what about the junit task? Easy in Ant 1.6, it comes in a jar of its own. Ant's default install will most probably need to keep it on the system classpath. This backwards compatibility thing, you know. I believe it can and should be easier and more flexible. Agreed. Stefan
RE: Artima SuiteRunner Task
Regarding suiterunner vs JUnit, I prefer the suiterunner API: test methods can throw Exceptions, also assertion failures generate Exceptions so you can put one catch(Exception) at the bottom of your method and print out any useful info before throwing the exception on, rather than separate ones for AssertionFailedError and Exception which looks very messy. Alternatively you can leave out the try/catch altogether - saves typing if you just want the stacktrace -- I Don't find the failures/exceptions distinction useful in JUnit. don't have to call super(String) - me being lazy again which tests run can be determined by a property file so if you want to run just a few tests out of a suite you don't need to recompile/comment out bits of code can also put classpath info in the property file, which seems better than adding it to your junit script or CLASSPATH flexible reporting of results - which you already mentioned - and which I haven't used... Nat Dominique Devienne To: 'Ant Developers List' [EMAIL PROTECTED] [EMAIL PROTECTED]cc: m Subject: RE: Artima SuiteRunner Task 26.03.2003 15:19 Please respond to Ant Developers List Could someone please explain me what SuiteRunner brings to the table that JUnit doesn't I've looked at it quite a bit, and maybe beside better reporting, I don't see anything compelling about it compared to JUnit, and even loose the built-in assert methods of TestCase (thru Assert)... I'd be interested in knowing what other see in it. Thanks, --DD -Original Message- From: Adam Duffy [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 5:09 AM To: Ant Developers List Subject: Artima SuiteRunner Task Hi All, (Please forgive my newbie-ness). I have developed an Ant Task for the Artima SuiteRunner and I'd like to submit it. Perhaps a Committer might a respond directly and I'll e-mail them a zip file containing the code? (Didn't want to send a zip file to a few hundred people...!) Thanks, Adam Duffy Crypto Group Computer Science Dept NUI Maynooth - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
RE: Artima SuiteRunner Task
-Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 11:55 AM To: Ant Developers List Subject: Re: Artima SuiteRunner Task snip test and batchtest in Ant support if/unless properties and I always have it set up to be able to run a single test upon demand. /snip Erik - How do you set it up to run a single test on demand? I could set a different target for each test (painful) or use a command line param with -D (less painful but no idea). Chris
RE: Artima SuiteRunner Task
I do it with one line in my build.xml:
test todir=${junit.results} name=${testcase} if=testcase/
and a small change to the batchtest task:
batchtest todir=${junit.results} unless=testcase
Both of these in are my test target, so I just run ant with
ant -Dtestcase=com.whatever.TestWhatever test
Easy! And thanks to Erik's book for the tip.
s
-Original Message-
From: Chris Reeves [mailto:[EMAIL PROTECTED]
How do you set it up to run a single test on demand?
I could set a different target for each test (painful) or use a command
line param with -D (less painful but no idea).
RE: Artima SuiteRunner Task
Ah - ok.
And proof that no matter how tattered the pages of my copy of JDWA are,
there's more gems to be found within.
Thanks!
Chris
-Original Message-
From: Steven Newton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 12:05 PM
To: Ant Developers List
Subject: RE: Artima SuiteRunner Task
I do it with one line in my build.xml:
test todir=${junit.results} name=${testcase}
if=testcase/ and a small change to the batchtest task:
batchtest todir=${junit.results} unless=testcase
Both of these in are my test target, so I just run ant with
ant -Dtestcase=com.whatever.TestWhatever test
Easy! And thanks to Erik's book for the tip.
s
-Original Message-
From: Chris Reeves [mailto:[EMAIL PROTECTED]
How do you set it up to run a single test on demand?
I could set a different target for each test (painful) or use
a command line param with -D (less painful but no idea).
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Artima SuiteRunner Task
I don't buy that. If your exception doesn't contain enough info, then modify
the exception. I never trap exception in Unit tests, unless I'm expecting it
to be thrown and fail() if it doesn't.
As far as running one of more tests, I use a
-Dtestcase=com/acme/SomeTest.class, and testcases defaultsto
**/test/*Test.class if not explicitly specified.
Like I said, I'm still trying to understand what SuiteRunner brings to the
table... I even prefer the distinction between Failures and Errors... With
JUnit 3.8.1, I even write test cases with just test methods and nothing else
(if one doesn't use setUp/tearDown).
I looked at SuiteRunner because of the talk about Conformance/API testing,
and it doesn't bring anything above JUnit at all. Like I said, I'm still
waiting to be enlightened about SuiteRunner's cons ;-) --DD
-Original Message-
From: Nathaniel Spurling [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 11:08 AM
To: Ant Developers List
Subject: Re: Artima SuiteRunner Task
On Wednesday, March 26, 2003, at 11:46 AM, Nathaniel Spurling wrote:
Regarding suiterunner vs JUnit, I prefer the suiterunner API:
test methods can throw Exceptions, also assertion failures
generate Exceptions so you can put one catch(Exception) at the bottom
of your method and print out any useful info before throwing the
exception on, rather than separate ones for AssertionFailedError and
Exception which looks very messy. Alternatively you can leave out the
try/catch altogether - saves typing if you just want the stacktrace
-- I Don't find the failures/exceptions distinction useful in JUnit.
I often simply have my JUnit testXXX throw Exception since that is
unexpected and a test failure/error. I don't quite get how SuiteRunner
is different here.
say you've got a method which goes:
testXXX() throws Exception{
//generate random data
try{
//do testing
} catch(Exception e){
//print data used
throw e;
}
}
in JUnit you need an extra catch(AssertionFailedError) clause in the event
of an assertion being untrue - not a big difference, but if all your tests
are the same format it's preferable.
--
This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Artima SuiteRunner Task
Dominique Devienne wrote: Hu, not totally. If the AntLib also uses types, you need another typedef, which should also probably needs a loaderref. Since you now use twice the classpath, if needs to be outside and refid'd. In ant1.6 the difference between tasks and types is very small. It would be trivial to load both of them at once. In any case, I don't quite agree with Stefan: the simpler solution is: path id=... / taskdef resource=.. classpathref=.. / I would love to completely remove the different treatment of types - i.e. a task is just like a type with an execute() method, and nothing else, and taskdef loades both kinds. That would be simpler than the current syntax that also require you to do a: typedef resource=... classpathref=... / Costin And what about the junit task? I'd like to not have setup my classpath outside of Ant and build.xml, and avoid having to dump everything in AntLib. I believe it can and should be easier and more flexible. --DD -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: Artima SuiteRunner Task On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: That said (one more ;-), if Ant ever comes up with an easier way to integrate third party tasks Easier than taskdef resource=...classpath ...//taskdef? Almost impossible. Stefan
Re: Artima SuiteRunner Task
Chris Reeves wrote: Ah - ok. And proof that no matter how tattered the pages of my copy of JDWA are, there's more gems to be found within. Thanks! Chris I believe that particular snippet is a near-direct cut and paste from ant's own build file. So the credit goes to whoever set up the junit task in ant's build.xml --- Actually, of all the pet peeves about junit, I have the following 1. I'd like logging integrated with ant log levels, even across processes 2 I want the notion of 'tests that fail but we dont consider showstoppers'; these are 'expected failures'. Its nice to know when these go away, and its nice to know when they fail in a different place or for a different reason from before, but I dont want the build stopping 'cos a test for a known bug is blocking everything. -steve
Re: Artima SuiteRunner Task
Costin Manolache wrote, On 26/03/2003 18.46: Dominique Devienne wrote: Hu, not totally. If the AntLib also uses types, you need another typedef, which should also probably needs a loaderref. Since you now use twice the classpath, if needs to be outside and refid'd. In ant1.6 the difference between tasks and types is very small. It would be trivial to load both of them at once. +1 It makes sense also because it's typical for tasks to need a certain typedef, and separating the declaration is simply wrong in these cases. In any case, I don't quite agree with Stefan: the simpler solution is: path id=... / taskdef resource=.. classpathref=.. / I would love to completely remove the different treatment of types - i.e. a task is just like a type with an execute() method, and nothing else, and taskdef loades both kinds. That would be simpler than the current syntax that also require you to do a: typedef resource=... classpathref=... / Do we have a real-world candidate for antlib resource=.. classpathref=.. / or antlib resource=.. / or antlib location=.. .jar/ ? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Artima SuiteRunner Task
I would include filters, mappers, conditions and selectors to the list. A relatively simple mod to the core ant makes this possible (bugzilla 17199) basically get ConditionBase.java, AbstractFileSet, FilterChain implement DynamicConfigurator. and get UnknownElement (bugzilla 18312) call setProject earlier on created children. Mappers are a little different, I implemented a new attribute to handle this. It this is done, then non ant core projects may implement their own whacky types. (like this to convert to upper case: filterchain tokenfilter scriptfilter language=beanshell self.setToken(self.getToken().toUpperCase()) /scriptfilter /tokenfilter /filterchain Peter On Wednesday 26 March 2003 17:46, Costin Manolache wrote: Dominique Devienne wrote: Hu, not totally. If the AntLib also uses types, you need another typedef, which should also probably needs a loaderref. Since you now use twice the classpath, if needs to be outside and refid'd. In ant1.6 the difference between tasks and types is very small. It would be trivial to load both of them at once. In any case, I don't quite agree with Stefan: the simpler solution is: path id=... / taskdef resource=.. classpathref=.. / I would love to completely remove the different treatment of types - i.e. a task is just like a type with an execute() method, and nothing else, and taskdef loades both kinds. That would be simpler than the current syntax that also require you to do a: typedef resource=... classpathref=... / Costin And what about the junit task? I'd like to not have setup my classpath outside of Ant and build.xml, and avoid having to dump everything in AntLib. I believe it can and should be easier and more flexible. --DD -Original Message- From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 26, 2003 10:27 AM To: [EMAIL PROTECTED] Subject: Re: Artima SuiteRunner Task On Wed, 26 Mar 2003, Dominique Devienne [EMAIL PROTECTED] wrote: That said (one more ;-), if Ant ever comes up with an easier way to integrate third party tasks Easier than taskdef resource=...classpath ...//taskdef? Almost impossible. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Artima SuiteRunner Task
peter reilly wrote: I would include filters, mappers, conditions and selectors to the list. I would exclude them :-) Taks, types, mappers, filters, whatever are just ant components - and they shouldn't need a special syntax from user perspective. We shouldn't treat them ( or types, tasks ) as special - just plain components that happen to perform different functions in the build file. A relatively simple mod to the core ant makes this possible (bugzilla 17199) basically get ConditionBase.java, AbstractFileSet, FilterChain implement DynamicConfigurator. and get UnknownElement (bugzilla 18312) call setProject earlier on created children. Mappers are a little different, I implemented a new attribute to handle this. That's a possible solution, I'll take a look ( in few weeks unfortunately..., hopefully this will be resolved by than by others :-).
Ant extension points (was RE: Artima SuiteRunner Task)
0 || atLeast atMost || atMost == 0) {
throw new IllegalArgumentException(Invalid min/max: +
atLeast + '/' + atMost);
}
if (requiredTypes != null requiredTypes.length 0) {
_types = Arrays.asList(requiredTypes);
}
_atLeast = atLeast;
_atMost = atMost;
}
// Implements DynamicConfigurator#setDynamicAttribute
public void setDynamicAttribute(String name, String value)
throws BuildException {
throw new BuildException(Unknown attribute: + name);
}
// Implements DynamicConfigurator#createDynamicElement
public Object createDynamicElement(String name)
throws BuildException {
return new MyUnknownElement(name);
}
/**
* Gets the instantiated bean/type/task at the given.
*
* @param index the index requested.
* @throws IndexOutOfBoundsException if no tags were instantiated;
* or the given codeindex/code is invalid.
*/
public Object getTag(int index) {
if (_tags == null) {
throw new IndexOutOfBoundsException(no tags);
}
assert _tags.size() = _atLeast;
assert _tags.size() = _atMost;
return _tags.get(index);
}
/**
* Gets all the tags instantiated within this dynamic tag.
*
* @return the unmodifiable, and possibly empty, list of tags.
*/
public List getTags() {
if (_tags == null) {
return Collections.EMPTY_LIST;
}
return Collections.unmodifiableList(_tags);
}
/**
* Checks to see whether the instantiated bean/type/tag is valid.
* p
* This particular implementation checks the instantiated bean/type/tag
* is assigment-compatible with the classes provided as arguments to
* this dynamic tag's constructors.
* p
* Derived classes should augment instead of bypass the checks performed
* by this method, by first calling
codesuper.assertValidTag(tag);/code
*
* @param tag the bean/type/tag to check.
* @throws BuildException if the bean/type/tag is invalid.
*/
protected void assertValidTag(Object tag)
throws BuildException {
if (_types == null || _types.size() 1) {
return;
}
Class tagClass = tag.getClass();
for (int i = 0; i _types.size(); ++i) {
Class type = (Class)_types.get(i);
if (!type.isAssignableFrom(tagClass)) {
throw new BuildException(tagClass +
not assignment-compatible with
+
type);
}
}
}
/**
* Adds the given instantiated bean/type/task to this dynamic tag.
*/
private void addTag(Object realThing) {
assertValidTag(realThing);
if (_tags == null) {
_tags = new ArrayList(Math.min(16, _atMost));
}
_tags.add(realThing);
}
// Intercept maybe configure to check min/max bounds.
public void maybeConfigure()
throws BuildException {
super.maybeConfigure();
if (_atLeast 0 (_tags == null || _tags.size() 1)) {
throw new BuildException(Too few elements: + _atLeast);
}
if (_tags.size() _atMost) {
throw new BuildException(Too many elements: + _atMost);
}
}
/**
* UnknownElement extension to intercept the bean/type/task
* actually instantiated by UnknownElement.
*
* @author a href=mailto:[EMAIL PROTECTED]Dominique Devienne/a
* @version Mar 2003 - Copyright (c) 2002, Landmark Graphics Corp.
*/
private class MyUnknownElement
extends UnknownElement {
private MyUnknownElement(String name) {
super(name);
}
protected Object makeObject(UnknownElement ue, RuntimeConfigurable
w) {
Object realThing = super.makeObject(ue, w);
DynamicTag.this.addTag(realThing);
return realThing;
}
} // END class DynamicTag.MyUnknownElement
} // END class DynamicTag
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 26, 2003 12:25 PM
To: Ant Developers List
Subject: Re: Artima SuiteRunner Task
I would include filters, mappers, conditions and selectors to
the list.
A relatively simple mod to the core ant makes this
possible (bugzilla 17199) basically get ConditionBase.java,
AbstractFileSet, FilterChain implement DynamicConfigurator.
and get UnknownElement (bugzilla 18312) call setProject
earlier on created children.
Mappers are a little different, I implemented a new
attribute to handle this.
It this is done, then non ant core projects may implement
their own whacky types.
(like this to convert to upper case:
filterchain
tokenfilter
scriptfilter language=beanshell
