DO NOT REPLY [Bug 10719] - Files processed under SQL task are hacked
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10719. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10719 Files processed under SQL task are hacked --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 01:29 --- Created an attachment (id=5299) diff -u of last attachement and cvs version 1.49
Re: 1.6 milestones ?
What about releasing an ant 1.5.4 before 1.6 with the current head revision in it, plus as many bugs from bugzilla as possible ? This would help a number of people and be encouraging for all the ant users who have reported bugs or suggested patches in bugzilla. Plus this would bring the import/ task to a confrontation with users ? I know from reading ant-users and ant-dev that this a feature that many people need. Meanwhile, it should be possible to make a discussion on the antlib feature or new taskdef, and on the boot loader process for ant on Win 9x. Antoine
Re: 1.6 milestones ?
On Wed, 12 Mar 2003, Costin Manolache [EMAIL PROTECTED] wrote: It'll have documentation after it is reviewed by more people and we know it's going to be stable. I don't like this approach at all. How are you expecting user feedback on an undocumented feature? Stefan
Re: 1.6 milestones ?
Steve Loughran wrote, On 13/03/2003 0.39: ... That's the import task that doesnt have any documentation, right? Jikes, you're right. How do I submit it, as the usual HTML page or the @tags... I'm a bit behind the Ant documentation efforts, sorry. Maybe the thing to do is look at what major changes still need to go in to ant. Now that we have exploded optional.jar, we need to compensate by perhaps adding a boot loader process for running ant, so that win9x boxes dont run out of memory. I keep getting line too long when I involke ant, because the script creates a too long classpath... I'd like to fix this ASAP, any suggestions? Shall I simply load in Ant all the jars in the ./lib dir? We also need to rework the documentation. In what sense? The other feature I thought was on the cards was some kind of plugin mechanism that pulls in new jars better -presumably a manifest, and the appropriate extensions to taskdef to handle them. Can you please expand a bit more? As I read, it looks like taskdef resource=tasks.properties/... for a more enhanced feature, we have the cents, but I'd move this discussion-integration-whatever to after 1.6. I think together these would be core features that need to be up and running before we can worry about milestone releases. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: 1.6 milestones ?
On Wed, 12 Mar 2003, Costin Manolache [EMAIL PROTECTED] wrote: Do we have any plan or idea on when we'll start distributing 1.6 milestone builds ? Ant has never released any milestone builds so far, so no, there is no plan yet AFAIK. If there was, you'd know it for sure 8-) Before we release a milestone we should make sure that whatever we release at least passes our tests (including the currently disabled ImportTest) and doesn't have any known regressions (see my mail of yesterday). And then I'd really love to have a rundown of the new features (I was swamped when you committed the parts coming from the embed proposal and lost track of it, a simple short list would suffice for starters) and look at them one by one to get consensus on whether we want them - if we can't agree on a given feature, it shouldn't be included in a milestone at all IMHO. Stefan
DO NOT REPLY [Bug 17934] - Dates too late in jar entries
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17934 Dates too late in jar entries [EMAIL PROTECTED] changed: What|Removed |Added Severity|Normal |Enhancement --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 08:47 --- From the manual of the zip task: Please note that ZIP files store file modification times with a granularity of two seconds. If a file is less than two seconds newer than the entry in the archive, Ant will not consider it newer. If Ant was rounding down instead of up, it would always consider the files inside the archive out-of-date and thus always update your archive. I'm changing this to an enhancement request. The possible enhancement I see is a new attribute to control the rounding behavior, but for the reason above, rounding up has to be the default.
DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17871. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17871 war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Target Milestone|--- |1.5.3 Version|1.6Alpha (nightly) |1.5.2 --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 08:54 --- Hmm, I see. I don't think using the canonical path is the correct solution (we'll technically the solution is correct, but probably not in terms of how it should be addressed in Ant). deploymentDescriptor should probably get the drive letter added to it in the first place - I'll look into it.
Re: 1.6 milestones ?
On Thu, 13 Mar 2003 09:50 am, Costin Manolache wrote: Hi, Do we have any plan or idea on when we'll start distributing 1.6 milestone builds ? I'm not really sure what a milestone build means and, more importantly, what expectations it creates for stability of feature set. For 1.6 I think there a few things which have been started which have not been completed. 1. Have we settled on the interpretation of basedir in the imported fragments? 2. I have a test case which fails which I think should be addressed. It is currently disabled since it was blocking the reporting of the JSPC failures 3. A lot of the code has comments such as //EXPERIMENTAL. There is unused code. I think some review here would be good. I'm still nervous about the classloader task and its ability to change the config of a running loader. I would like to close off the 1.5 branch beore we really start to polish 1.6. 1.5.2 was meant to do that but I think we may have rushed it a little. -- Conor MacNeill Blog: http://codefeed.com/blog/
Re: 1.6 milestones ?
On Thu, 13 Mar 2003 06:29 pm, Antoine Levy-Lambert wrote: What about releasing an ant 1.5.4 before 1.6 with the current head revision in it, plus as many bugs from bugzilla as possible ? A rose by any other name. If we release the HEAD revision, we'll call it 1.6 This would help a number of people and be encouraging for all the ant users who have reported bugs or suggested patches in bugzilla. Plus this would bring the import/ task to a confrontation with users ? I know from reading ant-users and ant-dev that this a feature that many people need. Meanwhile, it should be possible to make a discussion on the antlib feature or new taskdef, and on the boot loader process for ant on Win 9x. I have some ideas on the boot loader as I've done somethign similar before. -- Conor MacNeill Blog: http://codefeed.com/blog/
DO NOT REPLY [Bug 17952] New: - failonerror and verbose undocumented on move
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17952. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17952 failonerror and verbose undocumented on move Summary: failonerror and verbose undocumented on move Product: Ant Version: 1.6Alpha (nightly) Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Move.java extends Copy.java. But not all attributes are described in the Move- Manual. I know that failonerror works but isn´t described. So include the description of the Copy-Manual in Move-Manual, too: tr td valign=topfailonerror/td td valign=topLog a warning message, but do not stop the build, when the file to copy does not exist. Only meaningful when copying a single file. /td td valign=top align=centerNo; defaults to true./td /tr tr td valign=topverbose/td td valign=topLog the files that are being copied./td td valign=top align=centerNo; defaults to false./td /tr
Suggestion EJbjar exclude dependants
I think it would be useful in some cases. For instance I have the attribute dependency=full and dependency analyzer includes in myejb.jar classes that have to be in app server classpath. So I have them double and probably class loading issues. What do you mind? Does it make sense to include an optional element like excludeDependants? _ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail
RE: Possible TaskDef donation
This is indeed interesting. I do something quite similar for another purpose (scans a JAR for all classes having a give static method signature, executes all these methods, gathering the meta-info required, generate a XML file then stuck into the JAR's META-INF directory). Something I do is to restrict scanning classes to only those that match a given patternset to speed things up (you often know which part of your package tree to look things, or could use a naming convention to find things faster). This makes the scanning quite a bit faster (we have big JARs). All this to say that you specific use case if very useful, but the more generic action all scanning the classes of a JAR and doing something that ultimately updated the JAR somehow would be even more useful. Allowing to plug over 'actions' rather than the default 'looking for services' would be very very useful IMHO. What are your dependencies? BCEL? Do you load the actual classes (so need dependent classes on the classpath)? Thanks for sharing this with us. --DD PS: BTW, I don't think you can edit the JAR in place... -Original Message- From: Berin Loritsch [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 12, 2003 4:13 PM To: [EMAIL PROTECTED] Subject: Possible TaskDef donation Currently, if you want to support the JAR Services standard set forth by Sun, you have to create a file with an interface name in META-INF/services and list all the implementations. This can get to become a problem if we are adding and removing classes, and we forget to update this hand maintained file. I wrote an ANT task that will scan an existing JAR, and find all the classes that implement the specified interfaces. The task verifies that the supplied service name *is* in fact an interface, and then it checks every class in the JAR to see if it implements that interface. After it collects all this information it adds a new entry for each interface, with the list of implementations for each service. For now it needs to use an input jar and an output jar because I could not figure out how to modify the jar in place. As more project adopt this standard, it would be nice to include in ANT proper. If you are interested, I can post the source code.
[PATCH] Ant Task - Proposed Enhancement
The current ant task runs an ant process for a specified build file in a
specified directory. I wanted to be able to give it more than one
directory, and execute the build file found in each directory specified,
or give it a set of build files to execute. This can be really useful
for building projects on which this project depends (could be
sub-projects but doesn't have to be). I understand that this
enhancement overlaps with the proposed SubAnt task but I feel that this
function is really the domain of the existing Ant task, so rather than
adding another task, the Ant task should be enhanced - especially when
it only involves adding a couple contained types that users already know
how to use in other contexts.
This enhancement adds the ability to specify multiple directories with
the addition of a contained dirset type or multiple files with the
addition of a contained fileset type. One can also specify both
DirSets and FileSets together, as well. This allows the task to run ant
processes on the directories specified (by appending the default
antFile to them), or on the set of files specified. {see
ANT_HOME\src\etc\testcases\taskdefs\ant.xml for examples in the attached
zip file}
I've run all of the current and new tests on the task and all passed.
Most of the original logic flow is unchanged (although it doesn't seem
that way due to refactoring). In a nutshell, I added a for loop to the
execute method to loop through the each directory and each file
specifed, and execute the target on each. {see diff.txt in the
attached zip file}
Tell me what you think.
Andy
Using directory structure
*
/sub1
build.xml
/sub2
build.xml
/sub3
build.xml
A typical build file could use the new task like this:
!-- excerpt from Project3/build.xml which depends on Project1 and
Project2 --
!-- in order to build correctly --
property name=subproject.dirs value=Project1,Project2/
target name=compile-subprojects if=subproject.dirs
taskdef name=antnew
classname=org.apache.tools.ant.taskdefs.AntNew/
antnew inheritAll=false target=compile
dirset dir=.. includes=${subproject.dirs}/ !-- NEW
FEATURE --
/antnew
/target
target name=compile depends=compile-subprojects
...
/target
more examples pasted from testcases:
target name=test-dirset-inline-includes
ant inheritAll=false target=printMessage
dirset dir=ant includes=sub1,sub2,sub3/
/ant
/target
target name=test-dirset-contained-includes
ant inheritAll=false target=printMessage
dirset dir=ant
include name=sub*/
/dirset
/ant
/target
target name=test-fileset-inline-includes
ant inheritAll=false target=printMessage
fileset dir=ant
includes=sub1/build.xml,sub2/build.xml,sub3/build.xml/
/ant
/target
target name=test-fileset-contained-includes
ant inheritAll=false target=printMessage
fileset dir=ant
include name=sub*/build.xml/
/fileset
/ant
/target
target name=test-fileset-and-dirset
ant inheritAll=false target=printMessage
fileset dir=ant
include name=sub1/build.xml/
/fileset
dirset dir=ant includes=sub2,sub3/
/ant
/target
attachment: AntTask-Proposed.zip
Re: Possible TaskDef donation
Dominique Devienne wrote: This is indeed interesting. I do something quite similar for another purpose (scans a JAR for all classes having a give static method signature, executes all these methods, gathering the meta-info required, generate a XML file then stuck into the JAR's META-INF directory). Something I do is to restrict scanning classes to only those that match a given patternset to speed things up (you often know which part of your package tree to look things, or could use a naming convention to find things faster). This makes the scanning quite a bit faster (we have big JARs). All this to say that you specific use case if very useful, but the more generic action all scanning the classes of a JAR and doing something that ultimately updated the JAR somehow would be even more useful. Allowing to plug over 'actions' rather than the default 'looking for services' would be very very useful IMHO. Easy change to make--I can make it a protected action (the actual check). What are your dependencies? BCEL? Do you load the actual classes (so need dependent classes on the classpath)? Standard JVM. I use JarFile to read the JAR contents, and JarOutputStream to write the new JAR. I construct a new URLClassLoader that uses the current classloader as the parent, and loads the input JAR in as well. I then scan the contents of the JAR only looking at the .class entries. I load the class, and perform my checks on the class itself. Thanks for sharing this with us. --DD PS: BTW, I don't think you can edit the JAR in place... Would be nice though. I guess we could make it something where you can use a directory instead of the JAR. It would alter the scanning code though. Do you want me to post what I have?
RE: Possible TaskDef donation
Why not posting it? Seems interesting enough, and once it's posted people can start using it or tweaking it. Best way to post it is to open a new Enhancement in Ant's BugZilla. This keeps everything in one place (posted sources, JARs, ZIPs, whatever and the discussions about it). Using URLClassLoader works fine, but does require having the dependent classes available. Maybe somehow Ant's classfileset can be leveraged to not require the dependencies. --DD -Original Message- From: Berin Loritsch [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 9:57 AM To: [EMAIL PROTECTED] Subject: Re: Possible TaskDef donation Dominique Devienne wrote: This is indeed interesting. I do something quite similar for another purpose (scans a JAR for all classes having a give static method signature, executes all these methods, gathering the meta-info required, generate a XML file then stuck into the JAR's META-INF directory). Something I do is to restrict scanning classes to only those that match a given patternset to speed things up (you often know which part of your package tree to look things, or could use a naming convention to find things faster). This makes the scanning quite a bit faster (we have big JARs). All this to say that you specific use case if very useful, but the more generic action all scanning the classes of a JAR and doing something that ultimately updated the JAR somehow would be even more useful. Allowing to plug over 'actions' rather than the default 'looking for services' would be very very useful IMHO. Easy change to make--I can make it a protected action (the actual check). What are your dependencies? BCEL? Do you load the actual classes (so need dependent classes on the classpath)? Standard JVM. I use JarFile to read the JAR contents, and JarOutputStream to write the new JAR. I construct a new URLClassLoader that uses the current classloader as the parent, and loads the input JAR in as well. I then scan the contents of the JAR only looking at the .class entries. I load the class, and perform my checks on the class itself. Thanks for sharing this with us. --DD PS: BTW, I don't think you can edit the JAR in place... Would be nice though. I guess we could make it something where you can use a directory instead of the JAR. It would alter the scanning code though. Do you want me to post what I have?
DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17871. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17871 war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 16:25 --- Could you please either try the next nightly build (i.e. 2003-03-14) or replace the 1.5.2 ant.jar with the one from http://cvs.apache.org/~bodewig/ant.jar and see whether it fixes the problem?
DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14553. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14553 Add support for a separate CLASSPATH --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 16:25 --- Ok - I almost rest my case :) ... by using taskdef resource/file one can reduce it to a one-liner, but I still see it as a much cleaner way to specify the tasks available to ant from the outside instead of locally in each build.xml file Actually, I much prefer this one liner that an ANTCLASSPATH. At least some Ant committers prefer explicit things, and the taskdef at the top of all of your build files makes it explicit they are using custom tasks/types. You'll have a hard time introducing a magic feature when there's a clean and simple explicit way to do the same... --DD
DO NOT REPLY [Bug 17506] - loadproperties not working with non latin characters
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17506. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17506 loadproperties not working with non latin characters --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 16:39 --- Antoine, could you turn the code from escapeUnicode into a escapeunicode filterreader? It looks as if it might be useful even if you don't have to specify the encoding and maybe even for other tasks supporting filterchains. This filter would also allow you to use it as a custom filter to fix Ant 1.5 or whatever and to control whether you need it or not (if you have unencoded 8 bit characters you are violating the property file format and should expect loadproperties to fail 8-).
DO NOT REPLY [Bug 17961] - New task to collect services from a JAR
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17961. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17961 New task to collect services from a JAR --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 16:52 --- Created an attachment (id=5314) ServiceCollector source code
DO NOT REPLY [Bug 14553] - Add support for a separate CLASSPATH
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14553. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14553 Add support for a separate CLASSPATH --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 16:56 --- 1. Do you know about how to import XML fragments into a build file? Look in the ant in anger document with your ant install. Ant1.6 provisionally has an import task to do this more cleanly. 2. if you have 5 custom tasks in one single jar, you only need one taskdef -just point it at a properties file listing taskname=classname mappings.
RE: [PATCH] Ant Task - Proposed Enhancement
Mmm...spoken like someone with an emotional attachment to SubAnt due to
your involvement with it. Let's be constructive and stick with the
merits of my proposal because you've got some good points. BTW, this is
my first submittal to any open source project so let's approach this
from a today's my first day kind of way. :-) I don't care which one
people like and/or use, but I implemented it anyway so I thought I'd put
it out there.
My new ant task supports ordering of build files by default. Just line
them up in the includes= attribute.
I have never seen the loadproperties task before your reference to it
but yes, looking at it for a minute I think it may have been a better
fit in the property task, but it's fine the way it is.
This new ant task has no support for running several targets, forking,
child-parent props,refs (except the default handling of props/ref
provided by the original ant). This was outside of my scope. I don't
see why these features couldn't be added though. java and javac
have a fork attribute - why couldn't ant? Based on *your* reasoning
we should have created a subjavac if javac wasn't meeting our
needs.
This is why I extended ant. I knew of the existence of SubAnt task
but it hadn't been released (or even committed) when I got started on
the new Ant task and I thought my implementation was cleaner for the end
user. It's early enough for the Ant committers and the other developers
to decide which they like, or decide to keep both ways like the
Properties and LoadProperties tasks. So, to say that I should have used
an *existing* task is a bit of a stretch.
And, on the subtleties, I think it work pretty intuitively:
dir antFile = dir\antFile
dir dirset = error
dirset antFile = dir[i]\antFile
fileset = path\to\antFile
Andy
[EMAIL PROTECTED] 3/13/2003 9:55:03 AM
But where does it stop? subant also supports automatic ordering of
the
projects called based on the declared dependencies of the projects in
an XML
file... Should that go into ant as well? (granted, I didn't submit
that,
it's only in my sandbox...)
According to your reasoning, loadproperties features should have gone
into
property file=.
And what about running several targets instead of one, or forking the
sub-builds, or exporting back up properties/references from the child
to the
parent? Should that go in ant as well?
This is why subant and orther ant derivatives exist, and do a good
job
at what they do.
Have you considered the subtleties of what basedir gets used for the
sub-projects when mixing build filesets and dirsets?
Instead of modifying Ant to get your chances, you might as well have
used
something that already exists and works. But that's just me. --DD
-Original Message-
From: Andrew Goodnough [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 13, 2003 9:27 AM
To: [EMAIL PROTECTED]
Subject: [PATCH] Ant Task - Proposed Enhancement
The current ant task runs an ant process for a specified build file in
a
specified directory. I wanted to be able to give it more than one
directory, and execute the build file found in each directory
specified,
or give it a set of build files to execute. This can be really useful
for building projects on which this project depends (could be
sub-projects but doesn't have to be). I understand that this
enhancement overlaps with the proposed SubAnt task but I feel that
this
function is really the domain of the existing Ant task, so rather than
adding another task, the Ant task should be enhanced - especially when
it only involves adding a couple contained types that users already
know
how to use in other contexts.
This enhancement adds the ability to specify multiple directories with
the addition of a contained dirset type or multiple files with the
addition of a contained fileset type. One can also specify both
DirSets and FileSets together, as well. This allows the task to run
ant
processes on the directories specified (by appending the default
antFile to them), or on the set of files specified. {see
ANT_HOME\src\etc\testcases\taskdefs\ant.xml for examples in the
attached
zip file}
I've run all of the current and new tests on the task and all passed.
Most of the original logic flow is unchanged (although it doesn't
seem
that way due to refactoring). In a nutshell, I added a for loop to
the
execute method to loop through the each directory and each file
specifed, and execute the target on each. {see diff.txt in the
attached zip file}
Tell me what you think.
Andy
Using directory structure
*
/sub1
build.xml
/sub2
build.xml
/sub3
build.xml
A typical build file could use the new task like this:
!-- excerpt from Project3/build.xml which depends on Project1 and
Project2 --
!-- in order to build correctly --
property name=subproject.dirs value=Project1,Project2/
target name=compile-subprojects if=subproject.dirs
taskdef name=antnew
classname=org.apache.tools.ant.taskdefs.AntNew/
antnew
Re: [PATCH] Ant Task - Proposed Enhancement
I am more minded to put the subant in there, with perhaps some minor tweaks.
The reason to use a separate task when there are major changes in
functionality are
(a) we can have more sensible defaults (here: property inheritance, and what
happens when you invoke a target called . I'd like that to be the
default, but in ant you get the target called instead.
(b) guarantee of zero backwards compatibility issues.
If I start with adding subant to CVS, will you work with us to make sure
your needs are met in the new task, which includes pasting in all the bits
of this patch that help. I like the memory stuff, BTW -we do need to fight
leakage here.
-steve
- Original Message -
From: Andrew Goodnough [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 13, 2003 07:26
Subject: [PATCH] Ant Task - Proposed Enhancement
The current ant task runs an ant process for a specified build file in a
specified directory. I wanted to be able to give it more than one
directory, and execute the build file found in each directory specified,
or give it a set of build files to execute. This can be really useful
for building projects on which this project depends (could be
sub-projects but doesn't have to be). I understand that this
enhancement overlaps with the proposed SubAnt task but I feel that this
function is really the domain of the existing Ant task, so rather than
adding another task, the Ant task should be enhanced - especially when
it only involves adding a couple contained types that users already know
how to use in other contexts.
This enhancement adds the ability to specify multiple directories with
the addition of a contained dirset type or multiple files with the
addition of a contained fileset type. One can also specify both
DirSets and FileSets together, as well. This allows the task to run ant
processes on the directories specified (by appending the default
antFile to them), or on the set of files specified. {see
ANT_HOME\src\etc\testcases\taskdefs\ant.xml for examples in the attached
zip file}
I've run all of the current and new tests on the task and all passed.
Most of the original logic flow is unchanged (although it doesn't seem
that way due to refactoring). In a nutshell, I added a for loop to the
execute method to loop through the each directory and each file
specifed, and execute the target on each. {see diff.txt in the
attached zip file}
Tell me what you think.
Andy
Using directory structure
*
/sub1
build.xml
/sub2
build.xml
/sub3
build.xml
A typical build file could use the new task like this:
!-- excerpt from Project3/build.xml which depends on Project1 and
Project2 --
!-- in order to build correctly --
property name=subproject.dirs value=Project1,Project2/
target name=compile-subprojects if=subproject.dirs
taskdef name=antnew
classname=org.apache.tools.ant.taskdefs.AntNew/
antnew inheritAll=false target=compile
dirset dir=.. includes=${subproject.dirs}/ !-- NEW
FEATURE --
/antnew
/target
target name=compile depends=compile-subprojects
...
/target
more examples pasted from testcases:
target name=test-dirset-inline-includes
ant inheritAll=false target=printMessage
dirset dir=ant includes=sub1,sub2,sub3/
/ant
/target
target name=test-dirset-contained-includes
ant inheritAll=false target=printMessage
dirset dir=ant
include name=sub*/
/dirset
/ant
/target
target name=test-fileset-inline-includes
ant inheritAll=false target=printMessage
fileset dir=ant
includes=sub1/build.xml,sub2/build.xml,sub3/build.xml/
/ant
/target
target name=test-fileset-contained-includes
ant inheritAll=false target=printMessage
fileset dir=ant
include name=sub*/build.xml/
/fileset
/ant
/target
target name=test-fileset-and-dirset
ant inheritAll=false target=printMessage
fileset dir=ant
include name=sub1/build.xml/
/fileset
dirset dir=ant includes=sub2,sub3/
/ant
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH] Ant Task - Proposed Enhancement
Yeah, if you put subant out in CVS, I'd be happy to play around with
it to see how it could fit for me.
Andy
[EMAIL PROTECTED] 3/13/2003 11:07:53 AM
I am more minded to put the subant in there, with perhaps some minor
tweaks.
The reason to use a separate task when there are major changes in
functionality are
(a) we can have more sensible defaults (here: property inheritance, and
what
happens when you invoke a target called . I'd like that to be the
default, but in ant you get the target called instead.
(b) guarantee of zero backwards compatibility issues.
If I start with adding subant to CVS, will you work with us to make
sure
your needs are met in the new task, which includes pasting in all the
bits
of this patch that help. I like the memory stuff, BTW -we do need to
fight
leakage here.
-steve
- Original Message -
From: Andrew Goodnough [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, March 13, 2003 07:26
Subject: [PATCH] Ant Task - Proposed Enhancement
The current ant task runs an ant process for a specified build file
in a
specified directory. I wanted to be able to give it more than one
directory, and execute the build file found in each directory
specified,
or give it a set of build files to execute. This can be really
useful
for building projects on which this project depends (could be
sub-projects but doesn't have to be). I understand that this
enhancement overlaps with the proposed SubAnt task but I feel that
this
function is really the domain of the existing Ant task, so rather
than
adding another task, the Ant task should be enhanced - especially
when
it only involves adding a couple contained types that users already
know
how to use in other contexts.
This enhancement adds the ability to specify multiple directories
with
the addition of a contained dirset type or multiple files with the
addition of a contained fileset type. One can also specify both
DirSets and FileSets together, as well. This allows the task to run
ant
processes on the directories specified (by appending the default
antFile to them), or on the set of files specified. {see
ANT_HOME\src\etc\testcases\taskdefs\ant.xml for examples in the
attached
zip file}
I've run all of the current and new tests on the task and all
passed.
Most of the original logic flow is unchanged (although it doesn't
seem
that way due to refactoring). In a nutshell, I added a for loop to
the
execute method to loop through the each directory and each file
specifed, and execute the target on each. {see diff.txt in the
attached zip file}
Tell me what you think.
Andy
Using directory structure
*
/sub1
build.xml
/sub2
build.xml
/sub3
build.xml
A typical build file could use the new task like this:
!-- excerpt from Project3/build.xml which depends on Project1 and
Project2 --
!-- in order to build correctly --
property name=subproject.dirs value=Project1,Project2/
target name=compile-subprojects if=subproject.dirs
taskdef name=antnew
classname=org.apache.tools.ant.taskdefs.AntNew/
antnew inheritAll=false target=compile
dirset dir=.. includes=${subproject.dirs}/ !-- NEW
FEATURE --
/antnew
/target
target name=compile depends=compile-subprojects
...
/target
more examples pasted from testcases:
target name=test-dirset-inline-includes
ant inheritAll=false target=printMessage
dirset dir=ant includes=sub1,sub2,sub3/
/ant
/target
target name=test-dirset-contained-includes
ant inheritAll=false target=printMessage
dirset dir=ant
include name=sub*/
/dirset
/ant
/target
target name=test-fileset-inline-includes
ant inheritAll=false target=printMessage
fileset dir=ant
includes=sub1/build.xml,sub2/build.xml,sub3/build.xml/
/ant
/target
target name=test-fileset-contained-includes
ant inheritAll=false target=printMessage
fileset dir=ant
include name=sub*/build.xml/
/fileset
/ant
/target
target name=test-fileset-and-dirset
ant inheritAll=false target=printMessage
fileset dir=ant
include name=sub1/build.xml/
/fileset
dirset dir=ant includes=sub2,sub3/
/ant
/target
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 17871] - war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17871. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17871 war task's webxml attrib no longer is able to use value with a starting backslash for the path in Windows --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 17:51 --- After deleting the test?.war files and re-running the test target with the http://cvs.apache.org/~bodewig/ant.jar JAR, it now appears that the test3.war file is generated with the appropriate web.xml file within it. Thanks!
DO NOT REPLY [Bug 17961] - New task to collect services from a JAR
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17961. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17961 New task to collect services from a JAR --- Additional Comments From [EMAIL PROTECTED] 2003-03-13 19:38 --- Created an attachment (id=5327) Newer version that actually works--I forgot to copy the contents of the jar entries before
Re: [PATCH] Ant Task - Proposed Enhancement
- Original Message - From: Dominique Devienne [EMAIL PROTECTED] To: 'Ant Developers List' [EMAIL PROTECTED] Sent: Thursday, March 13, 2003 07:55 Subject: RE: [PATCH] Ant Task - Proposed Enhancement But where does it stop? subant also supports automatic ordering of the projects called based on the declared dependencies of the projects in an XML file... Should that go into ant as well? (granted, I didn't submit that, it's only in my sandbox...) DD. Looking at the subant source, I see * @version Sep 2002 - Copyright (c) 2002, Landmark Graphics Corp.What is the status of this?
RE: sql triggers, stored procedures, packages, format preserved
Steve, My build process will rely heavily on this task to load packages, procedures, triggers, view, types, and apply grants in Oracle9i. I agree that some tests are needed and I will look into creating some. Thanks, -Rob Anderson -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 9:02 AM To: Ant Developers List Subject: Re: sql triggers, stored procedures, packages, format preserved - Original Message - From: Anderson, Rob H - VSCM [EMAIL PROTECTED] To: 'Ant Developers List' [EMAIL PROTECTED] Sent: Thursday, March 13, 2003 08:41 Subject: RE: sql triggers, stored procedures, packages, format preserved The diff -u is now the latest attachement to the bug. got it. I am willing to commit these changes, but am not going to be in a position to test them. What would be really nice long term would be some tests that used, say hsql as a sql server. But short term, let me know what breaks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JDK 1.1 support
+1 -Original Message- From: Conor MacNeill [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 5:29 PM To: [EMAIL PROTECTED] Subject: JDK 1.1 support 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 2. Make the subsequent release require JDK 1.2+ (what about leap frogging to later versions?) 3. Name this subsequent release Ant 2.0 (due to its change in system requirements) 4. Drop all the Ant2 cruft from the website. Just as a data point, CVS HEAD (Ant 1.6) has not compiled against JDK 1.1 for a while now (due to diagnostics changes). -- Conor MacNeill Blog: http://codefeed.com/blog/
