Re: [Proposal] Krysalis Centipede, Ruper, Version to Ant

At 08:31 AM 3/7/2003 +0100, Stefan Bodewig wrote: On Thu, 6 Mar 2003, Steve Loughran <[EMAIL PROTECTED]> wrote: > how about an ant sandbox? IMHO we should move the whole proposal area there, this would also make our CVS snapshots smaller. +1 to both these ideas. In the best traditions of virtuously

Re: JDK 1.1 support

At 03:28 PM 3/13/2003, Conor MacNeill wrote: I'd like to throw this up again. What are peoples thoughts on the following 1. Make Ant 1.6.x the last JDK 1.1 release. This would be clearly documented +1 2. Make the subsequent release require JDK 1.2+ (what about leap frogging to later versions?) I d

Re: [VOTE] JDK 1.1 support

At 10:45 PM 3/18/2003, Conor MacNeill wrote: Ant 1.6 will require JDK 1.2 to compile and build. Releases from the 1.5 branch will be the last to support JDK 1.1 compilation, including Ant 1.5.3 and any subsequent maintenance releases. The ability to compile/build for JDK 1.1 deployment continues to

Re: VOTE: new committer: Jesse Stockall

At 11:13 PM 4/5/2003, Steve Loughran wrote: I nominate Jesse Stockall as a committer +1

Re: [PATCH] add regular expression selector (re-worked)

At 06:31 PM 4/11/2003, Jay wrote: I was thinking I should also do a test case. I have gotten lost trying to find what's needed. I know you aren't alone. I need to document this much better. I'm sure these questions have been answered before but so far I have not had much luck finding a howto for

Re: [VOTE] Antoine Levy-Lambert as committer

+1

Re: [VOTE]

At 02:19 AM 4/21/2003, you wrote: I use from ant-contrib a lot. I propose that it be migrated to Ant's HEAD. Objections? A big +1 from me assuming copyright assignment can be resolved. We should also probably add a FAQ entry on how to do multiple levels of dereferencing of a property once thi

Re: Antlib descriptor

(Boy, you fall behind a couple of days on your email and suddenly an avalanche breaks loose) At 10:39 AM 4/25/2003 -0700, Costin Manolache wrote: However I'm more convinced than ever that the XML should use a subset of ant, and reuse the same processing infrastructure. I.e. not another parser or

Re: [PMC VOTE] Adoption of Bylaws

At 05:00 PM 5/20/2003 +1000, Conor MacNeill wrote: PMC members, I'd like to move towards adoption of the bylaws draft. http://cvs.apache.org/viewcvs.cgi/*checkout*/ant/proposal/ant-site/anakia/docs/bylaws.html?rev=1.16 +1 assuming the typos are fixed. I'd go in and fix them, but I'm not sure wheth

Re: [PMC VOTE] Adoption of Bylaws

At 09:41 AM 5/21/2003 +1000, Conor MacNeill wrote: No, fixing typos wouldn't affect the vote, so please go ahead and fix them :-) Ok, done. But in proofing the document I realized there was another issue that may be a significant typo or may just require a bit more editing. The responsibilities s

Re: Selector tests/DifferentSelector

At 12:03 PM 5/27/2003 +0200, Antoine Levy-Lambert wrote: Hi Steve, do you mean you have difficulties to understand the existing selector tests. I have had some difficulties there too. Ok, you guys have guilted me in to cleaning up my previously posted description and committing it. Hopefully it wi

Re: AW: Selector tests/DifferentSelector

At 12:09 PM 5/27/2003 +0200, [EMAIL PROTECTED] wrote: I am working on a new Selector (with tests of course) and one point on my todo list is improving the doco about testing selectors. I took a lot of code reading for comprehending the test procedure. Take a look at the README file I just posted in

Re: AW: Selector tests/DifferentSelector

At 07:07 PM 5/27/2003 +0200, [EMAIL PROTECTED] wrote: Hmm, I can´t find any README there. I updated my local CVS tree right now (27.Mai 18:56 Berlin time) and looked in src\testcases\org\apache\tools\ant\types\selectors (BaseSelectorTest.java) It's there: http://cvs.apache.org/viewcvs.cgi/ant/sr

