Re: [VOTE] Release Ant 1.9.2

+1. Thanks for doing this, Stefan. On 13-07-09 04:04 AM, Stefan Bodewig wrote: I propose to adopt the following as Ant 1.9.2 SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_192/ revision 1500831 Tarballs: https://dist.apache.org/repos/dist/dev/ant/ revision 2394 Maven Artif

[RESULT][VOTE] Michael Clarke as a committer

s for getting set up as a committer. +1 Votes: Bruce Atherton Maarten Coene Jean-Louis Boudart Antoine Levy Lambert Martin Gainty Stefan Bodewig Jan Matèrne Conor MacNeill Peter Reilly Martijn Kruithof Jesse Glick -1 Votes: ±0 Votes: Thanks to everyon

[VOTE] Michael Clarke as a committer

I'd like to nominate Michael Clarke as a committer. Not only has he revamped our testing infrastructure to make it compatible with JUnit4, he has also worked on resolving older bugs in our bugzilla that touched on testing. Let's vote on it. [ ] +1 to add Michael Clarke as a committer [ ] -1 to

Re: [VOTE] Ant 1.9.0 release [2nd attempt]

the Ant web site. Regards, Antoine On Mar 8, 2013, at 3:49 PM, Bruce Atherton wrote: Good catch, Jesse. I have to admit I find the lack of a mention of requiring Java 5 troubling. That is definitely a difference people are going to care about. Is it possible to sneak that edit in to the

Re: [VOTE] Ant 1.9.0 release [2nd attempt]

Good catch, Jesse. I have to admit I find the lack of a mention of requiring Java 5 troubling. That is definitely a difference people are going to care about. Is it possible to sneak that edit in to the WHATSNEW file (in both the bin and src packages) without a whole new revote? On 13-03-08

Re: [VOTE] Accept EasyAnt as a subproject - take 2

A great big +1. With Ivy, we decided that having a separate users mailing list made sense but that we were better off having a single developers mailing list for both projects. I suggest we do the same again with EasyAnt assuming the vote is successful this time, unless the EasyAnt committers

Re: Ant 1.9.0

Thanks very much, Antoine. It's appreciated. On 13-01-31 06:11 PM, Antoine Levy Lambert wrote: Hello Bruce, I can see myself implementing the removal of the Perforce Ant tasks, this should be pretty straightforward. I will work on this this week-end. Regards, Antoine ---

Re: Ant 1.9.0

We've discussed this before[1] and already voted in favour of removing the commercial tasks from Ant some time ago[2]. A complication was that we wanted to create AntLibs for them if we couldn't get the vendors to support them directly so that there was minimal upset for our users, but apart fr

Re: [VOTE] Jean-Louis Boudart as committer

+1 On 12-10-23 01:58 AM, Nicolas Lalevée wrote: Jean-Louis has been nicely involved with both Ant and Ivy for some time. Let's vote to invite him to be an Ant committer. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.o

Re: [VOTE] Accept EasyAnt as a subproject

On 12-07-19 02:50 AM, Jean-Louis Boudart wrote: > This topic doesn't look like popular :) > > Should we consider this silence as a "no go"? Well, I haven't seen any disagreement with the proposal. It looks more like just a general lack of participation in the dev group, partly from the fact tha

Re: [VOTE] Accept EasyAnt as a subproject

I think this is a great idea, particularly if we can get the committers of EasyAnt interested in improving Ant and Ivy. +1. Would it be worthwhile to consider all the committers on EasyAnt as committers on Ant if this is adopted? As I recall, that is what happened with Ivy. On 12-07-11 01:4

Re: Wiki Spam Problems

I think we need to do everything we can to prevent spam and minimize the maintenance required from this all-volunteer group. I'm a bit confused, though. I thought that we already had a contributor group. Didn't you make a change to the Front page announcing it as well as mentioning it on the A

Re: [VOTE] Release Apache Compress Antlib 1.2

+1 On 4/16/2012 11:39 AM, Stefan Bodewig wrote: following the 1.4 release of Apache Commons Compress I've prepared a new release of the Compress Antlib. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional c

