Re: [VOTE] Remove commercial tasks from Ant
On Fri, Jun 25, 2010 at 6:14 AM, Bruce Atherton br...@callenish.com wrote: 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, CCUnCheckout, CCUpdate, CCMklbtype, CCMklabel, CCRmtype, CCLock, CCUnlock, CCMkbl, CCMkattr, CCMkdir, CCMkelem [ ] Perforce Tasks: P4Sync, P4Change, P4Edit, P4Submit, P4Have, P4Label, P4Labelsync, P4Counter, P4Reopen, P4Revert, P4Add, P4Delete, P4Integrate, P4Resolve, P4Fstat [ ] PVCS [ ] ServerDeploy, but only for the jonas and weblogic nested elements, generic can stay where it is. [ ] Source Offsite: sosget, soslabel, soscheckin, soscheckout [ ] Microsoft Visual SourceSafe (already an Antlib) +1 to all + 1 to all 2. Should the commercial tasks that are voted for dropping from Ant core above be established in their own Antlibs in the sandbox? [ ] +1 = Yes, establish one new Antlib in the sandbox for each task dropped -1 = No, just drop the commercial tasks altogether from Ant +1 +1 Peter - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Remove commercial tasks from Ant
On 19-6-2010 20:38, Bruce Atherton wrote: 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 up with a lot of tasks that they cannot use. In order to rectify this situation, I'm calling a vote on how to deal with these unsupportable tasks. The vote is composed of two parts: should we drop support for each of these tasks from the Ant release, and should we establish the commercial tasks that have been dropped as Antlibs in the sandbox. 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, CCUnCheckout, CCUpdate, CCMklbtype, CCMklabel, CCRmtype, CCLock, CCUnlock, CCMkbl, CCMkattr, CCMkdir, CCMkelem [ ] Perforce Tasks: P4Sync, P4Change, P4Edit, P4Submit, P4Have, P4Label, P4Labelsync, P4Counter, P4Reopen, P4Revert, P4Add, P4Delete, P4Integrate, P4Resolve, P4Fstat [ ] PVCS [ ] ServerDeploy, but only for the jonas and weblogic nested elements, generic can stay where it is. [ ] Source Offsite: sosget, soslabel, soscheckin, soscheckout [ ] Microsoft Visual SourceSafe (already an Antlib) +1 2. Should the commercial tasks that are voted for dropping from Ant core above be established in their own Antlibs in the sandbox? [ ] +1 = Yes, establish one new Antlib in the sandbox for each task dropped -1 = No, just drop the commercial tasks altogether from Ant Note that question 1 is a vote for code modification, so any -1 vote on question 1 is considered a veto. Question 2 is just for guidance from the community about whether there is a desire to keep the commercial tasks around in Antlibs. Since any committer can create a sandbox Antlib at any time, the vote is non-binding and any -1 vote just indicates that the voter does not think that this is a good idea rather than being a veto. +1 Three or more +1 votes with no -1 votes are required for dropping any of the commercial tasks. The vote will end in one week. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: [Proposal] Capture attributes in unknown namespaces
Other point: we have an implementation in the sandbox https://svn.apache.org/repos/asf/ant/sandbox/parallelexecutor Maybe you could use some code ;-) Jan -Ursprüngliche Nachricht- Von: Dominique Devienne [mailto:ddevie...@gmail.com] Gesendet: Donnerstag, 24. Juni 2010 23:12 An: Ant Developers List Betreff: Re: [Proposal] Capture attributes in unknown namespaces On Thu, Jun 24, 2010 at 2:50 PM, Danny Yates da...@codeaholics.org wrote: What would be kind of cool would be that if the parser encounters attributes in a namespace that it doesn't recognise, then instead of ignoring them (as it does now), it records them and makes them available through an API on the Project and Target objects. This would allow the executor to inspect them. Something related to that was discussed in the past to allow arbitrary cross-cutting attributes to be added to tasks which wouldn't normally support them, typically in the context of adding global ant:if and ant:unless attributes (or maybe I just thought about it, I'm no longer sure ;) I realise this is very specific to my parallel executor project, but I think adding it would be a non-breaking change that wouldn't have any impact on existing consumers of the API. True. But I'd be more in favor of an opt-in framework, where you explicitly tell Ant to record attributes from specific namespaces. From the list, I think other people also use extra markup in their builds for external tools, so in their case they don't need to record those attributes for examples. What do you folks think? I think it's a good idea. There are design considerations like, should it be free form string=string recorded as-is, or should these attributes be processed like ordinary attributes Ant deals with to do property expansion and conversion to Java types (like boolean accepting true/on/yes as a true). For example, imagine you group your extra attributes into a DataType part of an AntLib bound to that extra namespace, the DataType could be instantiated as usual by Ant provided it looked at the UnknownElement specifically for a given namespace, and then the DataType is bound somehow to the task or type or target. That way everything is typed as usual, and could be made to reuse a lot of the existing code/facilities. See what I mean? --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: [Proposal] Capture attributes in unknown namespaces
btw - when using parallel executors the problem of parallel logging output must be resolved ;-) Jan -Ursprüngliche Nachricht- Von: jan.mate...@rzf.fin-nrw.de [mailto:jan.mate...@rzf.fin-nrw.de] Gesendet: Freitag, 25. Juni 2010 12:46 An: dev@ant.apache.org Betreff: AW: [Proposal] Capture attributes in unknown namespaces Other point: we have an implementation in the sandbox https://svn.apache.org/repos/asf/ant/sandbox/parallelexecutor Maybe you could use some code ;-) Jan -Ursprüngliche Nachricht- Von: Dominique Devienne [mailto:ddevie...@gmail.com] Gesendet: Donnerstag, 24. Juni 2010 23:12 An: Ant Developers List Betreff: Re: [Proposal] Capture attributes in unknown namespaces On Thu, Jun 24, 2010 at 2:50 PM, Danny Yates da...@codeaholics.org wrote: What would be kind of cool would be that if the parser encounters attributes in a namespace that it doesn't recognise, then instead of ignoring them (as it does now), it records them and makes them available through an API on the Project and Target objects. This would allow the executor to inspect them. Something related to that was discussed in the past to allow arbitrary cross-cutting attributes to be added to tasks which wouldn't normally support them, typically in the context of adding global ant:if and ant:unless attributes (or maybe I just thought about it, I'm no longer sure ;) I realise this is very specific to my parallel executor project, but I think adding it would be a non-breaking change that wouldn't have any impact on existing consumers of the API. True. But I'd be more in favor of an opt-in framework, where you explicitly tell Ant to record attributes from specific namespaces. From the list, I think other people also use extra markup in their builds for external tools, so in their case they don't need to record those attributes for examples. What do you folks think? I think it's a good idea. There are design considerations like, should it be free form string=string recorded as-is, or should these attributes be processed like ordinary attributes Ant deals with to do property expansion and conversion to Java types (like boolean accepting true/on/yes as a true). For example, imagine you group your extra attributes into a DataType part of an AntLib bound to that extra namespace, the DataType could be instantiated as usual by Ant provided it looked at the UnknownElement specifically for a given namespace, and then the DataType is bound somehow to the task or type or target. That way everything is typed as usual, and could be made to reuse a lot of the existing code/facilities. See what I mean? --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: AW: AW: Hudson target to build Ant via Maven
Added the ignore=true part as MAVEN_OPTS. Building modules in parallel. Abort stuck builds after 30 minutes and let the job fail then. But haven't found the place for the patternset. The job is a Maven2-Job and AFAIK Hudson retrieves these information only from the poms, right? Jan -Ursprüngliche Nachricht- Von: Jesse Glick [mailto:jesse.gl...@oracle.com] Gesendet: Donnerstag, 24. Juni 2010 18:16 An: dev@ant.apache.org Betreff: Re: AW: AW: Hudson target to build Ant via Maven On 06/24/2010 10:17 AM, jan.mate...@rzf.fin-nrw.de wrote: But now it seems that the dependencies arent resolved... I am fixing that; include/exclude problems in POMs. But there are tons of test failures (not yet sure why); the job will need to pass: -Dmaven.test.failure.ignore=true and then include target/*/surefire-reports/TEST-*.xml in Hudson's test report patternset. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Proposal] Capture attributes in unknown namespaces
Yes, I nabbed an alternative logger from a similar project :-) Basically, it outputs when a target starts and when it finishes, and for each task it outputs [target/task] instead of just [task] so you can see what's going on. I can't claim any responsibility for it though! On 25 June 2010 11:48, jan.mate...@rzf.fin-nrw.de wrote: btw - when using parallel executors the problem of parallel logging output must be resolved ;-) Jan -Ursprüngliche Nachricht- Von: jan.mate...@rzf.fin-nrw.de [mailto:jan.mate...@rzf.fin-nrw.de] Gesendet: Freitag, 25. Juni 2010 12:46 An: dev@ant.apache.org Betreff: AW: [Proposal] Capture attributes in unknown namespaces Other point: we have an implementation in the sandbox https://svn.apache.org/repos/asf/ant/sandbox/parallelexecutor Maybe you could use some code ;-) Jan -Ursprüngliche Nachricht- Von: Dominique Devienne [mailto:ddevie...@gmail.com] Gesendet: Donnerstag, 24. Juni 2010 23:12 An: Ant Developers List Betreff: Re: [Proposal] Capture attributes in unknown namespaces On Thu, Jun 24, 2010 at 2:50 PM, Danny Yates da...@codeaholics.org wrote: What would be kind of cool would be that if the parser encounters attributes in a namespace that it doesn't recognise, then instead of ignoring them (as it does now), it records them and makes them available through an API on the Project and Target objects. This would allow the executor to inspect them. Something related to that was discussed in the past to allow arbitrary cross-cutting attributes to be added to tasks which wouldn't normally support them, typically in the context of adding global ant:if and ant:unless attributes (or maybe I just thought about it, I'm no longer sure ;) I realise this is very specific to my parallel executor project, but I think adding it would be a non-breaking change that wouldn't have any impact on existing consumers of the API. True. But I'd be more in favor of an opt-in framework, where you explicitly tell Ant to record attributes from specific namespaces. From the list, I think other people also use extra markup in their builds for external tools, so in their case they don't need to record those attributes for examples. What do you folks think? I think it's a good idea. There are design considerations like, should it be free form string=string recorded as-is, or should these attributes be processed like ordinary attributes Ant deals with to do property expansion and conversion to Java types (like boolean accepting true/on/yes as a true). For example, imagine you group your extra attributes into a DataType part of an AntLib bound to that extra namespace, the DataType could be instantiated as usual by Ant provided it looked at the UnknownElement specifically for a given namespace, and then the DataType is bound somehow to the task or type or target. That way everything is typed as usual, and could be made to reuse a lot of the existing code/facilities. See what I mean? --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Proposal] Capture attributes in unknown namespaces
By the way, if you're interested in taking a look at my work, you can find it here: http://parallel-ant.googlecode.com/svn/trunk/ On 25 June 2010 11:59, Danny Yates da...@codeaholics.org wrote: Yes, I nabbed an alternative logger from a similar project :-) Basically, it outputs when a target starts and when it finishes, and for each task it outputs [target/task] instead of just [task] so you can see what's going on. I can't claim any responsibility for it though! On 25 June 2010 11:48, jan.mate...@rzf.fin-nrw.de wrote: btw - when using parallel executors the problem of parallel logging output must be resolved ;-) Jan -Ursprüngliche Nachricht- Von: jan.mate...@rzf.fin-nrw.de [mailto:jan.mate...@rzf.fin-nrw.de] Gesendet: Freitag, 25. Juni 2010 12:46 An: dev@ant.apache.org Betreff: AW: [Proposal] Capture attributes in unknown namespaces Other point: we have an implementation in the sandbox https://svn.apache.org/repos/asf/ant/sandbox/parallelexecutor Maybe you could use some code ;-) Jan -Ursprüngliche Nachricht- Von: Dominique Devienne [mailto:ddevie...@gmail.com] Gesendet: Donnerstag, 24. Juni 2010 23:12 An: Ant Developers List Betreff: Re: [Proposal] Capture attributes in unknown namespaces On Thu, Jun 24, 2010 at 2:50 PM, Danny Yates da...@codeaholics.org wrote: What would be kind of cool would be that if the parser encounters attributes in a namespace that it doesn't recognise, then instead of ignoring them (as it does now), it records them and makes them available through an API on the Project and Target objects. This would allow the executor to inspect them. Something related to that was discussed in the past to allow arbitrary cross-cutting attributes to be added to tasks which wouldn't normally support them, typically in the context of adding global ant:if and ant:unless attributes (or maybe I just thought about it, I'm no longer sure ;) I realise this is very specific to my parallel executor project, but I think adding it would be a non-breaking change that wouldn't have any impact on existing consumers of the API. True. But I'd be more in favor of an opt-in framework, where you explicitly tell Ant to record attributes from specific namespaces. From the list, I think other people also use extra markup in their builds for external tools, so in their case they don't need to record those attributes for examples. What do you folks think? I think it's a good idea. There are design considerations like, should it be free form string=string recorded as-is, or should these attributes be processed like ordinary attributes Ant deals with to do property expansion and conversion to Java types (like boolean accepting true/on/yes as a true). For example, imagine you group your extra attributes into a DataType part of an AntLib bound to that extra namespace, the DataType could be instantiated as usual by Ant provided it looked at the UnknownElement specifically for a given namespace, and then the DataType is bound somehow to the task or type or target. That way everything is typed as usual, and could be made to reuse a lot of the existing code/facilities. See what I mean? --DD - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Hudson target to build Ant via Maven
On 06/25/2010 06:52 AM, jan.mate...@rzf.fin-nrw.de wrote: Building modules in parallel. Good luck there... these are only modules by fiat; they share some source and target dirs. The include/exclude definitions very likely do not form a disjoint union of all source files, so I have no idea if parallel builds will work. But haven't found the place for the patternset. The job is a Maven2-Job Ah, I thought (*) you were using a freeform job (since the master POM is not at the top of the source tree). In that case Hudson ought to collect test results automatically and not abort the build if tests from a module fail. But again, with the pathological source layout it is hard to know whether everything will work automatically. (*) I'm not an admin so I can't see the job configuration. It is possible to configure Hudson to permit anonymous users to view /job/*/config.xml but probably this server does not. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Union + Tar
sweet. works like a charm (even though it is a bit non-intuitive). mind if i
submit a diff to the tar documentation page with this example?
jon
On Thu, Jun 24, 2010 at 9:10 PM, Stefan Bodewig bode...@apache.org wrote:
On 2010-06-25, Jon Stevens wrote:
Now, I'd like to reference that Union within a tarfileset... something
like this:
tar destfile=${target.dir}/${project.name}.tgz
compression=gzip
longfile=gnu
tarfileset prefix=lib
resources refid=all.classpath /
/tarfileset
/tar
I'm getting this error (ant 1.8.1):
only single argument resource collections are supported as archives
To tarfileset a nested resource defines the tar archive to read
TarResources from.
IIUC this is not what you want, you are using tarfileset because of the
prefix attribute, right? If so, use mappedresources instead.
tar destfile=${target.dir}/${project.name}.tgz
compression=gzip longfile=gnu
mappedresources
resources refid=all.classpath /
globmapper from=* to=lib/*/
/mappedresources
/tar
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Union + Tar
Ok, how do I do the same thing with the war task lib directory?
war
lib
need to put a reference to my union in here.
/lib
/war
jon
On Fri, Jun 25, 2010 at 9:47 AM, Jon Stevens latch...@gmail.com wrote:
sweet. works like a charm (even though it is a bit non-intuitive). mind if
i submit a diff to the tar documentation page with this example?
jon
On Thu, Jun 24, 2010 at 9:10 PM, Stefan Bodewig bode...@apache.orgwrote:
On 2010-06-25, Jon Stevens wrote:
Now, I'd like to reference that Union within a tarfileset... something
like this:
tar destfile=${target.dir}/${project.name}.tgz
compression=gzip
longfile=gnu
tarfileset prefix=lib
resources refid=all.classpath /
/tarfileset
/tar
I'm getting this error (ant 1.8.1):
only single argument resource collections are supported as archives
To tarfileset a nested resource defines the tar archive to read
TarResources from.
IIUC this is not what you want, you are using tarfileset because of the
prefix attribute, right? If so, use mappedresources instead.
tar destfile=${target.dir}/${project.name}.tgz
compression=gzip longfile=gnu
mappedresources
resources refid=all.classpath /
globmapper from=* to=lib/*/
/mappedresources
/tar
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
bug in DOMElementWriter
Say you have an element like this: foo attr=#10; / If you want to load that through an XMLFragment and then output it later, the DOMElementWriter.encode() method doesn't case properly for non-printable characters. The quick fix for me in this case was to overload that method and add this: case '\n': sb.append(#10;); break; Obviously, you'd want a more complete encoding of all possible values. jon
