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: enhancement for PropertyFile, have a patch
See bottom of http://www.apache.org/licenses/ and http://www.apache.org/licenses/software-grant.txt. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enhancement for PropertyFile, have a patch
Dominique, I was pretty sure that Sun's stuff, although available in source form, wasn't open-source per se, so I avoided hacking their code. The class I have is subclassed from Properties (to allow for polymorphic substitution), and includes its own code for parsing the incoming file and handling the escapes. The 'spec' for it (ie. the rules for parsing a properties file) is taken from the documentation of the Properties class, and some experimentation of my own. It was originally coded relying on commons-lang for some string handling (using a sledgehammer to crack a nut there), but I stripped that out to prepare it for Ant, so now it had no dependancy outside the standard JDK. The parsing, escaping and string handling are coded from scratch, and although they don't claim to be the smartest in the world, don't step on anyone's licensing toes. I'll do a search for the Software Grant form that you mention, as the intention is to make it available to the ASF. PHiL --- Dominique Devienne <[EMAIL PROTECTED]> wrote: > I agree with your analysis. Your enhanced > PropertyFile task doesn't > fit the filterchain framework, although as Antoine > rightly writes, > many other things do fit it and should be > implemented or retrofitted > into that framework. > > Regarding your submission per se, it really depends > on how you coded > it. What you did was more or less proposed before, > but it wasn't clear > at the time whether the code was original or simply > modified code of > the JDK Property class from SUN, and thus it didn't > go anywhere. Of > course, taking/hacking SUN's code is a big no-no. If > yours is indeed > original, then by all means post it. Easiest is to > submit patches in > cvs diff -u format attached to a BugZilla report. If > it's brand new > code as opposed to modification of existing code > (already under the > Apache license), you'll have to send a Software > Grant form to the ASF > as well. Stefan knows the details better than me ;-) > > I hope this helps. --DD > > - > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: typedef onerror default
Jose Alberto Fernandez wrote: Steve Loughran wrote: Why is the onerror default of typedef "fail" and not "failall"? The effect is that a typedef like this will warn but not fail if the property file is missing. Surely a missing declaration file is important enough that the default should be "fail the build right now". proposal -we change the "new for ant1.7" default to failall -we allow for a failuremessage attr that lets you say "add checkstyle to your build via -lib" or whatever. This is not necessarily an error. As in some of my buildfiles, the same build may create a library with utility tasks which are typedef'd and use those tasks to do other things. In such an environment, you do not want the code to fail on the typedef but only when you try to use something that is not defined. So a warning is appropriate, and I do not see any reason to change it. I see that, and I see the BC issue. But I also see that when you use antlib URIs, you are declaring tasks with onerror=ignore everywhere, so only need to taskdef very late. Maybe if people say antlib="something" as peter suggested, then the default is failall. we could even add a test message for failures (nested?) that can contain text or URLs for explaining what to do on failure( e.g. download from ant-contrib.sf.net) -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: programmatically creating and marshalling antfiles
jonathan gold wrote: hi. i'm getting back to this now, and saw that there were a few more responses. to answer your question -- it's the latter. i've gone the xml route. the problem is that i have many modules interacting to build a project, and it's difficult, though not impossible, to do this with DOM, as i am now. it's not the DOM that makes it hard -- but the lack of typing, thus the desire to use the java objects, with their convenient accessors and access to the current project structure and type safety. ahh, you are in the "O/X mapping is soluble camp", I see. You could use Xom and provide classes (and a builder) for the core Ant things (project, target, core tasks) that map typed get/set to attribute/element manipulation of the nodes. This is what I do in my projects, and while it takes effort, it works well with XPath/Jaxen -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Subversion migration?
> Let's do this Saturday, 3rd Sept, 20:00 EST. Any last minute change of plans? Let us know how this goes, and thanks of lot for doing this for us Henri. Good luck, --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: enhancement for PropertyFile, have a patch
I agree with your analysis. Your enhanced PropertyFile task doesn't fit the filterchain framework, although as Antoine rightly writes, many other things do fit it and should be implemented or retrofitted into that framework. Regarding your submission per se, it really depends on how you coded it. What you did was more or less proposed before, but it wasn't clear at the time whether the code was original or simply modified code of the JDK Property class from SUN, and thus it didn't go anywhere. Of course, taking/hacking SUN's code is a big no-no. If yours is indeed original, then by all means post it. Easiest is to submit patches in cvs diff -u format attached to a BugZilla report. If it's brand new code as opposed to modification of existing code (already under the Apache license), you'll have to send a Software Grant form to the ASF as well. Stefan knows the details better than me ;-) I hope this helps. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