Re: cvs commit: ant/src/main/org/apache/tools/ant/taskdefs/optional/junit FormatterElement.java JUnitTask.java

At 09:37 AM 5/28/2003 -0700, Steve Loughran wrote: Im ok with this, but do worry about the general trend which I have recently contributed to (if and unless on in and siblings, though this is, as with a mapping of conditional java properties to #define values. Ditto. Generally, I favour usefu

Re: Selector Test

At 10:00 AM 6/4/2003 +0200, [EMAIL PROTECTED] wrote: When writing the testcase for my selector I missed some functionality in BaseSelectorTest: - transfering properties from JUnit test class to the Ant test project - resolve the selection String ("T..FF") to filenames I have done that with a lo

Re: [PATCH] Documentation of Patternset

At 04:53 PM 6/5/2003 +0200, [EMAIL PROTECTED] wrote: On http://www.jguru.com/forums/answer.jsp?op=62&EID=1091298 there is a nice question. Maybe we should add that pattern as example. Following the diff. Thanks for the diff, but I think the examples should be as illuminating as possible, rather th

Re: Ant scripting from Jython.

At 11:43 AM 6/13/2003 -0700, James Duncan Davidson wrote: Not that useful but a bit more grist for this mill. It certainly showed me that it is hard to cram the expressiveness of the XML approach into method calls. I had to limit myself to a very narrow subset of tasks and their usage patterns. It

Re: [VOTE] Jan Materne as committer

At 08:06 PM 6/25/2003 +1000, Conor MacNeill wrote: I'd like to propose Jan Materne as an Ant committer. I think his contribution in recent months has been quite obvious both on the dev and user lists and also the bug reports. I think he would make a great committer. +1

OT: More trivia about dates than you ever wanted to know

At 08:59 AM 6/24/2003 -0700, Steve Loughran wrote: Martin Gainty wrote: Alright I'll ask the dumb question What happened on Jan 1 1601??? -Martin Of most interest to clocks is that by that day, the start of the seventeenth century, most of the western world had updated their calendars to adopt th

Re: OT: More trivia about dates than you ever wanted to know

At 01:05 PM 6/26/2003 +1000, Conor MacNeill wrote: On Thu, 26 Jun 2003 06:22 am, Bruce Atherton wrote: > AU Australia 1752-09-02 Hmmm. I don't think the inhabitants at the time made any record of that decision. Quite right. Perhaps you should submit a patch. :-) From the ncal

Re: [PMC-VOTE] Ant 1.5.4

At 09:09 AM 8/12/2003 +0200, Stefan Bodewig wrote: Please vote for/against these archives as the 1.5.4 release. Here's my +1 for starters. +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PRO

Re: debian packaging related tasks - sandboxable?

ems to me. The downside is that the control is pretty coarse-grained: either you accept all the antlibs installed in ${ANTLIB_HOME}, or none of them. There is also the potential for all of the issues that installed extensions have had. Stefan Bodewig wrote: On Fri, 11 May 2007, Bruce A

Re: [VOTE] Weblogic and Starteam antlibs for ant 1.8.0

Yes, +1. Peter Reilly wrote: Yes - move the weblogic and starteam tasks to antlibs. [ ] No - keep them in ant 1.8.0 [ ] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-m

Re: [VOTE] Ben Burgess as committer

+1 Peter Reilly wrote: Hi all, I would like to propose Ben Burgess as a committer for the ant project, with a special interest in maintaining the starteam tasks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional

Re: [VOTE] Accept Ivy as subproject of Ant

+1 [EMAIL PROTECTED] wrote: Should we accept Ivy as subproject? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: OT: C projects for students?

Subversion is a good project to start with, I think, for a couple of reasons. First, it has a considerable amount of documentation for new people starting out to learn the ropes. See http://subversion.tigris.org/hacking.html in particular. Second, it has a lively community with a well-develo

Re: svn commit: r584139 - /ant/core/trunk/build.bat

You could also have reverted the change in your working copy: svn merge -r 584139:584138 https://svn.apache.org/repos/asf/ant/core/trunk and then committed it. See http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.2 Stefan Bodewig wrote: On Fri, 12 Oct 2007, Jan Materne <[EMAI

Re: Ivy mailing list organisation

Martijn Kruithof wrote: Good points new proposal: notifications (gump, wiki, bugzilla, jira, wiki, svn, for both ivy and ant) dev (development discussion on both ivy and ant) ant-user ivy-user +1 - To unsubscribe, e-ma

Re: svn commit: r585108 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/XSLTProcess.java

The changes for svn version 1.5 are for tracking of merges so that you don't accidentally merge the same changes twice to the same place, which I don't think is the issue here. Subversion has had good merge support between branches since the first release. See http://svnbook.red-bean.com/en/1.

Re: [VOTE] Merge Ivy and Ant Dev Lists

Stefan Bodewig wrote: Should we merge [EMAIL PROTECTED] into [EMAIL PROTECTED] and likewise [EMAIL PROTECTED] into the new [EMAIL PROTECTED] +1 to both. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-

Re: Moderators for notifications@ (was Re: [RESULT] notifications list will be created)

If you need someone in a different timezone, I'll volunteer. I'm in the Pacific timezone, which I believe is very different from the rest of you. Like Gilles, I haven't handled mailing list moderation duties before, but there is always a first time. Xavier Hanin wrote: On 10/30/07, Stefan Bo

Re: Updated Apache Ant listing in the EOS Directory

Hi, Ryck. The Ant developer mailing list is probably the best place to post messages that are meant to address the community of Ant committers. This would likely be true of many other open source projects, as well. I've cced the mailing list so that others have a chance to review your Ant pag

Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects

Gilles Scokart wrote: Finally, I stopped my reflections, thinking that it is certainly something that already exists in the wild. Does it? If I remember correctly (it was a long time ago) it used to. There used to be a project called Centipede that built Ant scripts into something called "cen

Re: AW: ant java versions

To me, the super-compelling reason is that if we claim to support Java 1.3, then we have to make sure to test against it on all supported platforms. This is a lot of extra work (on top of the testing for 1.4, 1.5, and 1.6), particularly if none of us has Java 1.3 installed. This has bitten us i

Re: moving to Jira

I was +1 on this before, and I am +1 now, particularly since Ivy uses it. But the objection that others have concerning threading when reading with GMail is a fair reason for vetoing again, as happened before. I've filed a bug report with Google on their lack of support for observing the In-Re

Re: AW: ant java versions

Peter Reilly wrote: There are a woe-full amount of java 1.3 users as well.. Peter And of 1.2 users that we abandoned during the 1.7 release. But the thinking at that time, and I think it holds up here as well, is that if those users are too conservative to move beyond a JVM which has now

Re: [VOTE] add Nicolas Lalevée as committer

+1 Xavier Hanin wrote: So I think he would make a good addition to our developer team, hence this is a vote to make him a new committer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL

Re: xmlproperties task

What I think you are missing is that the XML hierarchy translates into the name of the property. This is true whether you use Semantic Attributes or not, since they do not alter the name. Your XML file actually defines the same property name over and over again. If keepRoot were set to true, t

Re: [Vote] 1.7.1beta2

+1 Kevin Jackson wrote: A retrospective vote on these tarballs has been proposed, so Available tarballs at http://people.apache.org/dist/ant/v1.7.1beta2/ are ready: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additio

Re: Upgrading the version of IvyDE

+1. What Stefan said. Stefan Bodewig wrote: On Wed, 16 Apr 2008, Nicolas Lalevée <[EMAIL PROTECTED]> wrote: I would like to upgrade the version of IvyDE to 2.0. The trunk version is currently tagged to be an 1.3. I would like to make this upgrade for sevral reasons: - the trunk version of

Re: Is our objective for 2.0 too ambitious? (was Re: Ivy 2.0 planning)

I think you have to accept that there will be bugs. After all, would you halt the whole release if a minor bug was found the day before it was due to be published? But there are different categories of bugs. Some are so serious that you don't want to roll a release with it no matter what. This

Re: Is our objective for 2.0 too ambitious? (was Re: Ivy 2.0 planning)

Typically you would use a new Status, but I am uncertain about how much control you have over the Apache Jira instance. Can you introduce new workflow for your project? I don't think that merely setting the priority should result in moving between Open and In Progress. There should be an inter

Re: Adding magic properties for targets?

My problem with magic properties is that they pollute the namespace of allowed property names. Since properties are immutable, it can be confusing for someone to try to define a property for the first time in their build file and have it come back with an error about redefinition. Having said

Re: Issue 45190 and Ant 1.7.1

I understand the sentiment, but the implication is that our releases are always identical to our betas. AFAIR we have never had that policy before. The benefit to doing that is that we know we haven't added code that hasn't been through an adequate release cycle, no matter how trivial a change

Re: [VOTE] Adopt Java 1.4 as a minimum requirement for core/trunk

Stefan Bodewig wrote: This is not that much based on features available (although I consider using NIO in StreamPumper) but more on "where do we test". +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,

Re: How about moving all SCM and EJB tasks into Antlibs?

I like the concept simply because it seems like the best way to get old, mostly unused ant tasks out of the standard release. I'm not so concerned about moving the tasks that are commonly used out of optional to their own antlibs (though I have no objection to it) because I can't see there bein

Re: EasyAnt phases

Conceptually I agree with you, but I think we need to recognize why people would want this and to validate their concerns. Consider these targets: ... ... Whether or not "clean" is a dependency of "compile" depends on the context "compile" is executed in. Now, it is possible to work around

Re: svn commit: r714053 - /ant/core/trunk/src/main/org/apache/tools/ant/types/resources/MappedResource.java

I haven't taken a look at the the code so this is off the cuff, but couldn't you use a boolean field for each of the interfaces on the Resource class to indicate whether it is supported? Then have any methods that implement that interface check the boolean flag to see whether to proxy the reque

Re: EasyAnt phases

I think that summary does the job nicely. The only other topic I saw brought up on this thread was whether a target-group should be allowed to have tasks in it rather than requiring it to be empty. This can also be discussed separately, though, if people feel strongly enough about it. Stefan B

Re: target-group committed

I am in the same boat as Stefan. I also don't understand yet why target-groups are not just targets to the person running Ant. What you appear to be arguing here is that there should be two levels to Ant targets. But why just two? Why not three or four or five? I've written build systems this

Re: target-group committed

far into a strict layer decomposition. This might be too restrictive. Having a PartOf relationship allow to do strict layering elegantly, but there might be other usage to partOf. If the only benefits of a numerical layer is to hava a -p1 .. -pn options, then I think the benfit is too limited. G

Re: [FWD] Bugzilla upgrade and proposed change to workflow

Since the workflow is now configurable, presumably that means that we can define new states. If so, why couldn't we create our own state (WORKINGON or something) to indicate that someone is tackling the bug without changing the email address? Could we ask the admin to change all assigned to a

Re: [VOTE] Release AntUnit 1.0 Beta 1

+1 Stefan Bodewig wrote: Hi all, I've uploaded the files that correspond to a tagged but not yet committed version of AntUnit to . I propose to release those files as "Apache AntUnit 1.0 Beta 1". Stefan -

Re: [VOTE] drop java 1.2 support in ant 1.7.1 and later

+1 to dropping support for Java 1.2 altogether as of now. Martijn Kruithof wrote: > > > [ ] Yes drop Java 1.2 support altogether as of now > [ ] No do not drop Java 1.2 support altogether as of now > - To unsubscribe, e-mail: [E

Re: [Vote] move defect tracking from bugzilla to Jira

Thunderbird threads Jira emails only sometimes. It looks like it does so when the emails have exactly the same subject line, typically when the ticket is updated. For other types of changes, such as work flow or logging of work, they will not appear in the same thread. I use Jira at work all the t

Re: debian packaging related tasks - sandboxable?

I think your plan is a great one. I'm having a related but different thought about debian support. What do people think about Ant supporting a way to install and remove antlibs from the command line into a standard antlib directory that is automatically added to the classpath on startup? That

Re: FW: APIDocs online?

[EMAIL PROTECTED] wrote: If I remember right, we had a nice comment online before 1.6 ... Something like "no official online; latest on nagoya; see your local copy" We did, and it got schwacked accidently. I've done a checkin that restores the original pages but the web site will need to be regene

Re: Distribution of modified ANT script in my project (JNetStream)

Mark Bednarczyk wrote: Hi Bruce, my name is Mark Bednarczyk I have an OpenSource project on SourceForge JNetStream (http://jnetstream.sf.net). I would like to use a modified version of your ANT script in my project to execute my java applications. I have modified the original "ant" script for two

Re: VOTE - new committer - Martijn Kruithof

Erik Hatcher wrote: Better late than never: +1 Ditto. +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Start a subproject for Ant libraries

+1. The points that Conor brought up are good ones and probably need thrashing out before we can make a decision about them, but I'd prefer we vote on this proposal first just so we can get something started, and vote on an amendment to the proposal afterward. Iterative design through iterative

Re: New COPY granularity breaks builds on Windows 2000

Xxx Yyy wrote: Thanks for your consideration. I think you are testing the wrong thing -- an OS test is not a substitute for FS test. That is true, but there is no FS test. This code is not trying to be an FS test, it is trying to be smart about guessing a default value using whatever information

Re: New COPY granularity breaks builds on Windows 2000

Steve Loughran wrote: 1. we could have a property "ant.filesys.granularity" which can be set to something in a build.properties or on the command line. if unset, you get the default.. I don't have a problem with this, but I know the general reaction is "No Magic Properties". 2. we could have a

Re: New COPY granularity breaks builds on Windows 2000

Xxx Yyy wrote: I disagree with the measurements here. The granularity default should not be based on popularity of FS or current usage of ant. Ant must work in a predictable, reliable manner. And maintain function from release to release. As ant tries to get intelligent and make assumptions on

Re: [VOTE] Retire Antidote

+1. Stefan Bodewig wrote: Since Antidote's development has been stalled for a long time now - and there doesn't seem to be a big need for an Ant GUI given the great IDE support we have - I hereby propose to retire the Antidote subproject.

Re: [VOTE] Alexey Solofnenko

+1 Conor MacNeill wrote: I would like to propose Alexey Solofnenko as an Ant committer. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: cvs commit: ant/src/main/org/apache/tools/ant/util FileUtils.java

Ok, I'll make this change. Martijn Kruithof wrote: +/** + * The granularity of timestamps under the NT File System. + * NTFS has a granularity of 100 nanoseconds, which is less + * than 1 millisecond, so we set this to 0. + */ +public static final long NTFS_FILE_TIMES

Re: [VOTE] Ant 1.6.4 release

Antoine Levy-Lambert wrote: Do we want to release ant 1.6.4 on Thursday, May 19th (this would at least suit Eclipse) +1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] migrate to svn

+1 [EMAIL PROTECTED] wrote: "Migrate Ant from CVS to SVN on the weekend of 13./14. August 2005." That would be the first weekend after the one-week voting timeframe. After passing the vote we should add a note on the homepage. --

Re: [VOTE] removal of dependency to xslp

[X] Yes [ ] No Antoine Levy-Lambert wrote: Hello, Do you want to remove from ant the usage of xslp, a library containing an XML transformation engine, the site where this transformation engine could be downloaded from no longer exists. XSL:P : used to live at

Re: [VOTE] removal of Visual for Java based tasks

[X] Yes [ ] No Antoine Levy-Lambert wrote: Hello, Do you want to remove from ant the usage of Visual Age for Java : see this document : [1] I believe that IBM has replaced Visual Age for Java with WSAD since a long time. Stefan Bodewig also wrote that the Visual Age Tasks in ant cannot work

Re: [VOTE] removal of icontract based task in ant

[X] Yes [ ] No Antoine Levy-Lambert wrote: Hello, Do you want to remove from ant the usage of icontract : see the documentation of the optional task icontract [1]. The link [2] contained in the page [3] listing the library dependencies of ant is dead. --

Re: [VOTE] removal of the test task based upon the org.apache.testlet framework

[X] Yes [ ] No Antoine Levy-Lambert wrote: Hello, Do you want to remove from ant the usage of the org.apache.testlet framework : see this document : [1] describing the optional task. ... [1] http://ant.apache.org/manual/OptionalTasks/test.html

Re: [vote] 'undeprecate project.resolveFile() [was Re: svn commit: r414442 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs: AbstractJarSignerTask.java ExecTask.java Javac.java Javadoc.java

I'm +1 for undeprecating. You make a good case that Project is doing too much, but I don't think that deprecating before a good solution is arrived at is a good idea. And a solution that breaks DRY and adds more code dependencies on the Singleton Antipattern is not a good solution IMHO. Mart

Re: [Vote] remove Xalan1 dependencies from codebase

+1, be my guest. Martijn Kruithof wrote: Still, I'd like to remove these classes and the dependencies towards these classes unless someone objects, so please vote [ ] Yes, be my guest, remove the dependencies towards xalan1 [ ] No, don't, these classes are still important (I know a place where

Re: [VOTE] Dropping Win98 Support for 1.7

+1. Conor MacNeill wrote: Considering that we are getting into the swing of releasing Ant 1.7, I would like to suggest that we drop Win98 support in Ant 1.7. The benefit will be to allow us to improve the Ant launch batch file as well as not having to test or support Win98, which we don't really

Re: Default excludes and Subversion on Windows

Steve Loughran wrote: Kev Jackson wrote: On 19 Aug 2006, at 02:06, Stefan Bodewig wrote: On Fri, 18 Aug 2006, Jan Materne <[EMAIL PROTECTED]> wrote: If we reject automatically handling _svn directories (as a "hack" as said by svn-people), we should document it in the manual of and svn-antl

Re: [VOTE] New committer - Jon Schneider

+1 for Jon Schneider as an Ant committer. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org

Re: [VOTE] Accept Groovy-Front Donation

+1. Stefan Bodewig wrote: Hi, Nicolas wants to donate his ProjectHelper implementation that allows build files to be written in Groovy. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail

Re: Maybe we should open up "depends" for all targets [again]

Xavier Hanin wrote: 2009/12/10 Stefan Bodewig and would do away with any notion of target composition people way expect from the name target-*group*. I also think the name target-group is confusing for something that doesn't provide any composition. Still I'm not sure dependencies=

Re: deep-if/deep-unless

I think that would be very confusing at this point. For better or worse, Ant was designed from the beginning to build its dependencies through backwards chaining. It is often (usually) surprising behaviour to the first time user, but once learned quickly becomes second nature. Introducing a new

Re: [POLL] target-groups

Sorry if the previous thread was hijacked by naming issues, but I'm not sure I'm ready to vote in a poll yet. To me, only two of the options are seriously being discussed right now: 1) the current target-group codebase 2) moving the behaviour of target-group into all targets through a marker

Re: [POLL] target-groups

e current code base. Dominique Devienne wrote: On Tue, Dec 15, 2009 at 7:53 PM, Bruce Atherton wrote: Can anyone give a concrete example where there would be a problem treating a target-group as if it were a target? Can't. But my thinking is that we should ere on the conservati

Re: Naming of target-group

Coming into this thread I didn't really have an opinion, but I like this reasoning. +1 for both. Nicolas Lalevée wrote: Well, the main use case I see of target groups is about using them between different build scripts, as also noted in the documentation Stefan just wrote. So the "extension po

Re: [VOTE] name for target-group

Stefan Bodewig wrote: Currently I don't have strong feelings either way, I prefer extension-point slightly, but can certainly live with target-group. I'll go with the majority. Exactly my feeling. +1 for extension-point/extensionOf, happy with target-group (with or without the dash) if that

Re: [VOTE] release ant 1.8.0RC1

Just minor nits in the release notes, nothing important enough to hold anything up: 1. On the line describing , we have: This method is now used to define conditions, selectors and selectors. Was the second selectors meant to be filtersets? 2. This is just a style issue: Remove fall-ba

Re: svn commit: r894462 - in /ant/core/trunk: WHATSNEW docs/manual/CoreTypes/filterchain.html src/main/org/apache/tools/ant/filters/AppendToLines.java src/main/org/apache/tools/ant/types/FilterChain.j

While you are undeniably technically right that suffixlines is a better match with prefixlines, which of the three sounds better and is going to be clearer to users: appendtolines, suffixlines, or postfix lines. If I had to choose one, I'd go with appendtolines, with suffixlines a close second

Re: AW: svn commit: r894462 - in /ant/core/trunk: WHATSNEW docs/manual/CoreTypes/filterchain.html src/main/org/apache/tools/ant/filters/AppendToLines.java src/main/org/apache/tools/ant/types/FilterCha

Antoine Levy Lambert wrote: Do we need a formal vote for this, or should someone just go ahead and change the code/documentation/tests accordingly ? This hardly seems controversial enough for a vote. I haven't seen a single person take a position against suffixlines. I'd suggest the change

Re: [VOTE] [second attempt] release of ant 1.8.0

+1 from me. Antoine Levy Lambert wrote: Hi, this vote cancels and replaces the vote started on Friday. The vote of Friday is cancelled because of a bug affecting the junit task which would have suppressed the stack traces of failing tests. The new build incorporates the fix for the junit s

Re: task that allows augmentation of previously declared references

I agree. I see that the intent in such a final attribute is to keep a build system understandable at a local level without worrying about what external entities might do, but if you feel that way don't use augmentation in your build system. The only reasons I use final keyword in programming ar

Re: task that allows augmentation of previously declared references

mperative style). And in a declarative language, it is much more unusual to overwrite/modify the declaration. Immutability has great value in declarative language. Gilles Scokart On 25 March 2010 23:58, Bruce Atherton wrote: I agree. I see that the intent in such a final attribute is