Re: Merging to the 1.8.x branch

I agree. Option 2 is the better choice. Changesets on trunk can be Java5 specific. It would be problematic to have to also include tested Java 1.4 versions on a 1.8 branch that may never see the light of day. If there are bug fixes that need to go into a future 1.8.4 release we can deal with t

Re: [ANNOUNCE] Apache Ant 1.8.3 Released

Thanks for doing this, Stefan. On 2/29/2012 9:07 PM, Stefan Bodewig wrote: The Apache Ant Team is proud to announce the 1.8.3 release of Ant. Apache Ant is a Java based build tool. Version 1.8.3 is a bug fix release with small fixes and improvements accross many tasks. The Ant developers have

Re: [VOTE] Release Ant 1.8.3 Take 2

+1, seems fine to me. On 2/25/2012 10:25 PM, Stefan Bodewig wrote: This next attempt is based on the same code base as the last release candidate plus Jesse's fix for the "macrodef-attributes must get properties expanded twice" issue. In addition some of the build/release fixes I had to perform

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

On 2/21/2012 12:22 PM, Bruce Atherton wrote: It sounds like you are both are on a similar wavelength. Let me see if I understand. A new style of build (while maintaining the old style, of course) would be to declare some combination of resources to have similar states and transitions bet

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

It sounds like you are both are on a similar wavelength. Let me see if I understand. A new style of build (while maintaining the old style, of course) would be to declare some combination of resources to have similar states and transitions between states. So something like this (just as an exa

Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)

Unit testing has long been considered important for Ant. A published report a few years ago (can't find it now) showed our code coverage was among the highest of the open source projects that they reported on, as I recall. It has often happened that committers push back on code submissions aski

Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)

I have similar thoughts on the high level abstract view of Ant. Here is how I see it: 1. Command Line Processor 2. Build File Parser 3. Dependency Tree Resolver - This is essentially a Dependency Injection/IOC system, but with late binding (Unknown Element) and modification through things l

Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)

nt and maintain. If it is design is modular, I think all these can be added as plugins. Performance ??!! On Sat, Feb 18, 2012 at 1:47 PM, Bruce Atherton wrote: This too I find a great idea. Multicores mean we need more ways of exploiting parallelism, particularly if they can be identified autom

Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)

rent state). Gilles Scokart On 17 February 2012 20:07, Bruce Atherton wrote: It doesn't require a rewrite, but a rewrite could simplify integrating a usecase like this as well as integrating other features that we already have into it and making them simpler and unified inthe code. I ag

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

have, both in the standard class libraries and in Ant itself. Just an idea off the top of my head. On 2/17/2012 5:53 AM, Dominique Devienne wrote: 2012/2/17 Bruce Atherton: A lot of companies have their own, internally written build file generators just so their build systems are consistent and ex

Reasons why Java 7 got me excited about Ant 2

I thought I'd expand on why I got so excited about NIO 2.0 and JSR 203 as well as the other changes in Java 7. I can see I have done a bad job of selling the benefits of a refactoring for potential volunteers. Reading through the changes that were introduced in Java 7, it seems to me that Ant w

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

On 2/16/2012 2:36 PM, Nicolas Lalevée wrote: Le 16 févr. 2012 à 20:47, Bruce Atherton a écrit : I'd hope to go further than that in backwards compatibility. I work with a lot of companies that are: a) resistant to learning new things unless there is a good reason for it (such a

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

It has but not for quite a long time. Look in the archives from 2001 to 2003 for "Mutant"[1] which Conor proposed, and "Myrmidon"[2] which Peter Donald proposed back in 2000. You can still find them in the svn repository[3], [4]. I think there was so much discussion on a new design of Ant tha

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

Oops, accidental deletion. On 2/16/2012 11:47 AM, Bruce Atherton wrote: b) have a number of separate Ant build scripts that follow different standards in different areas of the company, particularly if they have acquired other companies with their own Ant builds

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

point where new builds could think about using a new build format automatically, just based on file extension or a flag on the command line. That might encourage new projects to adopt it. On 2/16/2012 10:57 AM, Nicolas Lalevée wrote: Le 14 févr. 2012 à 20:02, Bruce Atherton a écrit : On 2/14/2

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

