Re: missing extension-point behaviour
On 2010-06-23, Danny Yates wrote: Also, I'd really like it so that I don't have to subant (or ant or antcall or whetever) into the service-specific scripts, because there are (will be) a large number of touch points, and I don't want to have to go and find each of them whenever a new service is added. This is how I understood it. You are using wildcard imports and extension-ppoints as an alternative to subant where you have to know all callable targets upfront. Given that subant is way more heavyweight than import and plain dependencies I can understand you want to avoid subant. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ivy 2.2.0-RC1
Hi Maarten, Any chance to get a release date for this RC ? Thanks in advance, -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
Re: Ivy 2.2.0-RC1
I wanted to create this RC last week, but I had some other (non-Ivy-related) issues I had to look at so I didn't had time left to create the RC. But I hope I'll be able to do it somewhere this week or next week... There are still 2 (minor) things on my todo-list for this RC: - automatically regenerate the tutorial outputs when creating a new release (almost finished on this one) - automatically run RAT against Ivy codebase and fail the build if it contains errors like missing licenses... Maarten - Original Message From: Jean-Louis Boudart jeanlouis.boud...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Thu, June 24, 2010 10:24:37 AM Subject: Re: Ivy 2.2.0-RC1 Hi Maarten, Any chance to get a release date for this RC ? Thanks in advance, -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ivy 2.2.0-RC1
Is there anything i can do to help you on this ? I'm planning to release next easyant distribution soon and i would like it to be based on Ivy 2.2.0-RC1. We've made a few tests on our side with a trunk build and we didn't notice any problems or regressions so far. 2010/6/24 Maarten Coene maarten_co...@yahoo.com I wanted to create this RC last week, but I had some other (non-Ivy-related) issues I had to look at so I didn't had time left to create the RC. But I hope I'll be able to do it somewhere this week or next week... There are still 2 (minor) things on my todo-list for this RC: - automatically regenerate the tutorial outputs when creating a new release (almost finished on this one) - automatically run RAT against Ivy codebase and fail the build if it contains errors like missing licenses... Maarten - Original Message From: Jean-Louis Boudart jeanlouis.boud...@gmail.com To: Ant Developers List dev@ant.apache.org Sent: Thu, June 24, 2010 10:24:37 AM Subject: Re: Ivy 2.2.0-RC1 Hi Maarten, Any chance to get a release date for this RC ? Thanks in advance, -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
AW: Hudson target to build Ant via Maven
I created a Job BuildFromPOMs http://hudson.zones.apache.org/hudson/view/Ant/job/Ant_BuildFromPOMs Configuration: * SCM: Subversion repo: http://svn.apache.org/repos/asf/ant/core/trunk module: trunk * build trigger: - if a snapshot-dependency is built - scm changes, checked @hourly * Builder: Maven: - version: latest - pom: src/etc/poms/pom.xml - goals: clean package Jan -Ursprüngliche Nachricht- Von: jan.mate...@rzf.fin-nrw.de [mailto:jan.mate...@rzf.fin-nrw.de] Gesendet: Dienstag, 22. Juni 2010 12:27 An: dev@ant.apache.org Betreff: AW: Hudson target to build Ant via Maven I'll try that ... Jan -Ursprüngliche Nachricht- Von: Jesse Glick [mailto:jesse.gl...@oracle.com] Gesendet: Dienstag, 15. Juni 2010 02:19 An: dev@ant.apache.org Betreff: Re: Hudson target to build Ant via Maven On 06/11/2010 08:44 PM, Antoine Levy-Lambert wrote: we could contact the maven team and ask them to build ant in continuum. Possible. I just suggested using the existing Hudson server to keep everything together. (Hudson has good Maven support.) - 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: AW: Hudson target to build Ant via Maven
On 06/24/2010 08:30 AM, jan.mate...@rzf.fin-nrw.de wrote: Configuration: Looks like the build node is misconfigured: Unable to locate the Javac Compiler in: C:\java\jre6\..\lib\tools.jar If you have admin access you can set the job to use JDK 1.4.2_19 or whatever you like. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: AW: Hudson target to build Ant via Maven
Ok, havent seen that. Changed to latest Java 1.5. But now it seems that the dependencies arent resolved... Jan -Ursprüngliche Nachricht- Von: Jesse Glick [mailto:jesse.gl...@oracle.com] Gesendet: Donnerstag, 24. Juni 2010 15:46 An: dev@ant.apache.org Betreff: Re: AW: Hudson target to build Ant via Maven On 06/24/2010 08:30 AM, jan.mate...@rzf.fin-nrw.de wrote: Configuration: Looks like the build node is misconfigured: Unable to locate the Javac Compiler in: C:\java\jre6\..\lib\tools.jar If you have admin access you can set the job to use JDK 1.4.2_19 or whatever you like. - 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: 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
[Proposal] Capture attributes in unknown namespaces
Hi guys, Me again! I have some more functionality that I'm interested in, but I fear it may be quite specific to my requirements, so I thought I'd run it past you all before getting to work on it. I'm developing a custom executor which can execute targets in parallel, and as an extension of that, it would be kind of cool to be able to mark individual targets as CPU-bound or IO-bound so that the executor can be a bit smarter about scheduling them. However, I can't find any sensible way to communicate this information to the executor. 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. 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. What do you folks think? Cheers, Danny.
Re: [Proposal] Capture attributes in unknown namespaces
Like org.apache.tools.ant.Dynamic*NS? -Matt On Jun 24, 2010, at 2:50 PM, Danny Yates wrote: Hi guys, Me again! I have some more functionality that I'm interested in, but I fear it may be quite specific to my requirements, so I thought I'd run it past you all before getting to work on it. I'm developing a custom executor which can execute targets in parallel, and as an extension of that, it would be kind of cool to be able to mark individual targets as CPU-bound or IO-bound so that the executor can be a bit smarter about scheduling them. However, I can't find any sensible way to communicate this information to the executor. 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. 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. What do you folks think? Cheers, Danny. - 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
Hmm... that's interesting. I hadn't discovered that before. It's not clear to me what that does - it appears to manipulate the DOM somehow. Could you explain what it's for and how to use it and then I can see if it will help me solve my current problem. Many thanks, Danny. On 24 June 2010 20:58, Matt Benson gudnabr...@gmail.com wrote: Like org.apache.tools.ant.Dynamic*NS? -Matt On Jun 24, 2010, at 2:50 PM, Danny Yates wrote: Hi guys, Me again! I have some more functionality that I'm interested in, but I fear it may be quite specific to my requirements, so I thought I'd run it past you all before getting to work on it. I'm developing a custom executor which can execute targets in parallel, and as an extension of that, it would be kind of cool to be able to mark individual targets as CPU-bound or IO-bound so that the executor can be a bit smarter about scheduling them. However, I can't find any sensible way to communicate this information to the executor. 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. 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. What do you folks think? Cheers, Danny. - 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
On Jun 24, 2010, at 3:04 PM, Danny Yates wrote: Hmm... that's interesting. I hadn't discovered that before. It's not clear to me what that does - it appears to manipulate the DOM somehow. Could you explain what it's for and how to use it and then I can see if it will help me solve my current problem. Admittedly, I didn't read the entire message to see _what_ you wanted namespaced attributes for. :) The Dynamic* interfaces are more for custom tasks, etc. I could swear we've had a similar discussion about putting attributes on Targets before; at the very least you could create a custom ProjectHelper that instantiated a particular Target subclass. One of our committers, Alexey Solofnenko, was once working on a parallel executor, but I don't know whether he ever completed it. -Matt Many thanks, Danny. On 24 June 2010 20:58, Matt Benson gudnabr...@gmail.com wrote: Like org.apache.tools.ant.Dynamic*NS? -Matt On Jun 24, 2010, at 2:50 PM, Danny Yates wrote: Hi guys, Me again! I have some more functionality that I'm interested in, but I fear it may be quite specific to my requirements, so I thought I'd run it past you all before getting to work on it. I'm developing a custom executor which can execute targets in parallel, and as an extension of that, it would be kind of cool to be able to mark individual targets as CPU-bound or IO-bound so that the executor can be a bit smarter about scheduling them. However, I can't find any sensible way to communicate this information to the executor. 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. 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. What do you folks think? Cheers, Danny. - 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
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
Union + Tar
I've got my class which extends Union typedef. Inside of it are a bunch of
FileList's which in turn have a bunch of FileResources.
sunion id=all.classpath scope=all
sfilelist dir=${lib.dir}
sfile name=${activation.jar} scope=compile /
/sfilelist
/sunion
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
Idea's? One workaround is to create the directory structure first by copying
files, but that is kind of lame. =)
copy todir=${target.dir}/dist/lib
union refid=all.classpath /
/copy
jon
Re: Union + Tar
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: [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, 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 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