Re: Augment feature

On 06/04/2010 8:16 AM, Jean-Louis Boudart wrote: The objective of this thread is to take a decision on : - restriction on augment feature - and if the vote is in favor to choose one implementation design to do it So, What's your opinion ? My opinion is that what we really need

[Vote] Augment feature

Ok, so this didn't start out as a vote thread, just my suggestion for what questions should appear in the vote. But since it has morphed into that I've changed the subject line to make it easier for people to find. So the questions are: 1. Are you in favor of adding the augment feature to Ant?

Re: [Vote] Augment feature

On 13/04/2010 3:34 PM, Bruce Atherton wrote: 1. Are you in favor of adding the augment feature to Ant? +1 2. Are you in favor of an attribute that allows references to be marked as final, to avoid augmentation? -0 3. If a final attribute is decided upon, do you think it should

[Result][Vote] Augment feature

I lost my email server for a few days, so I can only now close the vote and post the results. I believe that between my returned email feed and the record of posts on MarkMail[1] I have all the results. If you feel your vote was missed, let me know. On question 1, whether to adopt the augment

Re: Augment feature

I just wanted to let Jean Louis and Martijn know not to give up hope on the enhancements they'd like to see. Jean Louis, although the vote was not in favour of the final feature, it was not against it, either. Half the community seemed to think it was a good idea, although they didn't want to

