Re: Abusing the BuildListener
On 7/12/06, Henri Yandell [EMAIL PROTECTED] wrote:
I suspect this isn't what was intended for the build listener, but
I've been using it to override the build.xml for junit tasks. In
startTask I ensure that haltonerror and haltonfailure are set to
false. Next up I want to ensure there is always a formatter
type=xml/, but adding a new task in seems a lot more painful than
simply modifying the existing objects.
Very happy; I've got it working. Many thanks for all the help!
I kept playing with the direction Matt had me go and it suddenly
worked (when I was really looking to see what the old error was). The
following code forces the haltonfailure and haltonerror attributes to
always be false; and ensures that an xml output is always done.
public void taskStarted(BuildEvent event) {
if(event.getTask().getTaskName().equals(junit)) {
UnknownElement ue = (UnknownElement) event.getTask();
RuntimeConfigurable rc = ue.getWrapper();
rc.setAttribute(haltonfailure, false);
rc.setAttribute(haltonerror, false);
UnknownElement ue2 = new UnknownElement(formatter);
ue.addChild(ue2);
FormatterElement fe = new FormatterElement();
RuntimeConfigurable rc2 = new RuntimeConfigurable(fe,
formatter);
rc2.setAttribute(type, xml);
rc.addChild(rc2);
}
}
Hopefully there won't be any surprises when I throw this into a real scenario.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abusing the BuildListener
On 7/14/06, Matt Benson [EMAIL PROTECTED] wrote:
Henri: Did you ever get this working?
-Matt
Sorry, was working on it on Saturday but then an unhappy 2 year old
intervened before the reply was finished. Replying below, thanks for
the followup.
On 7/14/06, Matt Benson [EMAIL PROTECTED] wrote:
Can you try calling
maybeConfigure(), followed by getRealThing() on your
UnknownElement to get your JUnitTask instance?
Thanks Matt, the code looks really good now - just doesn't work :(
Here's where I am:
if(event.getTask().getTaskName().equals(junit)) {
Task task = event.getTask();
UnknownElement ue = (UnknownElement) task;
ue.maybeConfigure();
JUnitTask jut = (JUnitTask) ue.getRealThing();
jut.setHaltonerror(false);
jut.setHaltonfailure(false);
FormatterElement fe = new FormatterElement();
FormatterElement.TypeAttribute feta = new
FormatterElement.TypeAttribute();
feta.setValue(xml);
fe.setType(feta);
jut.addFormatter(fe);
}
The Halt's have stopped working, which I'd previously overridden via:
RuntimeConfigurable rc = ue.getWrapper();
rc.setAttribute(haltonfailure, false);
rc.setAttribute(haltonerror, false);
Looking at UnknownElement, I think the real call to maybeConfigure
from within Project blows away the one that I've put in place, then
applies the RuntimeConfigurable again.
(then I continued to dig into things but didn't get anywhere in particular)
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abusing the BuildListener
On 7/14/06, Steve Loughran [EMAIL PROTECTED] wrote: Henri Yandell wrote: Reading the presetdef manual page, it sounds like it's not what I want because it only sets defaults and not mandated values. I don't want to allow the build.xml to change the settings. Well, if you are being really ruthless, you could subclass junit, and have a distro with a modified properties file defining the junit typedef and pointing at your subclass. The subclass gets to enforce its own rules... Yeah, that's what I was originally going to do. I got excited when I realised that not only could I use -listener to hack it, I could possibly do it in such a way that I had some kind of AspectAnt that would let me modify Ant on the fly for other tasks. Is that going to be impossible for subtags, or do I just need to grok how UnknownElements work etc? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abusing the BuildListener
On 7/14/06, Matt Benson [EMAIL PROTECTED] wrote: --- Henri Yandell [EMAIL PROTECTED] wrote: Is that going to be impossible for subtags, or do I just need to grok how UnknownElements work etc? Am I being dense here? I haven't grasped why you need to use UEs instead of using task/type classes directly. The UnknownElement is generally an artifact of Ant's XML configuration mechanism and can (should) be bypassed in programmatic Ant usage. Entirely me being dense - this is my first time digging into these parts of Ant. When I inspect the event in taskStarted, it consists of UnknownElements, so my first attempt was to duplicate the structure of one of these to get my formatter. I can mimic one happily enough (for all the getXxx responses), but something's not right in my mimicry as it falls over. Just making an org.apache.tools.ant.taskdefs.optional.junit.FormatterElement and adding that seems good, but looking at the API for UnknownElement, I don't see a way to add anything to it that isn't another UnknownElement. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abusing the BuildListener
On 7/14/06, Matt Benson [EMAIL PROTECTED] wrote: --- Henri Yandell [EMAIL PROTECTED] wrote: On 7/14/06, Matt Benson [EMAIL PROTECTED] wrote: --- Henri Yandell [EMAIL PROTECTED] wrote: Is that going to be impossible for subtags, or do I just need to grok how UnknownElements work etc? Am I being dense here? I haven't grasped why you need to use UEs instead of using task/type classes directly. The UnknownElement is generally an artifact of Ant's XML configuration mechanism and can (should) be bypassed in programmatic Ant usage. Entirely me being dense - this is my first time digging into these parts of Ant. When I inspect the event in taskStarted, it consists of UnknownElements, so my first attempt was to duplicate the structure of one of these to get my formatter. I can mimic one happily enough (for all the getXxx responses), but something's not right in my mimicry as it falls over. Just making an org.apache.tools.ant.taskdefs.optional.junit.FormatterElement and adding that seems good, but looking at the API for UnknownElement, I don't see a way to add anything to it that isn't another UnknownElement. whoo, I'm confused... none of the classes in oata.taskdefs.optional.junit, including FormatterElement appears to have any knowledge of UEs... so it looks at my admittedly casual glance like you could just programmatically set the properties (xml attributes) of a FormatterElement in code and add it to your JUnitTask instance. Is there a reason (that my perfunctory analysis didn't find) that this won't work? I don't have a JUnitTask instance :( I'm using the BuildListener interface, and I just get an UnknownElement object that represents the junit (and I guess later on becomes a JUnitTask). Thanks all for putting up with this btw, I know I'm being an ignorant newbie here :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Abusing the BuildListener
On 7/13/06, Steve Loughran [EMAIL PROTECTED] wrote: Henri Yandell wrote: I suspect this isn't what was intended for the build listener, but I've been using it to override the build.xml for junit tasks. In startTask I ensure that haltonerror and haltonfailure are set to false. Next up I want to ensure there is always a formatter type=xml/, but adding a new task in seems a lot more painful than simply modifying the existing objects. Here's a chunk of my code: UnknownElement proxy = new UnknownElement(formatter); proxy.setNamespace(); proxy.setQName(formatter); proxy.setTaskName(formatter); proxy.setTaskType(org.apache.tools.ant.taskdefs.optional.junit.FormatterElement); proxy.setProject(task.getProject()); proxy.setOwningTarget(task.getOwningTarget()); RuntimeConfigurable fc = new RuntimeConfigurable( proxy, formatter); fc.setAttribute(type, xml); rc.addChild(fc); // rc is the RuntimeConfig for the junit task When I build with a listener that contains this, I get: Class org.apache.tools.ant.UnknownElement doesn't support the type attribute. have you not thought of using presetdef to define a new junit with the right defaults? Didn't know it existed :) Reading the presetdef manual page, it sounds like it's not what I want because it only sets defaults and not mandated values. I don't want to allow the build.xml to change the settings. My ant script calls other ant scripts, so would be worried that the presetdef wouldn't survive down into the ant call. Of course I'm assuming that I can get the listener into the ant call in some way :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Abusing the BuildListener
I suspect this isn't what was intended for the build listener, but I've been using it to override the build.xml for junit tasks. In startTask I ensure that haltonerror and haltonfailure are set to false. Next up I want to ensure there is always a formatter type=xml/, but adding a new task in seems a lot more painful than simply modifying the existing objects. Here's a chunk of my code: UnknownElement proxy = new UnknownElement(formatter); proxy.setNamespace(); proxy.setQName(formatter); proxy.setTaskName(formatter); proxy.setTaskType(org.apache.tools.ant.taskdefs.optional.junit.FormatterElement); proxy.setProject(task.getProject()); proxy.setOwningTarget(task.getOwningTarget()); RuntimeConfigurable fc = new RuntimeConfigurable( proxy, formatter); fc.setAttribute(type, xml); rc.addChild(fc); // rc is the RuntimeConfig for the junit task When I build with a listener that contains this, I get: Class org.apache.tools.ant.UnknownElement doesn't support the type attribute. Before I dig deep into how the xml is parsed and turned into an object model - is it blatantly obvious what I'm doing wrong? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
On 9/3/05, Dominique Devienne [EMAIL PROTECTED] wrote: Let's do this Saturday, 3rd Sept, 20:00 EST. Any last minute change of plans? Nothing, apart from me starting an hour late because my son is cuter than you guys :) Let us know how this goes, and thanks of lot for doing this for us Henri. Good luck, --DD Surprisingly long, took the better part of 2 hours. For the machine anyway, I get to multi-task and do other things while it slogs along :) Tis done now: http://svn.apache.org/repos/asf/ant/core/ svn co https://svn.apache.org/repos/asf/ant/core/trunk ant-core I added 'alexeys' to the authorization list for ant in SVN, I got the feeling that you guys had already moved your CVS auth list to SVN, but that alexeys was added to CVS after that event. Emails will goto [EMAIL PROTECTED] Let me know if there are any problems, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
On 8/31/05, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Henri Yandell wrote: Conor: Any time when you'd like the migration to happen? Hen Hello, since we had a positive vote [1] to migrate to SVN, I think the migration should happen as soon as it is practicable for you Henri. Can you suggest a time ? Let's do this Saturday, 3rd Sept, 20:00 EST. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
On 8/30/05, Jack Woehr [EMAIL PROTECTED] wrote: Yves Martin wrote: I propose to install a post-commit hook in subversion to keep cvs up-to-date even with read-only access: http://sam.zoy.org/writings/programming/svn2cvs.html That would be nice! Would be nice, but given that 80% of the ASF is now in SVN, it seems a bit late. Plus it'd only be there for 4 months. Hesistant to introduce something new at this stage (and spend the time getting it setup etc) without getting more payback. My view anyway, -1 the migration if it's a blocker for you, otherwise I'll go ahead on Saturday and make the change. Sorry, Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
On 8/28/05, Jack Woehr [EMAIL PROTECTED] wrote: Conor MacNeill wrote: The following link goes through the basics. After that it is all pretty straightforward. http://www.apache.org/dev/version-control.html If you have particular issues, just yell out Thanks, Conor. If I read that page correctly, it says something I hadn't quite grokked from the list discussion, to wit, you're going to maintain *both* CVS and SVN access for a while to the same code body? Nope, which bit suggests that? Once migrated to SVN, CVS is currently being kept in a read-only state, with no changes since the point at which a snapshot was taken for migration. This'll all get turned off at the end of the year, but it's been preferred to have it available in the meantime. Conor: Any time when you'd like the migration to happen? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
On 8/20/05, Henri Yandell [EMAIL PROTECTED] wrote: On 8/16/05, Stefan Bodewig [EMAIL PROTECTED] wrote: +1 on the migration, or rather +0.5 since I don't know much help I'm going to be right now (adapting to a different timing schema after switching jobs). I can pretty much do it anytime, just need to type a handful of lines and let the ASF hardware churn for a little bit. How does next Saturday evening sound, Aug 27th 20:00 EST? Didn't hear back, so hopefully that meant not to go ahead and do it :) I can go ahead and migrate pretty much anytime, just need to make sure you're happy with when :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
On 8/16/05, Stefan Bodewig [EMAIL PROTECTED] wrote: On Thu, 4 Aug 2005, Henri Yandell [EMAIL PROTECTED] wrote: Looks like it just needs to go into a core/. Structure looks fine, although we probably don't need that many tags (we can remove them easily) and I wouldn't want to retain any of the old branches - their tips are supposed to correspond to a tag anyway. Easy enough for you guys to remove them later. They don't really cost anything on the Infra side. +1 on the migration, or rather +0.5 since I don't know much help I'm going to be right now (adapting to a different timing schema after switching jobs). I can pretty much do it anytime, just need to type a handful of lines and let the ASF hardware churn for a little bit. How does next Saturday evening sound, Aug 27th 20:00 EST? I would: Make CVS read-only. Load copy of CVS into SVN. Copy authentication from CVS to SVN. Make sure the commit notification looks to be setup correctly. For a small CVS repository it can be as quick as 30 minutes, for Ant I'm guessing an hour or two as the larger size means it has to churn more. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [VOTE] migrate to svn
On 8/12/05, Kev Jackson [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: I´m just getting the results of the vote. But I´m not sure which action from the bylaws to use. An Adoption of New Codebase needs 2/3 majority of committers which we havent (~ 1/3). Many committers havent voted, but we have consensus. How to proceed? [snip results] Can the infrastructure guyes handle the migration this weekend? If not then we have to delay anyway Could have, I just wasn't monitoring this thread until just now and would hate to dive in without giving you guys warning :) Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
Any further thoughts migration-wise? Did you get your stuff done Steve? Hen On 8/1/05, Steve Loughran [EMAIL PROTECTED] wrote: I have some things I'd like to commit (and then tag and delete), and before that I need to do some changes to Get; if I can get those done quickly then I'm +1. If I cant get them done quickly, then they werent that important. -steve - 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: Subversion migration?
Looks like it just needs to go into a core/. I've gone ahead and made this change manually to show what it would look like (it's a very tiny change to the migration). Hen On 8/3/05, Peter Reilly [EMAIL PROTECTED] wrote: If you check old mails, I think that Stefan has already proposed a layout. It needs to incorporate the antlibs directories (already in svn). Also, antidote is no longer supported, and should not be placed in svn - unless someone wants to maintain it. Peter Henri Yandell wrote: To accompany the ongoing vote, I've setup a test Ant migration. https://svn.apache.org/repos/test/ant/ svn co https://svn.apache.org/repos/test/ant/trunk ant I've made the huge assumption that the Ant TLP have only one codebase and haven't structured it in an umbrella way. I'm not sure if ant-antidote is live and needs to be a part of the migration too. SVN is hierarchical, so you'd end up with something like: ant/ core/ trunk/ branches/ tags/ antidote/ trunk/ branches/ tags/ Currently it's just: ant/ trunk/ branches/ tags/ Anyway, give it a try if you want and let me which strategy seems to make sense for Ant; ie) where do you want antidote? Hen - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
To accompany the ongoing vote, I've setup a test Ant migration. https://svn.apache.org/repos/test/ant/ svn co https://svn.apache.org/repos/test/ant/trunk ant I've made the huge assumption that the Ant TLP have only one codebase and haven't structured it in an umbrella way. I'm not sure if ant-antidote is live and needs to be a part of the migration too. SVN is hierarchical, so you'd end up with something like: ant/ core/ trunk/ branches/ tags/ antidote/ trunk/ branches/ tags/ Currently it's just: ant/ trunk/ branches/ tags/ Anyway, give it a try if you want and let me which strategy seems to make sense for Ant; ie) where do you want antidote? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion migration?
Talked a little with Stefan offline about when/whether you guys would be interested in an svn migration. He'd said that you wanted to migrate before the Ant 1.7? Looking at the Ant CVS structure, it looks pretty basic and could be done pretty quickly without much work on your parts. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
