Travel Assistance applications open for ApacheCon North America 2011
The Apache Software Foundation (ASF)'s Travel Assistance Committee (TAC) is now accepting applications for ApacheCon North America 2011, 7-11 November in Vancouver BC, Canada. The TAC is seeking individuals from the Apache community at-large --users, developers, educators, students, Committers, and Members-- who would like to attend ApacheCon, but need some financial support in order to be able to get there. There are limited places available, and all applicants will be scored on their individual merit. Financial assistance is available to cover flights/trains, accommodation and entrance fees either in part or in full, depending on circumstances. However, the support available for those attending only the BarCamp (7-8 November) is less than that for those attending the entire event (Conference + BarCamp 7-11 November). The Travel Assistance Committee aims to support all official ASF events, including cross-project activities; as such, it may be prudent for those in Asia and Europe to wait for an event geographically closer to them. More information can be found at http://www.apache.org/travel/index.html including a link to the online application and detailed instructions for submitting. Applications will close on 8 July 2011 at 22:00 BST (UTC/GMT +1). We wish good luck to all those who will apply, and thank you in advance for tweeting, blogging, and otherwise spreading the word. Regards, The Travel Assistance Committee - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Ivy Jenkins build
Why do we only do a 'clean jar'? Shouldn't we be running unit tests at least? Isn't that kind of the point of CI? Perhaps 'clean coverage-report'? Matt - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ivy Jenkins build
FYI I experimented with running these targets; build completed successfully in 3.x minutes. I'm not going to revert my change unless someone presents a good reason to do so. Matt On Mon, Jun 6, 2011 at 10:18 AM, Matt Benson gudnabr...@gmail.com wrote: Why do we only do a 'clean jar'? Shouldn't we be running unit tests at least? Isn't that kind of the point of CI? Perhaps 'clean coverage-report'? Matt - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Command Line Debugging
The idea really looks like promising. I think this feature could have a better place in ant itself (i'm adding them in copy of this email). Could you share the code of your POC somewhere with some guide line to test it? I'm pretty sure people will have ideas when they will try it. If you need a place to publish it you can use this : https://svn.apache.org/repos/asf/incubator/easyant/tasks/trunk/. 2011/5/29 Purkayastha, Siddhartha siddhartha.purkayas...@ca.com Hello All - I wanted to discuss an idea with you about diagnostics. When considering about diagnostics, it should comprise of a set of tools that can help me diagnose issues I am facing with my build. Ant -diagnostics returns lots of variables that can be valuable to resolving environment / setup issues. I am thinking of the possibility of a Command Line Debugger / Inspector included within EasyAnt (or may be even Ant itself). I am not aware if such a tool already exists. It could behave something like this: I can run: ant -breakAt=someTarget The breakAt parameter could indicate a breakpoint at target 'someTarget'. The user could be interactively displayed a prompt here: breakpoint: [Debugger] DEBUGGER Where the user could issue a set of commands to inspect the state of the build so far. For example: breakpoint: [Debugger] DEBUGGER inspect some.property Property Value: HelloWorld The same idea could be extended to include other build factors, like paths, imported plugins etc. It may actually be extended to become a fully featured command line debugger, from where one can also set new property values or override existing values (probably a relaxation of immutability for the support of this tool) etc, do step over, step into etc. I did some experiments with this concept, I was able to break at a certain target and inspect values of properties that user wants to see, using a new target created at Runtime, with a single task that accepted user inputs from command line, interpreted it and displayed an output - And kept on doing so till the user typed 'return' on the prompt. I also think, as an extension - if we can also track audit history of different properties, paths, references etc, then this could be an effective tool. However, I do not think it is easily achievable today. I am wondering about the technical feasibility and utility of such an inbuilt tool. Can you share your thoughts on this? Thanks, Siddhartha -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Ivy Jenkins build
Matt, the junit tests were running in another separate project: https://builds.apache.org/job/Ivy-tests/ Maarten From: Matt Benson gudnabr...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Monday, June 6, 2011 5:28 PM Subject: Re: Ivy Jenkins build FYI I experimented with running these targets; build completed successfully in 3.x minutes. I'm not going to revert my change unless someone presents a good reason to do so. Matt On Mon, Jun 6, 2011 at 10:18 AM, Matt Benson gudnabr...@gmail.com wrote: Why do we only do a 'clean jar'? Shouldn't we be running unit tests at least? Isn't that kind of the point of CI? Perhaps 'clean coverage-report'? Matt - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