Re: [POLL] Bug 48804

I think that since the code doesn't address the primary usecase, that trumps pretty-well all considerations. It is hard to imagine how someone would be relying on the order of the extension point/extension evaluation in order to avoid the extension point. Since the behaviour isn't documented a

Re: Bug 49261 - and Read-Only Destination Files

On 07/05/2010 7:52 AM, Stefan Bodewig wrote: First of all I must admit that I like the idea of not overwriting read-only files better than the old behavior. Agreed. Although it breaks backward compatibility to change this, it so violates POLA[1] that I think it needs changing. Independe

Re: 1.8.1

Ditto. Great work, Antoine. On 08/05/2010 3:44 AM, Kevin Jackson wrote: Hi sorry I didn't even get chance to download and test this release this time :( Good work on getting a point release done so quickly Kev - To unsubscrib

Re: Bug 49261 - and Read-Only Destination Files

On 10/05/2010 8:27 AM, Stefan Bodewig wrote: you won't like what I'm going to say 8-) Oh man, it is never easy, is it? The following non-deprecated tasks use copyFile or copyResource as well: , the WebLogic deployment tool,,. and . For most of them I'd be willing to accept the backward

Re: Bug 49261 - and Read-Only Destination Files

On 11/05/2010 2:56 AM, Stefan Bodewig wrote: On 2010-05-10, Bruce Atherton wrote: 1) On Concat, add an overwrite attribute and mark the force attribute as deprecated with a warning 2) Add force to copy, echo, etc 3) add forceReadOnly to Concat this is now the case in

  1   2   >