On 2/15/2012 5:48 PM, Bruce Atherton wrote: I've read a blog post that said that one of the requirements that has been adopted is OSGI compatibility... Here is the post I mentioned: http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html It brings up a good

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

Those changes you have sound useful. Good luck with getting them cleared, I'm sure a number of people would appreciate having access to those hooks. I think adding the standard packaging and deployment mechanism of Java 8 to Antlibs once 8 comes out makes a lot of sense. Once that happens som

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

On 2/13/2012 2:55 PM, Jesse Glick wrote: On 02/13/2012 01:25 PM, Bruce Atherton wrote: could Java 7 and NIO 2.0 be a good reason to create Ant 2.0? While the new java.nio.file.* APIs are indeed valuable for a tool like Ant, I hardly think a fork or major rewrite is required to take

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

On 2/14/2012 6:13 AM, Stefan Bodewig wrote: This will lead us to the discussion of what Ant2 would be. A rewritten Ant that remains compatible (or mostly so) on the build file level or something quite different? My opinion. I think we need at least an option for being backwards compatible a

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

This brings up a point to consider if a rewrite is desired. Ant has always avoided relying on external libraries because it is usually the first thing in the build chain. It can't have any dependencies itself if it is to be self-building. There are tasks that require external libraries to be co

NIO 2.0 == Ant 2.0? was Re: Java NIO support

I actually wanted to discuss Java 7 on the list. I went through its features a while ago and got really excited when I read through NIO 2.0. It does so much that Ant has to struggle with, and so much that Ant can't do. I spent some time starting to implement a very simple (only a few tasks) n

Re: [VOTE] Drop JDK 1.4 after 1.8.3

+1 On 1/27/2012 10:42 AM, Jesse Glick wrote: [X] +1: announce that 1.8.3 will be the last version of Ant to support JDK 1.4, and after it is branched, permit trunk sources to assume JDK 5+, updating CI jobs accordingly [ ] ±0: not sure, maybe continuing to support JDK 1.4 is useful, leave it

Re: 1.8.3?

That's wonderful. Thanks for your efforts getting this done. On 1/26/2012 9:19 AM, Stefan Bodewig wrote: Hi all, Obviously I didn't manage to look through bugzilla last weekend, my family had different plans (and I thank them). One thing I want to do is giving a recent OpenJDK8 snapshot a try

Re: [VOTE] Release Compress Antlib 1.1 based on RC1

+1 On 01/11/2011 11:22 PM, Stefan Bodewig wrote: Should this be released as the Compress Antlib 1.1? Vote will be open for at least 72 hours (closing no earlier than November 5th, 0630 UTC). - To unsubscribe, e-mail: dev-un

Re: svn commit: r1154551 - in /ant/core/trunk/src: main/org/apache/tools/ant/taskdefs/optional/junit/JUnitTestRunner.java tests/antunit/taskdefs/optional/junit/xmlformatter-test.xml

On 06/08/2011 10:21 AM, Stefan Bodewig wrote: On 2011-08-06, wrote: URL: http://svn.apache.org/viewvc?rev=1154551&view=rev Log: never filter out the first line of the exception stack trace in junit so the failure message is preserved The rationale is that since a few releases the word "more"

Re: [VOTE] Second Attempt to Release .NET Antlib 1.1

On 27/01/2011 9:02 PM, Stefan Bodewig wrote: I hereby call for a vote to release these files as Apache .NET Ant Library 1.1. +1 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...

Re: [VOTE] third attempt - release of ant 1.8.2

+1 On 20/12/2010 10:55 AM, Antoine Levy-Lambert wrote: Hi, The first release candidate of ant 1.8.2 got several binding +1s and a -1 concerning an issue with the use of the JUnit task with selective methods and JUnit 4 style coding [1]. So I addressed these concerns and rebuilt a release ca

Re: Can Anybody Fix our Logos?

I'd have to go back in the archives, but I have a pretty clear recollection that while we had asked for a vector format for the logo after the contest winner was announced, none was available. I don't recall whether that was because we never got a response from Nick Wood or because the vector f

Re: [VOTE] Accept Bushel Donation

+1. On 05/11/2010 7:45 AM, Stefan Bodewig wrote: So, do we want to accept the Bushel donation? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org

Re: Vote to promote VSS antlib out of sandbox

We've already had a vote on this which passed. http://marc.info/?l=ant-dev&m=127697274731069&w=2 I'd change point c to just removing the old code from core. On 31/08/2010 5:33 PM, Kevin Jackson wrote: c: vote to remove the old vss code from core/trunk (as it won't be needed) -

Re: Vote to promote VSS antlib out of sandbox

+1 On 24/08/2010 11:53 PM, Kevin Jackson wrote: The VSS antlib[1] should be promoted from sandbox [1]http://svn.apache.org/viewvc/ant/sandbox/antlibs/vss/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additi

Re: [VOTE] Apache Compress Antlib 1.0 - Take 2

+1 On 22/08/2010 10:15 PM, Stefan Bodewig wrote: Hi, I've created new distribution artifacts without the empty WHATSNEW file and a README.html that points to the docs directory. I'd like to release this is Apache Compress Antlib 1.0 so please vote. Stefan

Re: [VOTE] Release Apache Compress Antlib 1.0

I notice that the README.html and WHATSNEW are empty apart from headers. This strikes me as a little odd, particularly the README.html which I would have expected to include instructions on how to deploy the Antlib in Ant. Assuming this omission was intentional, though, I'll give a +1. On 19

Re: [VOTE] Release Manuals of Last Five Ant Releases

+1 On 19/07/2010 7:21 AM, Stefan Bodewig wrote: [ ] +1 release them [ ] 0 don't care [ ] -1 no, don't release them - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.a

Re: Distributing Docs: Manual or whole Site?

I'm fine with just the manual and Javadocs. For the rest of the web site, users of older versions could just consult the live site. I don't think we make a lot of changes to the rest of the site that lose information or mislead about behaviour that is applicable to older versions, the way the

Re: Contacting vendors

On 06/07/2010 1:57 AM, Kevin Jackson wrote: How about adding that of course the customers can continue to use the current version of Ant as is with the tasks integrated and that it will only affect people that use the latest versions (ok my wording is crappy, but to let them know that we're not d

Contacting vendors (was [RESULT][VOTE] Remove commercial tasks from Ant)

On 30/06/2010 4:43 AM, Jan Matèrne wrote: Could you provide a mail 'template' we could use? I could try to contact the Synergy-people at IBM. Sure. How about this as a first attempt. Feedback and suggestions appreciated. -- On behalf of the Apache Ant Project, I am writing to let you kn

[RESULT][VOTE] Remove commercial tasks from Ant

The results of the vote are in. Both motions passed. The motion to drop the commercial tasks from the binary release of Ant had 13 +1 votes for almost all the commercial tasks, and no -1 votes. The one exception was the Server Deploy subtasks, which Gilles voted +0 on, resulting in 12 +1 votes

Re: [VOTE] Remove commercial tasks from Ant

On 19/06/2010 11:38 AM, Bruce Atherton wrote: 1. Should the following commercial tasks be dropped from being distributed with the Ant release? [ ] Continuous/Synergy tasks: CCMCheckin, CCMCheckout, CCMCheckinTask, CCMReconfigure, CCMCreateTask [ ] Clearcase tasks: CCCheckin, CCCheckout

[VOTE] Remove commercial tasks from Ant

Ant supplies several tasks that require commercial software in order to run. This is a problem because the Ant developers do not typically have access to the commercial products required to test, maintain, and enhance the tasks. It also means that users downloading the binary edition of Ant end

Re: what to expand?

On 18/06/2010 7:48 AM, Dominique Devienne wrote: On Fri, Jun 18, 2010 at 2:47 AM, Stefan Bodewig wrote: On 06/17/2010 11:10 AM, Stefan Bodewig wrote: Assume x=x y=${x} and that there is no property x defined prior to then ${y} will be "x". Using ${foo.y} in Ant 1.8.0 is ${x

Re: [DISCUSS] Commercial Tasks in Ant

On 01/06/2010 7:51 AM, Stefan Bodewig wrote: On 2010-05-29, Bruce Atherton wrote: I'd like to discuss whether to move all of the commercial tasks out of Ant core/optional libraries and putting them each into their own Antlibs. +1 - I'm not sure we must stop at the comme

Re: Visual SourceSafe Antlib

On 08/06/2010 7:08 AM, Stefan Bodewig wrote: Can the tests depend on cleanup? Sorry, I haven't actually looked into the build file but thought I might toss out the idea anyway. Sure they could, but then you couldn't examine the repository to make sure everything is being stored as expecte

Visual SourceSafe Antlib (was [DISCUSS] Commercial Tasks in Ant)

On 02/06/2010 8:14 PM, Kevin Jackson wrote: - Microsoft Visual SourceSafe: already an Antlib, just need the vote to get it out of Ant core/optional and to get a release. I did the work for this, but could never get the requisite number of votes for this to be released. I've g

[DISCUSS] Commercial Tasks in Ant

There are a number of tasks in Ant that require commercial software in order to run. This is problematic in a couple of ways: 1) The Ant developers usually do not have access to the commercial software, and so cannot confirm that existing code or submitted patches work correctly.

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

On 28/05/2010 8:31 AM, Stefan Bodewig wrote: I'm thinking about putting together a tiny jar that contains a command line Java main class that compares System.getEnv and Ant's traditional way on the current system and then ask on our user list whether anybody there was willing to run it on the mor

Re: JAI and NetRexx in fetch.xml (Was: Ant source structure and ant*.jar build products)

On 19/05/2010 11:27 AM, Gilles Scokart wrote: For JAI, note that the maven distribution is just the pom, with an url that that should be used manually. I did notice this on ibiblio when I went to actually implement the target in fetch.xml, but I also found the full jar file in the JBoss p

Re: [VOTE] Ant source tree reorganization

On 17/05/2010 7:11 PM, Jesse Glick wrote: Should the Ant source tree (src/main/ and perhaps also src/tests/) be split into subtrees? [ ] No, leave it the way it is - one big tree, using to conditionally compile pieces and route classes to various JARs. [ ] Yes, split it into subtrees, where

Re: Ant source structure and ant*.jar build products

On 16/05/2010 9:35 PM, Stefan Bodewig wrote: If you wanted to merge ant.jar with ant-nodeps.jar (which would be fine with me) we should probably move all tasks included from optional to core inside the manual as well since the distinction would make even less sense after that. +1. Then the

Re: Ant source structure and ant*.jar build products

Oh boy, was I ever confused. Thanks for the clarification. On 16/05/2010 4:52 PM, Antoine Levy-Lambert wrote: Bruce, I believe that Jesse meant something like "One jar should be built from each source root". In fact his proposition does not change the number of jars produced in the ant distribu

Re: Ant source structure and ant*.jar build products

On 15/05/2010 11:34 AM, Bruce Atherton wrote: Anyway, my point is that if we go for one big jar and include fetch.xml behaviour in the standard build, then we don't need to break the source directories apart. Sorry, I realized that I was conflating the distribution with working wit

Re: Ant source structure and ant*.jar build products

On 14/05/2010 3:56 PM, Antoine Levy-Lambert wrote: Jesse Glick wrote: In relation to : Ironically enough, I find the Ant build script to be a poor example of an Ant script. The system of compiling certain classes and not others accor

Re: AW: [VOTE] use nexus for maven upload of ant release

+1 to all these good ideas, including the three on the original vote. On 14/05/2010 2:35 AM, jan.mate...@rzf.fin-nrw.de wrote: If using Nexus is the "official way" I am +1 for uploading Ant, Antlibs and Ivy. This wasnt part of the vote, but I am also +1 for putting the upload procedure in a com

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

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: 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 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: [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: 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

[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: [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

[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: 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

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: 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: [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: 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: 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: [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: [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: 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: [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: [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: 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: 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: [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: [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: [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: 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: 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: 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: 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

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: 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: [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: 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: 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

  1   2   >