Re: [VOTE] Release AntUnit 1.3 based on RC1
+1 from me Peter On Sun, May 11, 2014 at 4:55 PM, Antoine Levy Lambert anto...@gmx.dewrote: +1 for me Antoine On May 11, 2014, at 11:07 AM, Nicolas Lalevée nicolas.lale...@hibnet.org wrote: +1 for me Nicolas Le 11 mai 2014 à 12:42, Stefan Bodewig bode...@apache.org a écrit : Hi all, delayed because I wanted to wait for mails to arrive again. Antunit 1.3 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/ (svn revision 5298) Maven artifacts are here: https://repository.apache.org/content/repositories/orgapacheant-1005/org/apache/ant/ant-antunit/1.3/ Details of changes since 1.2 are in the release notes: https://dist.apache.org/repos/dist/dev/ant/antlibs/antunit/RELEASE-NOTES-1.3.html The tag is here: http://svn.apache.org/repos/asf/ant/antlibs/antunit/tags/1.3RC1/ (svn revision 1593382) KEYS: http://www.apache.org/dist/ant/KEYS Please review the release candidate and vote. This vote will close no sooner that 72 hours from now, i.e. after 1100 GMT 14-May 2014. Should we get hit by a mail-outage again I'll defer counting the votes as well. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thanks! Stefan - 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: [VOTE] Release Ant 1.9.3
+1 Peter On Thu, Dec 26, 2013 at 1:17 PM, Jan Matèrne (jhm) apa...@materne.dewrote: After investing some more time and doing a bootstrap build (thanks Antoine): Running on Windows 7 64bit Using Java 1.5 C:\projekte\apache-ant\ANT_193java -version java version 1.5.0_22 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_22-b03) Java HotSpot(TM) Client VM (build 1.5.0_22-b03, mixed mode) Using empty environment variables for JAVA_HOME ANT_HOME CLASSPATH Path-Variable only points to JDK\bin Running build dist test BUILD FAILED C:\projekte\apache-ant\ANT_193\build.xml:1620: Unit tests failed; see: C:\projekte\apache-ant\ANT_193\build\testcases\reports C:\projekte\apache-ant\ANT_193\build\antunit\reports taskdef-antlib-test_xml testAntlib java.lang.IllegalStateException: zip file closed at line 47 , column 69 This test creates a jar containing an antlib definition with two macros. Loading that jar via taskdef throws this exception. No idea here. == not bad enough for me to vote against this release, because AntUnit is loaded all the time, so taskdef works. ManifestClassPathTest testDifferentWindowsDrive Failure Should throw BuildException because: different drive at org.apache.tools.ant.BuildFileTest.expectBuildExceptionContaining(BuildFileT est.java:391) at org.apache.tools.ant.taskdefs.ManifestClassPathTest.testDifferentWindowsDriv e(ManifestClassPathTest.java:198) This test runs only on Windows. This test tries to get File.getCanonicalPath() of a file on a C: or D: according to java.tmp.dir: java.tmp.dir on C ? File(D:/foo.txt).getCanonicalPath() : File(C:/foo.txt).getCanonicalPath() Problem (on my machine): D: exists but is not ready (CD-ROM with no CD inserted) == not bad enough for me to vote against this release Running apache-ant-1.9.3\bin\ant -f check.xml rat 11 Unknown Licenses *** Unapproved licenses: C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/Comman dLauncherTask.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/CommandLauncher.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/CommandLauncherProxy.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/Java13CommandLauncher.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/MacCommandLauncher.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/OS2CommandLauncher.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/PerlScriptCommandLauncher.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/ScriptCommandLauncher.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/VmsCommandLauncher.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/WinNTCommandLauncher.java C:/projekte/apache-ant/ANT_193/src/main/org/apache/tools/ant/types/resources /LazyResourceCollectionWrapper.java == I dont like the missing of the license header. But obviously we have shipped that for more versions and its fixed now in trunk. So ok with me. So I could vote a +1. Jan -Ursprüngliche Nachricht- Von: Jan Matèrne (jhm) [mailto:apa...@materne.de] Gesendet: Donnerstag, 26. Dezember 2013 15:41 An: 'Ant Developers List' Betreff: AW: [VOTE] Release Ant 1.9.3 Checked the tag http://svn.apache.org/repos/asf/ant/core/tags/ANT_193/ Using RAT (ant -f check.xml rat) 11 Unknown Licenses *** Unapproved licenses: C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/Comman dLauncherTask.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/CommandLauncher.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/CommandLauncherProxy.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/Java13CommandLauncher.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/MacCommandLauncher.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/OS2CommandLauncher.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/PerlScriptCommandLauncher.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/ScriptCommandLauncher.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/VmsCommandLauncher.java C:/projekte/apache- ant/ANT_193/src/main/org/apache/tools/ant/taskdefs/launch er/WinNTCommandLauncher.java
Re: [VOTE] Jean-Louis Boudart as a PMC member
+1 Peter On Tue, Nov 26, 2013 at 6:10 AM, Dominique Devienne ddevie...@gmail.comwrote: On Tue, Nov 26, 2013 at 12:04 PM, Nicolas Lalevée nicolas.lale...@hibnet.org wrote: Jean-Louis has been around for a very long time, owned committership, contributed a lot to bring EasyAnt into the Ant PMC, and he is participating to the vote in the release process. Thus, let's invite Jean-Louis to be part of the PMC. Here is my +1 +1. --DD
Re: [VOTE] Charles Duffy as a committer
+1 Peter On Fri, Nov 22, 2013 at 11:21 AM, Martin Gainty mgai...@hotmail.com wrote: -Support your proposals in particular (and the project in general) -Be diligent about squashing bugs (especially when they are out of conformance with documented SPECs or JSRs) -Be around nites and weekends (to take the load off everyone elses shoulders) -sometimes working 40 hours/week (without a dime of remuneration!) Welcome to the group Mr Duffy! -) Martin __ Place long-winded disclaimer at this location From: anto...@gmx.de To: dev@ant.apache.org Date: Fri, 22 Nov 2013 12:07:48 -0500 Subject: [VOTE] Charles Duffy as a committer I would like to nominate Charles Duffy as a committer. Charles has proposed a number of patches to Ivy such as IVY-1421, IVY-1423, IVY-1424 and recently a patch concerning the useorigin attribute for the case of URL resources which happen to be files. Let's vote on it. [ ] +1 to add Charles Duffy as a committer [ ] -1 to disagree [ ] +0 means I don't care Here is my +1. Antoine Envoyé avec AquaMail pour Android http://www.aqua-mail.com - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Compress Antlib 1.3 Based on RC1
+1 Peter On Sat, Nov 2, 2013 at 3:21 AM, Stefan Bodewig bode...@apache.org wrote: On 2013-11-02, Nicolas Lalevée wrote: I was just surprised to see the license file in the common folder in the source archive rather at its root. But this is nit picking. I think this is common (no pun intended) to all our antlib releases. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
peter.kitt.reilly
http://biggerpenissize.enhancementpills.co/eo/zhurcr.aermnb - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
peter.kitt.reilly
http://adidas.dxsmedia.net/soicm/tlu.drdgwowxfbkjgiccff - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ant 1.9.2
+1 Peter On Thu, Jul 11, 2013 at 7:36 AM, Jesse Glick jgl...@cloudbees.com wrote: +1; a contact at NetBeans did some sanity checking at my suggestion (especially Javadoc generation on JDK 7u21 and 7u25) and said it was OK. Thanks Stefan for taking the initiative on this! --**--**- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Ant 1.9.1 Release
+1 Peter On Mon, May 20, 2013 at 2:01 AM, Antoine Levy Lambert anto...@gmx.dewrote: I plan to wait until Tuesday May 21st evening to release. Just in case - I have seen that Monday is a holiday for some of us. Regards, Antoine On May 19, 2013, at 2:13 PM, Michael Clarke wrote: +1 from me too On 19 May 2013 13:22, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: +1 2013/5/16 Antoine Levy Lambert anto...@gmx.de Hi, I have uploaded candidate artefacts for an ant 1.9.1 release to : http://people.apache.org/~antoine/dist Let's vote on releasing these. Let's start with my own +1. Regards, Antoine - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://ant.apache.org/easyant/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Adding if/unless conditions on commandline args
The problem of not using namespaces is that they
would not be backward compatible. Also the attributes
are 'magic' and we already have 'id' as a magic attribute,
which makes task code hard to reason about.
Peter
p.s, I really hate xml namespaces!
On Thu, May 9, 2013 at 4:43 PM, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
I'm not a big fan of adding this feature through internal namespaces, was
there any complication to do it without namespaces ?
Anyway it does the job, and stuff looks extensible so i'm fine with current
solution if no one objects.
49036 add 'unless' attribute to JUnit test element was already solved
isn't it ?
2013/5/6 Peter Reilly peter.kitt.rei...@gmail.com
wow, I had forgot about that!
Peter
On Mon, May 6, 2013 at 12:55 AM, Antoine Levy Lambert anto...@gmx.de
wrote:
Hi,
I have committed a patch created by Peter Reilly back in 2007.
The bugzilla PR is 43362 [1]
If the community is happy with this change we will be able to close a
number of bug reports requesting if/unless on various elements .
For instance 49136 requesting if/unless support for attribute nested
element of manifest task,
49036 add 'unless' attribute to JUnit test element,
...
Regards,
Antoine
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43362
On May 3, 2013, at 5:37 AM, Jan Matèrne (jhm) wrote:
AFAIK this was discussed several times in the past (few years) with
the
result, that having if/unless an _all_ elements would decrease
maintainability of the build scripts.
But +1 from me for having if/unless on nested elements.
What about supporting more complex conditions via nested condition
elements?
Jan
-Ursprüngliche Nachricht-
Von: Michael Clarke [mailto:michael.m.cla...@gmail.com]
Gesendet: Freitag, 3. Mai 2013 11:01
An: Ant Developers List
Betreff: Re: Adding if/unless conditions on commandline args
+1 from me too
On 3 May 2013, at 09:37, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
+1
2013/5/3 Antoine Levy Lambert anto...@gmx.de
I wonder whether we could not add if an unless on all nested
elements
in the framework ?
Regards,
Antoine
On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:
Hi,
It's currently difficult to make reusable script when using
exec
task
or
any other task using commandline args.
We oftenly need some dynamic arguments and this can be
complicated.
Therefor, i suggest to introduce if/unless conditions on comand
line
args :
exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/ arg value=-m/
arg
value=${commit.message}/ /exec
I have a working implementation with related tests and
documentation.
Commandline.Arg class now extends ProjectComponent, and expose
accessors for if/unless condition, and rely on PropertyHelper to
check conditions.
Is this sufficient ? From what i have seen, it doesn't break
backward compatibility at least all tests are green :p.
The setProject(Project p) method should be invoked
automatically
by ProjectHelper isn't it ?
If ant is used in pure java and we ommited invoking
setProject(Project p) method, it should also works as
PropertyHelper seems null safe.
If there is no objection i will commit this this week end.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
additional
commands, e-mail: dev-h...@ant.apache.org
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
-
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
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
Re: Adding if/unless conditions on commandline args
wow, I had forgot about that!
Peter
On Mon, May 6, 2013 at 12:55 AM, Antoine Levy Lambert anto...@gmx.dewrote:
Hi,
I have committed a patch created by Peter Reilly back in 2007.
The bugzilla PR is 43362 [1]
If the community is happy with this change we will be able to close a
number of bug reports requesting if/unless on various elements .
For instance 49136 requesting if/unless support for attribute nested
element of manifest task,
49036 add 'unless' attribute to JUnit test element,
...
Regards,
Antoine
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43362
On May 3, 2013, at 5:37 AM, Jan Matèrne (jhm) wrote:
AFAIK this was discussed several times in the past (few years) with the
result, that having if/unless an _all_ elements would decrease
maintainability of the build scripts.
But +1 from me for having if/unless on nested elements.
What about supporting more complex conditions via nested condition
elements?
Jan
-Ursprüngliche Nachricht-
Von: Michael Clarke [mailto:michael.m.cla...@gmail.com]
Gesendet: Freitag, 3. Mai 2013 11:01
An: Ant Developers List
Betreff: Re: Adding if/unless conditions on commandline args
+1 from me too
On 3 May 2013, at 09:37, Jean-Louis Boudart
jeanlouis.boud...@gmail.com wrote:
+1
2013/5/3 Antoine Levy Lambert anto...@gmx.de
I wonder whether we could not add if an unless on all nested
elements
in the framework ?
Regards,
Antoine
On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:
Hi,
It's currently difficult to make reusable script when using exec
task
or
any other task using commandline args.
We oftenly need some dynamic arguments and this can be
complicated.
Therefor, i suggest to introduce if/unless conditions on comand
line
args :
exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/ arg value=-m/ arg
value=${commit.message}/ /exec
I have a working implementation with related tests and
documentation.
Commandline.Arg class now extends ProjectComponent, and expose
accessors for if/unless condition, and rely on PropertyHelper to
check conditions.
Is this sufficient ? From what i have seen, it doesn't break
backward compatibility at least all tests are green :p.
The setProject(Project p) method should be invoked automatically
by ProjectHelper isn't it ?
If ant is used in pure java and we ommited invoking
setProject(Project p) method, it should also works as
PropertyHelper seems null safe.
If there is no objection i will commit this this week end.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
additional
commands, e-mail: dev-h...@ant.apache.org
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/
-
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] Michael Clarke as a committer
+1 Peter On Wed, Mar 13, 2013 at 8:08 AM, Conor MacNeill co...@apache.org wrote: On 13 March 2013 04:03, Bruce Atherton br...@callenish.com wrote: 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 disagree [ ] ą0 means I don't care. +1 Conor - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Ant 1.9.0 release [2nd attempt]
+1 Peter On Sun, Mar 10, 2013 at 9:30 AM, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: +1 on the release as is too Works perfectly in easyant :) 2013/3/9 Stefan Bodewig bode...@apache.org +1 on the release as is. On 2013-03-08, Antoine Levy Lambert wrote: You can veto the release if it matters that much to you and I would then have to drop and recreate the 1.9.0 label and do a new build. Maybe I'm picking nits: you can't veto a release, this is a majority vote. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org -- Jean Louis Boudart Independent consultant Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: deprecations
Just had a quick look at Project. There are a lot of deprecated methods. However I do not think that most of them are deprecated correctly. Users of the api should not have to know about implementation details and changes to implementation - for example the FileUtils.getFileUtils(). I downloaded the latest svn trunk version of ant-contrib and compiled it with -Xlint:deprecation. It uses a fair number of ant deprecated methods. Most of the issues could be removed. But... it would mean a new version of ant-contrib that would not work with old versions of ant (a very common occurrence). I would suspect that most 3rd party task collections would have similar issues. A major problem with the ant api is that is it not well specified and so it is too big - it included nearly all the ant implementation, but it is probably too late to fix that now. So, yes I guess I would be opposed. However for deprecated methods that need to be removed because it would be impossible to implement with newer and better implementations, I would have no problem with (perhaps using an implementation that throws an UnsupportedOperationException(dead api). Peter On Wed, Aug 22, 2012 at 12:19 AM, Matt Benson gudnabr...@gmail.com wrote: Hi Peter, So does that mean you would be opposed to removing these deprecated items? Matt On Tue, Aug 21, 2012 at 6:07 PM, Peter Reilly peter.kitt.rei...@gmail.com wrote: The only problem is the there are a lot of tasks out there in the wild that have not been compiled in a very long time. (I know I have uses a number), These will most likely use the deprecated methods, especially in regard to handling of properties and references. Peter 2012/8/20 Martin Gainty mgai...@hotmail.com: Hi Matt as long as there is a new method (or new class) to replace the deprecated method (or deprectaed class) Many Thanks for your diligence! Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 20 Aug 2012 12:52:19 -0500 Subject: deprecations From: gudnabr...@gmail.com To: dev@ant.apache.org Hi gang, There are lots of methods in Ant's source that have been deprecated since e.g. v1.6. Does anyone object to removing deprecated methods for Ant 1.9? Matt - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: deprecations
The only problem is the there are a lot of tasks out there in the wild that have not been compiled in a very long time. (I know I have uses a number), These will most likely use the deprecated methods, especially in regard to handling of properties and references. Peter 2012/8/20 Martin Gainty mgai...@hotmail.com: Hi Matt as long as there is a new method (or new class) to replace the deprecated method (or deprectaed class) Many Thanks for your diligence! Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Mon, 20 Aug 2012 12:52:19 -0500 Subject: deprecations From: gudnabr...@gmail.com To: dev@ant.apache.org Hi gang, There are lots of methods in Ant's source that have been deprecated since e.g. v1.6. Does anyone object to removing deprecated methods for Ant 1.9? Matt - 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: svn commit: r1373836 - /ant/core/trunk/src/main/org/apache/tools/ant/util/DeweyDecimal.java
java 6 allows @Override in this case, but java 5 does not.
On Thu, Aug 16, 2012 at 2:53 PM, jgl...@apache.org wrote:
Author: jglick
Date: Thu Aug 16 13:53:07 2012
New Revision: 1373836
URL: http://svn.apache.org/viewvc?rev=1373836view=rev
Log:
JDK 5 javac is apparently buggy; @Override should be allowed on methods
implemented from an interface.
Modified:
ant/core/trunk/src/main/org/apache/tools/ant/util/DeweyDecimal.java
Modified: ant/core/trunk/src/main/org/apache/tools/ant/util/DeweyDecimal.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/util/DeweyDecimal.java?rev=1373836r1=1373835r2=1373836view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/ant/util/DeweyDecimal.java
(original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/util/DeweyDecimal.java Thu
Aug 16 13:53:07 2012
@@ -207,7 +207,7 @@ public class DeweyDecimal implements Com
return sb.toString();
}
-@Override public int compareTo(DeweyDecimal other) {
+public int compareTo(DeweyDecimal other) {
final int max = Math.max(other.components.length, components.length);
for (int i = 0; i max; i++) {
final int component1 = (i components.length) ? components[ i ]
: 0;
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Drop JDK 1.4 after 1.8.3
+ 1 and move to 1.9 Yey, we may even dabble in these new fangled generics Peter On Mon, Jan 30, 2012 at 8:40 AM, Dominique Devienne ddevie...@gmail.com wrote: On Sat, Jan 28, 2012 at 6:54 AM, Stefan Bodewig bode...@apache.org wrote: On 2012-01-27, Jesse Glick wrote: As suggested in 1.8.3 thread, I propose we drop JDK 1.4 support in trunk after Ant 1.8.3 is released. It is long past EOL http://www.oracle.com/technetwork/java/eol-135779.html and cumbersome to even get installed for testing. (Note that JDK 5 is also past EOL, but I am not proposing dropping JDK 5 support in this vote.) +1 for dropping Java 1.4 support in trunk after 1.8.3. I'm with Maarten that we should switch to 1.9.0 in trunk then. +1. --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
Re: [VOTE] Release Compress Antlib 1.1 based on RC1
+1 Peter On Wed, Nov 2, 2011 at 11:13 AM, Conor MacNeill co...@apache.org wrote: On Wed, Nov 2, 2011 at 17:22, Stefan Bodewig bode...@apache.org wrote: Should this be released as the Compress Antlib 1.1? +1 Conor - 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] Release AntUnit 1.2 - second attempt
+1 Peter On Mon, Aug 15, 2011 at 12:32 PM, Conor MacNeill co...@apache.org wrote: On Sat, Aug 13, 2011 at 15:15, Stefan Bodewig bode...@apache.org wrote: On 2011-08-13, Stefan Bodewig wrote: svn tag (rev 1157319): http://svn.apache.org/repos/asf/ant/antlibs/antunit/tags/1.2/ tarballs and README: http://people.apache.org/~bodewig/antunit-1.2/ Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-034/org/apache/ant/ant-antunit/1.2/ +1 +1 Conor - 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: ZIP64 Support
Personally I think that ant should move to java 1.5 for ant 1.9. Peter On Fri, Jul 29, 2011 at 5:16 AM, Stefan Bodewig bode...@apache.org wrote: Hi all, ZIP64 is the nickname for the changes to the ZIP archive format that are necessary to support files 4GB (both individual entries and complete archives) or archives with more than 64k entries. Ant's ZIP package does not support this and neither does java.util.zip prior to Java7[1]. Over in Commons land I've started to implement ZIP64 support in Commons Compress. Once the code is released the Compress Antlib will transparently support ZIP64 without any changes required there. All you'd need to do is upgrading Commons Compress. In order to implement it, Commons Compress must switch to Java5 as the few parts of java.util.zip that are used in CC (Inflater/Deflater) have an issuficient API for big entries (getTotalIn returns an int which is too small, getBytesRead which returns a long has been added in Java5). Since Ant is stuck with Java 1.4 for now I do not plan to backport the changes from Commons Compress over to Ant's ZIP package. The reflection needed will be too much and I've started to embrace generics and other Java5 features in the modified code base, so porting is just too painful. Users that need ZIP64 can be pointed to the Compress Antlib IMHO. Stefan [1] Java7 claims to support it but from what I've seen the OpenJDK implementation is likely wrong. I'll dig into OpenJDK's code at one point in time and open a bug report if my suspicion remains true. - 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: antcontrib settings
You have not passed in the classpath to the taskdef.
You need to do something like:
taskdef classname=net.sf.antcontrib.logic.For name=for
classpath
pathelement location=lib/ant-contrib-1.0b3.jar/
/classpath
/taskdef
On Tue, Mar 1, 2011 at 11:40 AM, Ajitesh ajites...@yahoo.com wrote:
hi
I am trying to use the FOR loop present in antcontrib jar file - ant-contrib-
1.0b3.jar in my build.xml;
but getting below error while running the
D:\buildFRIDAYant
Buildfile: D:\buildFRIDAY\build.xml
BUILD FAILED
D:\buildFRIDAY\build.xml:5: taskdef class net.sf.antcontrib.logic.For cannot
be
found using the classloader AntClassLoader
MY Build.xml file is as below:-
project name=ObieeBuild default=init basedir=.
description
obiee copy files build file
/description
taskdef classname=net.sf.antcontrib.logic.For name=for/
classpath
pathelement path=${classpath}/
pathelement location=lib/ant-contrib-1.0b3.jar/
/classpath
!-- set global properties for this build --
property name=test location=test/
target name=init description=copying obiee files
echo message=The first five letters of the alphabet are:/
for list=a,b,c,d,e param=letter
sequential
echoLetter @{letter}/echo
/sequential
/for
/target
/project
thanks
Ajitesh
-
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: svn commit: r1066963 - in /ant/core/trunk/src/main/org/apache/tools: ant/ ant/taskdefs/ ant/taskdefs/cvslib/ ant/taskdefs/email/ ant/taskdefs/optional/ ant/taskdefs/optional/depend/ ant/taskdefs/o
It depends on the cost of .size(), it is done on each run of the body
and cannot be optimized by the compiler (.size() could change during
the loop).
A common pattern is to do:
for (int i = 0, len = x.size(); i len; ++i) {
...
}
Peter
On Fri, Feb 4, 2011 at 2:03 PM, Antoine Levy-Lambert anto...@gmx.de wrote:
Hello Stefan,
I did not know that using a final variable for the upper bound of a loop
instead of something.size() makes a difference in terms of performance.
Interesting.
I just read the original bug report Project.fireMessageLoggedEvent
performance fix [1] and the one you have addressed [2].
In an ideal world, should the compiler not do these optimizations for us
automatically ?
Regards,
Antoine
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=19101
[2] https://issues.apache.org/bugzilla/show_bug.cgi?id=50716
On 2/3/2011 4:00 PM, bode...@apache.org wrote:
Author: bodewig
Date: Thu Feb 3 21:00:00 2011
New Revision: 1066963
URL: http://svn.apache.org/viewvc?rev=1066963view=rev
Log:
microoptimizations. PR 50716
Modified:
ant/core/trunk/src/main/org/apache/tools/ant/IntrospectionHelper.java
ant/core/trunk/src/main/org/apache/tools/ant/Main.java
ant/core/trunk/src/main/org/apache/tools/ant/Target.java
ant/core/trunk/src/main/org/apache/tools/ant/UnknownElement.java
.
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/mail/MailMessage.java?rev=1066963r1=1066962r2=1066963view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/mail/MailMessage.java
(original)
+++ ant/core/trunk/src/main/org/apache/tools/mail/MailMessage.java Thu Feb
3 21:00:00 2011
@@ -328,7 +328,8 @@ public class MailMessage {
// Header fields are NOT required to occur in any particular
order,
// except that the message body MUST occur AFTER the headers
// (the same section specifies a reccommended order, which we ignore)
- for (int i = 0; i headersKeys.size(); i++) {
+ final int size = headersKeys.size();
+ for (int i = 0; i size; i++) {
String name = (String) headersKeys.elementAt(i);
String value = (String) headersValues.elementAt(i);
out.println(name + : + value);
-
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] Second Attempt to Release .NET Antlib 1.1
+1 Peter On Fri, Jan 28, 2011 at 6:34 AM, Conor MacNeill co...@apache.org wrote: On Fri, Jan 28, 2011 at 16:02, Stefan Bodewig bode...@apache.org wrote: Hi, after fixing the NOTICE file and applying the trademark policy I've rebuilt the distribution from svn revision 1064451 of http://svn.apache.org/repos/asf/ant/antlibs/dotnet/tags/1_1/ Tarballs at http://people.apache.org/~bodewig/dotnet/, Maven artifacts at https://repository.apache.org/content/repositories/orgapacheant-087/. I hereby call for a vote to release these files as Apache .NET Ant Library 1.1. Stefan +1 Conor - 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: Ant Eclipse integration
I thought that there was a problem with the removal of out-of-target reference resolution with moving to ant 1.8.0. ... ah, looking at the bug report, that is still an issue. https://issues.apache.org/bugzilla/show_bug.cgi?id=49659 Peter On Wed, Jan 5, 2011 at 4:57 PM, Antoine Levy-Lambert anto...@gmx.de wrote: On 1/5/2011 11:34 AM, Antoine Levy-Lambert wrote: Hi, the version of ant which currently ships with Eclipse is as far as I know 1.7.1 ( I think so because there is a directory called org.apache.ant_1.7.1.v20100518-1145 in my plugins folder). I have read that the platform-ant team of Eclipse is preparing a new version of the Ant Eclipse integration with some support for newer syntactic constructs of ant 1.8.x [1] Oops - the bug report says that in fact the new version of the integration does not support new constructs introduced in 1.8.x but fixes other bugs. Sorry. This bug report [1] is inviting people to try out the new Eclipse Ant integration for ant 1.8.x. I have thought that some of us can be interested Regards, Antoine [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=302296 - 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] third attempt - release of ant 1.8.2
+1 Peter On Wed, Dec 22, 2010 at 4:11 PM, Stefan Bodewig bode...@apache.org wrote: On 2010-12-20, Antoine Levy-Lambert wrote: 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 candidate. Thank you. The new release candidate is available for download from http://people.apache.org/~antoine/dist/ a second release candidate of ant 1.8.2. I also updated the previsional release date to be December 27th 2010. Let's vote to release it as apache-ant-1.8.2. +1 Stefan - 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] Accept Bushel Donation
+1 Peter On Fri, Nov 5, 2010 at 2:45 PM, Stefan Bodewig bode...@apache.org wrote: Hi, the people behind Bushel[1] want to donate their code to Ivy[2] and before I can start the formal IP clearance process we can and should vote whether we want to accept the donation at all. So, do we want to accept the Bushel donation? Stefan [1] Original: http://code.google.com/p/bushel/ Donated Code: https://issues.apache.org/jira/browse/IVY-1241 [2] http://mail-archives.apache.org/mod_mbox/ant-dev/201010.mbox/%3cb53d948c-5da9-48d8-b81d-2f8c44dba...@hibnet.org%3e - 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] Apache Compress Antlib 1.0 - Take 2
+1 Peter On Wed, Aug 25, 2010 at 6:49 PM, Bruce Atherton br...@callenish.com wrote: +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 - 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: Vote to promote VSS antlib out of sandbox
+1 Peter On Wed, Aug 25, 2010 at 7:06 PM, Bruce Atherton br...@callenish.com wrote: +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 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: warning: 'includeantruntime' was not set
We have a policy of keeping stupid historical defaults. Peter On Wed, Aug 18, 2010 at 10:21 PM, Jesse Glick jesse.gl...@oracle.com wrote: On 08/18/2010 02:27 PM, Matt Benson wrote: I would still guess that more builds than not DON'T need to compile against Ant itself. Of course; at least an order of magnitude more. But those that do will be *broken* if your suggested change is made, whereas those that don't get a *warning* currently. My inclination was to err on the conservative side and retain compatibility even at the cost of a little inconvenience. Call a vote if you want to change the default and break compatibility. 1.8.0 and 1.8.1 have the warning, so a break in 1.8.2 would only affect those who ignored the warning for two prior releases. I don't know if Ant generally has a policy for fixing stupid historical defaults, like failonerror=false. - 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] Release Manuals of Last Five Ant Releases
+1 release the manuals
On Mon, Jul 19, 2010 at 3:21 PM, Stefan Bodewig bode...@apache.org wrote:
Hi,
I don't really think this requires a vote since I've just repackaged
existing distributions (see buildfile at the end of the mail for
details), but it won't hurt.
In http://people.apache.org/~bodewig/manual/ there are ZIP and
tar.gz/bz2 files containing the manuals of the releases 1.6.5 to 1.8.1.
The contents are similar to the manual tarballs that will be created by
the distribution target in trunk's build.xml.
I'd like to release those to the public, so please cast your vote:
[ ] +1 release them
[ ] 0 don't care
[ ] -1 no, don't release them
The plan is to create a manual directory inside Ant's distribution area
right next to the source and binaries directories and copy over all
files from http://people.apache.org/~bodewig/manual/. In addition I'd
create -current symlinks just like we have for source and binaries.
Once the mirrors have picked up all files I'd delete the archives for
1.6.5 to 1.8.0 so they remain on archives.apache.org only.
Furthermore I'll add a new download page for the manual and link to it
from the cover page (if you are looking for an older version ...) and
the API docs page (if you are looking for javadocs ...) of the Ant
website.
Stefan
PS: this is how I created the files, most of it stolen from trunk's
build.xml.
project
mkdir dir=work/
macrodef name=checksums-mvn description=only md5 and sha1 are needed for
the maven directory structure
element name=resources implicit=true/
sequential
checksum algorithm=md5
resources/
/checksum
checksum algorithm=sha1
resources/
/checksum
/sequential
/macrodef
macrodef name=checksums
element name=resources implicit=true/
sequential
checksums-mvn
resources/
/checksums-mvn
checksum fileext=.sha512 algorithm=sha-512
resources/
/checksum
/sequential
/macrodef
macrodef name=get-and-zip
attribute name=version/
sequential
get
src=http://archive.apache.org/dist/ant/binaries/apache-a...@{version}-bin.tar.bz2;
dest=work/
untar src=work/apache-a...@{version}-bin.tar.bz2 dest=work
compression=bzip2/
mkdir dir=work/manual/
zip destfile=work/manual/apache-a...@{version}-manual.zip
zipfileset dir=work/apache-a...@{version}/docs/manual
prefix=apache-a...@{version}/
zipfileset file=work/apache-a...@{version}/NOTICE
prefix=apache-a...@{version}/
/zip
tar longfile=gnu
destfile=work/manual/apache-a...@{version}-manual.tar
tarfileset dir=work/apache-a...@{version}/docs/manual
prefix=apache-a...@{version}/
tarfileset file=work/apache-a...@{version}/NOTICE
prefix=apache-a...@{version}/
/tar
gzip destfile=work/manual/apache-a...@{version}-manual.tar.gz
src=work/manual/apache-a...@{version}-manual.tar/
bzip2 destfile=work/manual/apache-a...@{version}-manual.tar.bz2
src=work/manual/apache-a...@{version}-manual.tar/
delete file=work/manual/apache-a...@{version}-manual.tar/
/sequential
/macrodef
get-and-zip version=1.6.5/
get-and-zip version=1.7.0/
get-and-zip version=1.7.1/
get-and-zip version=1.8.0/
get-and-zip version=1.8.1/
checksums
fileset dir=work/manual/
exclude name=**/*.asc/
exclude name=**/*.md5/
exclude name=**/*.sha1/
exclude name=**/*.sha512/
/fileset
/checksums
/project
-
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 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: [DISCUSS] Commercial Tasks in Ant
On Fri, Jun 11, 2010 at 8:29 PM, Bruce Atherton br...@callenish.com wrote: 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 commercial task (is there any reason to include the CVS tasks with Ant today?), but it will be a start. I can add CVS to the list if there are no objections. Any other tasks to nominate for transfer to an antlib? ekk no, I think that a lot of build scripts in the wild depend on the cvs tasks, and would be quite expensive to fix if they are to be moved to an antlib, we should have an ivy (or similar) based auto loading of the antlib. Peter - EJB Tasks: Note that there may no longer be a need for these as the servers are very old, we could instead deprecate and eventually get rid of. +1 So a separate vote for these to be deprecated in the next release and removed in the release after that? One other thing. I think the vote should be to move these to their own separate antlibs in the sandbox. That will clearly indicate that they are unsupported. My only concern is with the difficulty in getting them out of the sandbox once we have a volunteer or two to maintain them, as happened with VSS. I'm not sure what the answer should be for this problem. - 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: Ant source structure and ant*.jar build products
That is not what I meant. I meant dependences for maven pom files. We would have an jar file (for example ant-commons-logging.jar that did not contain any classes) and have a pom file like: project parent groupIdorg.apache.ant/groupId artifactIdant-parent/artifactId relativePath../pom.xml/relativePath version1.8.2/version /parent modelVersion4.0.0/modelVersion groupIdorg.apache.ant/groupId artifactIdant-commons-logging/artifactId version1.8.2alpha/version descriptionAnt Listener based on commons-logging/description dependencies dependency groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.8.2/version scopecompile/scope /dependency dependency groupIdcommons-logging/groupId artifactIdcommons-logging-api/artifactId version1.0.4/version scopecompile/scope /dependency /dependencies /project This would allow maven users to use ant.jar and specify which optional parts are needed. Peter On Tue, May 18, 2010 at 6:17 AM, jan.mate...@rzf.fin-nrw.de wrote: We could have dummy jar's for dependences. Peter You could use https://svn.apache.org/repos/asf/ant/sandbox/mocks ;-) Jan - 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: Ant source structure and ant*.jar build products
We could have dummy jar's for dependences. Peter On Fri, May 14, 2010 at 11:15 PM, Jesse Glick jesse.gl...@oracle.com wrote: On 05/14/2010 04:00 PM, Peter Reilly wrote: Personally I think that there should be only one ant.jar file ... and not loads of itty-bitty ones. This would break usage from Maven repositories, for which separate POMs with separate dependency lists are created. - 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: Ant source structure and ant*.jar build products
On Fri, May 14, 2010 at 11:56 PM, Antoine Levy-Lambert anto...@gmx.de wrote: Hello Jesse, Jesse Glick wrote: In relation to https://issues.apache.org/bugzilla/show_bug.cgi?id=49287: 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 according to classpath availability, and then packing classes to different JARs, is difficult to understand and debug, and it is too easy to accidentally put a class in the wrong JAR. Would be much easier to manage (and possibly more friendly to IDEs) if classes were split into several physical source roots. Each root would: 1. Compile all classes beneath it (if the root is compiled at all). +1 2. Use a particular classpath, including binary outputs of upstream roots plus any third-party library dependencies. +1 3. Produce the contents of one JAR in the distribution. +1 What do other committers think about such a change? Is there some advantage to having all (non-test) sources mixed together in one tree, other than to provide an advanced demo of selector? (Since we are using Subversion, losing file history after a move is no longer a consideration.) I would also like a clear explanation of what ant-nodeps.jar is supposed to be, as distinct from ant.jar. Both include tasks that we have always shipped and which do not need any third-party libraries. So what's the difference? The include set seems to be rather arbitrary. Some things that require newer Java Platform APIs are also in there, which you would expect to be in their own ant-jdk5.jar or ant-jdk6.jar. ant-nodeps.jar contains classes belonging to so-called optional tasks. There are some tasks such as for instance propertyfile which are only using the JDK and ant's own classes and are categorized as optional tasks. In ant 1.5, there was just ant.jar and ant-optional.jar. When ant-optional.jar was broken up, the classes without any external, non ant, library dependencies were added to ant-nodeps.jar. It also seems unpleasant to make parts of the build work only conditionally. I think that for any third-party libraries needed by the build, we should either include them in lib/optional in the Subversion tree (or download from a well-known repository on demand), or move the corresponding tasks to an antlib if nonfree JARs are involved. But perhaps there are special considerations here for Linux packagers. there is a problem with some libraries such as NetRexx or jai which have non BSD licenses. I think nearly all other dependencies can be downloaded using ant -f fetch.xml. I would not check in jars under lib/optional. I am not sure what we can do about NetRexx and jai. How to contact IBM to get them to publish the NetRexx jars to a public repository with a BSD license ? Same for Oracle-Sun concerning jai. Yes, this is a problem. Peter Regards, Antoine - 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] use nexus for maven upload of ant release
+1 to all and +1 to doc howto Peter On Fri, May 14, 2010 at 10:47 AM, Kevin Jackson foamd...@gmail.com wrote: Hi, This wasnt part of the vote, but I am also +1 for putting the upload procedure in a common.xml +1 +1 for using Ivy for uploading +1 +1 for including a src.zip into our distro (was asked by Brian on https://issues.apache.org/jira/browse/INFRA-2706) I like getting information by the IDE when using APIs ... +1 Good ideas Kev - 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: Ant source structure and ant*.jar build products
Personally I think that there should be only one ant.jar file (as was the case in ant 1.5 - well two) and not loads of itty-bitty ones. Peter On Fri, May 14, 2010 at 7:08 PM, Jesse Glick jesse.gl...@oracle.com wrote: In relation to https://issues.apache.org/bugzilla/show_bug.cgi?id=49287: 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 according to classpath availability, and then packing classes to different JARs, is difficult to understand and debug, and it is too easy to accidentally put a class in the wrong JAR. Would be much easier to manage (and possibly more friendly to IDEs) if classes were split into several physical source roots. Each root would: 1. Compile all classes beneath it (if the root is compiled at all). 2. Use a particular classpath, including binary outputs of upstream roots plus any third-party library dependencies. 3. Produce the contents of one JAR in the distribution. What do other committers think about such a change? Is there some advantage to having all (non-test) sources mixed together in one tree, other than to provide an advanced demo of selector? (Since we are using Subversion, losing file history after a move is no longer a consideration.) I would also like a clear explanation of what ant-nodeps.jar is supposed to be, as distinct from ant.jar. Both include tasks that we have always shipped and which do not need any third-party libraries. So what's the difference? The include set seems to be rather arbitrary. Some things that require newer Java Platform APIs are also in there, which you would expect to be in their own ant-jdk5.jar or ant-jdk6.jar. It also seems unpleasant to make parts of the build work only conditionally. I think that for any third-party libraries needed by the build, we should either include them in lib/optional in the Subversion tree (or download from a well-known repository on demand), or move the corresponding tasks to an antlib if nonfree JARs are involved. But perhaps there are special considerations here for Linux packagers. - 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] release of ant 1.8.1
I am not too sure that I like the warning: /home/preilly/scm/svn/nft-trunk/build.xml:61: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds when using javac without setting the includeantruntime attribute. (not too sure if this was added in ant 1.8 or ant 1.8.1) Peter On Wed, May 5, 2010 at 3:43 PM, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: +1 no issue here with easyant Regards, 2010/5/1 Antoine Levy-Lambert anto...@gmx.de Hi, I have uploaded a candidate for ant 1.8.1 under http://people.apache.org/~antoine/dist/http://people.apache.org/%7Eantoine/dist/ Also a label ANT_181 has been created in the repository. Vote to release this build as ant 1.8.1 [ ] Yes [ ] No Regards, Antoine - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] release of ant 1.8.1
ok, scratch that, the warning happens for ant 1.8.0 as well :-( So +1 for the 1.8.1 release. Peter On Wed, May 5, 2010 at 4:01 PM, Peter Reilly peter.kitt.rei...@gmail.com wrote: I am not too sure that I like the warning: /home/preilly/scm/svn/nft-trunk/build.xml:61: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds when using javac without setting the includeantruntime attribute. (not too sure if this was added in ant 1.8 or ant 1.8.1) Peter On Wed, May 5, 2010 at 3:43 PM, Jean-Louis Boudart jeanlouis.boud...@gmail.com wrote: +1 no issue here with easyant Regards, 2010/5/1 Antoine Levy-Lambert anto...@gmx.de Hi, I have uploaded a candidate for ant 1.8.1 under http://people.apache.org/~antoine/dist/http://people.apache.org/%7Eantoine/dist/ Also a label ANT_181 has been created in the repository. Vote to release this build as ant 1.8.1 [ ] Yes [ ] No Regards, Antoine - 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: includeantruntime warning (was: [VOTE] release of ant 1.8.1)
Just did not like the presence of the warning,since
it will hit nearly every ant build file out there.
Still it is in ant 1.8.0 so no need to change it now.
Peter
On Wed, May 5, 2010 at 5:28 PM, Jesse Glick jesse.gl...@oracle.com wrote:
Peter Reilly wrote:
I am not too sure that I like the warning:
'includeantruntime' was not set, defaulting to build.sysclasspath=last;
set to false for repeatable builds
You don't like the text of the warning message, or the fact that there is a
warning at all?
I have just seen a lot of build scripts which used the historical default of
true, thus including ant.jar etc. in the classpath of quite unrelated code.
(In the unusual case that you are in fact compiling Ant tasks, adding
${ant.core.lib} to the classpath makes this explicit.) Besides permitting
code to compile against classes it might not have accessible at runtime, I
found that this interfered with dynamic analysis of the compile-time
classpath for purposes of http://wiki.netbeans.org/AutomaticProjects.
Since changing the default would be incompatible, it seemed better to warn
about what was almost always a mistake. This is analogous to the warning
printed when you neglect to set a source level and Ant defaults to the
version of the executing JDK.
(not too sure if this was added in ant 1.8 or ant 1.8.1)
1.8.0.
-
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: [POLL] Bug 48804
+1 for fixing Peter On Fri, Apr 23, 2010 at 3:37 PM, Stefan Bodewig bode...@apache.org wrote: On 2010-04-23, Dominique Devienne ddevie...@gmail.com wrote: On Fri, Apr 23, 2010 at 4:29 AM, Stefan Bodewig bode...@apache.org wrote: [...] Personally I think the changed behavior isn't a bad thing, the old behavior isn't documented and we shouldn't even try to keep it. I agree. Fixing the primary use-case trumps this particular behavior. If we can't fix the bug without allow this ahead-of-time use of the extension point, it's no big deal to me. Technically we could also disallow it, but it would take some additional effort that I'm not sure is worth it, that's why I started this poll. Thanks Stefan - 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: task that allows augmentation of previously declared references
I agree, datatypes are mutable, properties are not, why add this complexity of final. Peter On Wed, Mar 3, 2010 at 9:13 PM, Antoine Levy Lambert anto...@gmx.de wrote: Hi, I was thinking that ant datatypes are currently de-facto mutable by default. Maybe we are making this too complex. Of course, only users who can write custom tasks in java or javascript/groovy/... can for instance add an include pattern to an existing fileset, but there is nothing preventing them from doing it. Antoine Gilles Scokart wrote: I just have an idea that come into my mind. I will quickly post it (and probably think it's stupid tomorow morning). Instead of a special id, we could maybe use a decorator : mutabletype id=x path ... / /mutabletype Probably stupid, certainly not trivial to implement, but make it obvious that's a quiet special structure that should be used carrefully. Gilles Scokart On 3 March 2010 05:52, Stefan Bodewig bode...@apache.org wrote: On 2010-03-02, Matt Benson gudnabr...@gmail.com wrote: Okay, let's reason this out... since tasks and types are Java objects can we assume that a Java property final is unlikely enough to be used that we can use it as a configuration attribute? Agreed. An alternative could be anything that contains a dash or any other character that would be illegal in a Java method name (so you can't have a set-method for it). Now, any id'd item would declare final=false if it wanted to be augmentable. This would require changes in the way we handle references, but would seem doable. +1 Stefan - 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: Command Line Property Overrides Broken in trunk
Could be the change I made to the propertymap the other day.
Peter
On Wed, Feb 24, 2010 at 5:20 AM, Stefan Bodewig bode...@apache.org wrote:
Hi all,
many of the latest Gump builds stopped working, see
http://vmgump.apache.org/gump/public/project_todos.html and look at
those with duration in state equal to 1 (or 2 if you read this mail in
a few hours).
Common to all those failures is something like this:
build.xml:
project
property name=version value=X.Y/
jar destfile=project-${version}.jar .../
/project
$ ant -Dversion=A
[jar] Building jar: project-X.Y.jar
Has anything broken command line properties or property immutability?
I haven't found any time to look into it but maybe anybody else recalls
the latest changes and can pinpoint the problem.
Stefan
-
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: BZ 48768: Properties wrongly read from file or not update during read
I think that we will just have to put the old code (1.7) back in. Peter On Wed, Feb 24, 2010 at 4:10 PM, Stefan Bodewig bode...@apache.org wrote: On 2010-02-18, Matt Benson gudnabr...@gmail.com wrote: This problem happens in src/main/org/apache/tools/ant/property/ ResolvePropertyMap.java . Peter, you extracted this class some two years ago, but at the point in the code at which the offense takes place, there is the comment: // Note: the master overrides (even if the name is subsequently // prefixed) If you trace it back to the older code you'll see it corresponds to a check whether the property is defined outside of the map as well - and if it is use the outside value - to enforce property immutability. To account for the bug report it may be a good idea to ignore existing properties only if we are importing with a prefix. This does require adding a new overload with a prefix argument, but it's the only way we can re-gain the old behavior for property files AFAICS. Stefan - 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: BZ 48768: Properties wrongly read from file or not update during read
Great news. Peter On Wed, Feb 24, 2010 at 4:22 PM, Stefan Bodewig bode...@apache.org wrote: On 2010-02-24, Stefan Bodewig bode...@apache.org wrote: To account for the bug report it may be a good idea to ignore existing properties only if we are importing with a prefix. and look for an existing property with the prefix when using one. I have a modified version that passes the testcase I've added for 48768 and a new one I've written for the Gump is broken scenario and will commit it as soon as it has completed the full test suite (about fifteen minutes from now). Stefan - 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: BZ 48768: Properties wrongly read from file or not update during read
I think that I was trying to allow the map to be used in a stack of property maps. But looking at the original code for Property in 1.7, I got it wrong, so I have removed the test. Peter On Fri, Feb 19, 2010 at 2:57 PM, Peter Reilly peter.kitt.rei...@gmail.com wrote: Looks like a bad bug. Will have a look during the weekend. Peter On Thu, Feb 18, 2010 at 8:33 PM, Antoine Levy-Lambert anto...@gmx.de wrote: Hello Matt, Datum: Thu, 18 Feb 2010 12:27:26 -0600 Von: Matt Benson gudnabr...@gmail.com An: Ant Developers List dev@ant.apache.org Convenience link: https://issues.apache.org/bugzilla/show_bug.cgi?id=48768 The behavior reported in BZ does seem counter-intuitive and wrong. Agreed. Thanks, Matt Antoine - 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: BZ 48768: Properties wrongly read from file or not update during read
Looks like a bad bug. Will have a look during the weekend. Peter On Thu, Feb 18, 2010 at 8:33 PM, Antoine Levy-Lambert anto...@gmx.de wrote: Hello Matt, Datum: Thu, 18 Feb 2010 12:27:26 -0600 Von: Matt Benson gudnabr...@gmail.com An: Ant Developers List dev@ant.apache.org Convenience link: https://issues.apache.org/bugzilla/show_bug.cgi?id=48768 The behavior reported in BZ does seem counter-intuitive and wrong. Agreed. Thanks, Matt Antoine - 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] [second attempt] release of ant 1.8.0
I have installed and used 1.8 rc for our build env. Everything looks good. so +1 from me On Sat, Feb 6, 2010 at 8:02 AM, Martijn Kruithof j...@apache.org wrote: On 2-2-2010 2:12, Antoine Levy Lambert wrote: The new build incorporates the fix for the junit stack traces issue. a candidate for ant 1.8.0 is available under http://people.apache.org/~antoine/dist/apache-ant-1.8.0/ Vote [x] Release as Apache Ant 1.8.0 [] Do not release yet +1 Martijn - 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: Gertting Reference ejb.classpath not found while using Ant 1.8 RC1
When using ant 1.7, did you see a warning about references?
Peter
On Thu, Jan 28, 2010 at 9:12 AM, Suman N suma...@curamsoftware.com wrote:
Hi,
We are testing the compatibility of our build scripts with Ant 1.8 RC1 and
we encounter the following error when referring a path refid in our script.
D:\CC\suman.n_TI_MAIN_3\TIVOB\build_scripts\test.xml:579: The following
error occurred while executing this line:
D:\CC\suman.n_TI_MAIN_3\TIVOB\build_scripts\test.xml:632: The following
error occurred while executing this line:
D:\CC\suman.n_TI_MAIN_3\TIVOB\build_scripts\test.xml:672: The following
error occurred while executing this line:
D:\CC\suman.n_TI_MAIN_3\TIVOB\build_scripts\test.xml:703: Reference
ejb.classpath not found.
We are defining a path element in the ‘wlstest’ target (Line 573 in attached
test.xml)
target name=wlstest
description=Runs in-container tests against WLS and produces a
report.
antcall target=clean inheritAll=false/
path id=ejb.classpath
pathelement location=${WLS_HOME}/lib/weblogic.jar/
/path
!-- 36877: Must set inheritall to true here, or the test failure
override
does not get propagated and clover fails before producing a report.
--
antcall target=wlstest.without.clean inheritAll=true/
/target
We refer to this “path” in another part of the build script: (line 719 in
the attached test.xml file)
classpath
path refid=junit.common.classpath/
path refid=ejb.classpath/
path refid=zos.ejb.classpath/
path refid=nas.ejb.classpath/
pathelement path=${jar.wsdl4j}/
!-- stubs of the beans --
pathelement path=${dir.test.lib}/stubs.jar/
/classpath
The build script basically tests all the tests which depend on the
application server (Oracle weblogic in this case).
This error does not occur when using Ant 1.7.0 version.
Can you please let me know what has changed in Ant 1.8 RC1 that is causing
the issue. Please let me know the workaround or fix for this?
Cheers,
Suman.N
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.
-
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: Gertting Reference ejb.classpath not found while using Ant 1.8 RC1
This happens when an id is defined in a target that is not run,
for example:
project default=abc
target name=abc
... use id x here
/target
target name=not_run
fileset id=x ...
/target
/project
The warning in 1.7.x was that x was not defined, so ant would read the
full build file and find a random x id and use that one. This causes a
lot of problems ... and the ant code to do this was difficult to maintain.
So on ant 1.7 the big dirty warning message was placed in - and many
years later (the future in the warning message), the hacking code
in ant has been removed.
Peter
On Thu, Jan 28, 2010 at 2:57 PM, Suman N suma...@curamsoftware.com wrote:
Hi,
When using Ant 1.7, I get the following warning.
Warning: Reference ejb.classpath has not been set at runtime, but was found
during
build file parsing, attempting to resolve. Future versions of Ant may support
referencing ids defined in non-executed targets.
I understand that I am doing something wrong here. I am new to Ant and I
don’t understand what a non-executed target is.
Can you please suggest what should be done to rectify the issue, while using
1.8RC1?
Thanks,
Suman.N
-Original Message-
From: Peter Reilly [mailto:peter.kitt.rei...@gmail.com]
Sent: 28 January 2010 15:27
To: Ant Developers List
Subject: Re: Gertting Reference ejb.classpath not found while using Ant
1.8 RC1
When using ant 1.7, did you see a warning about references?
Peter
On Thu, Jan 28, 2010 at 9:12 AM, Suman N suma...@curamsoftware.com wrote:
Hi,
We are testing the compatibility of our build scripts with Ant 1.8 RC1 and
we encounter the following error when referring a path refid in our script.
D:\CC\suman.n_TI_MAIN_3\TIVOB\build_scripts\test.xml:579: The following
error occurred while executing this line:
D:\CC\suman.n_TI_MAIN_3\TIVOB\build_scripts\test.xml:632: The following
error occurred while executing this line:
D:\CC\suman.n_TI_MAIN_3\TIVOB\build_scripts\test.xml:672: The following
error occurred while executing this line:
D:\CC\suman.n_TI_MAIN_3\TIVOB\build_scripts\test.xml:703: Reference
ejb.classpath not found.
We are defining a path element in the ‘wlstest’ target (Line 573 in attached
test.xml)
target name=wlstest
description=Runs in-container tests against WLS and produces a
report.
antcall target=clean inheritAll=false/
path id=ejb.classpath
pathelement location=${WLS_HOME}/lib/weblogic.jar/
/path
!-- 36877: Must set inheritall to true here, or the test failure
override
does not get propagated and clover fails before producing a report.
--
antcall target=wlstest.without.clean inheritAll=true/
/target
We refer to this “path” in another part of the build script: (line 719 in
the attached test.xml file)
classpath
path refid=junit.common.classpath/
path refid=ejb.classpath/
path refid=zos.ejb.classpath/
path refid=nas.ejb.classpath/
pathelement path=${jar.wsdl4j}/
!-- stubs of the beans --
pathelement path=${dir.test.lib}/stubs.jar/
/classpath
The build script basically tests all the tests which depend on the
application server (Oracle weblogic in this case).
This error does not occur when using Ant 1.7.0 version.
Can you please let me know what has changed in Ant 1.8 RC1 that is causing
the issue. Please let me know the workaround or fix for this?
Cheers,
Suman.N
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.
-
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
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you are not the intended
addressee please contact the sender and dispose of this e-mail. Thank you.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h
Re: [VOTE] New committer - Jon Schneider
+1 Peter On Tue, Nov 3, 2009 at 7:25 AM, jan.mate...@rzf.fin-nrw.de wrote: +1 Jan -Ursprüngliche Nachricht- Von: Conor MacNeill [mailto:co...@apache.org] Gesendet: Montag, 2. November 2009 23:06 An: Ant Developers List Betreff: Re: [VOTE] New committer - Jon Schneider Matt Benson wrote: Please vote whether to admit Jon Schneider as an Ant committer for his contributions to Ivy and IvyDE. Voting is open for one week. Remember that although only PMC votes are binding, anyone may give his opinion. +1 Conor - 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: [VOTE] Promote the Compress Antlib
+1 Peter On Fri, Oct 9, 2009 at 9:03 AM, Stefan Bodewig bode...@apache.org wrote: On 2009-10-09, Stefan Bodewig bode...@apache.org wrote: As a first step I propose to promote the Antlib from the sandbox to a proper Antlib. +1 Stefan - 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: if/unless Attributes
using target name=x if=${foo}
seems to be very very strange..
Peter
On Thu, Sep 24, 2009 at 5:09 PM, Stefan Bodewig bode...@apache.org wrote:
On 2009-09-24, Stefan Bodewig bode...@apache.org wrote:
target if=${foo}/
will only be executed if a property named ${foo} exists (unexpanded) -
in Ant 1.7.1. and Ant 1.8.0 - or if expanding ${foo} returns something
that equals Boolean.TRUE (Ant 1.8.0 only).
This part is false, I just re-read the code. It will look up a property
named like the expansion of ${foo} - and it's been that way in 1.7.1 as
well.
This doesn't change the rest of what I wrote, you'd still need
target if=${foo}/ if you wanted to skip a target if foo evaluated to
false.
Stefan
-
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: PropertyHelper API
Yes, I think that I added the null return to allow local properties.
Peter
On Tue, Sep 1, 2009 at 1:08 PM, Matt Bensongudnabr...@yahoo.com wrote:
--- On Tue, 9/1/09, Stefan Bodewig bode...@apache.org wrote:
From: Stefan Bodewig bode...@apache.org
Subject: PropertyHelper API
To: dev@ant.apache.org
Date: Tuesday, September 1, 2009, 4:59 AM
Hi
I'm trying to grok the changes to the PropertyHelper in
order to
document them for 1.8.0 - and maybe to suggest throwing in
some more
built-in delegates, but that's for a different thread.
From what I understand:
The default PropertyHelper splits its work into several
steps that can
be delegated to custom implementations. These steps
are:
* finding a property reference inside a string.
The delegate interface is
oata.property.PropertyExpander.
There are two built-in expanders, one that
finds ${foo} positions
the parser after the '}' and says here is
property foo' and one
that finds $$, positions the parser after the
second $ (actually at
the second $) and says no property to be
seen here.
This is the interface I'd implement if I
wanted a completely
different property syntax. I'd also
need to implement it if I
wanted to allow nested properties ${${foo}}
since the default
PropertyExpander doesn't balance braces.
Note that the props antlib does provide a NestedPropertyExpander, so you're
right on track.
* mapping a property to a value
The delegate interface is
oata.PropertyHelper.PropertyEvaluator.
There are two built-in implementations, one
implements local
properties and one implements the toString:
protocol,
i.e. ${toString:some-refid} =
find-reference-in-project.toString()
This is the interface I'd implement if I
- want to provide a different protocol like
toString:
- want to provide a different storage for
properties, this would be
the reading part of it.
Normal project properties are not
implemented via
PropertyEvaluator but implemented via
fallback mechanisms in the
default PropertyHelper implementation.
PropertyEvaluator can return Object but it
will be turned into a
String unless the whole string that was
expanded is consumed by the
property (i.e. ${foo} can become an Object
while ${foo} bar van
not).
PropertyEvaluator can return an instance of
the magical
oata.property.NullReturn class which means I
really really mean it
when I say the property expands to null
because simply returning
null means I don't know this property.
* storing the value for a property somewhere
The delegate interface is
oata.PropertyHelper.PropertySetter.
The only built-in implementation is for local
properties.
This is the interface I'd implement if I
- want to provide a different storage for
properties, this would be
the writing part of it.
Normal project properties are not
implemented via
PropertySetter but implemented via fallback
mechanisms in the
default PropertyHelper implementation.
PropertySetter returns a flag indicating
whether it has consumed the
property - otherwise the other delegates are
consulted and
ultimately the fallback to project properties
is used.
The properthelper task can be used to register
custom delegates.
Delegates are used in LIFO order that is custom delegates
are able to
override built-in delegates.
Is this correct and somewhat complete (Matt?)?
The NullReturn thing, IIRC, was added by Peter. But I think you're correct
about it. Everything else sounds correct and complete as well; my proverbial
hat is off to you for having compiled this comprehensive piece of
documentation.
-Matt
Stefan
-
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: ant-problem after upgrading from junit 4.4 to junit 4.6
It is very very unlikely that cobertura is the problem Most likely the use'r code was compiled against one version of junit and tested with a different version. Peter On Thu, May 14, 2009 at 10:31 AM, Stefan Bodewig bode...@apache.org wrote: Hi Matthias, On 2009-05-14, Walter, Matthias m.wal...@citti.de wrote: Hello there, I'm not quite sure if this is the correct mailing list for my problem, please forgive me, if not. I have a problem after upgrading junit from 4.4 to 4.6 on a Hudson Server. I get the error message: [junit] Running org.path.to.my.test.class.SqliteBackupManagerTest [junit] Testsuite: org.path.to.my.test.class.SqliteBackupManagerTest /some/path/to/my/build.xml:188: java.lang.NoClassDefFoundError: org/junit/Assume$AssumptionViolatedException could you provide the full stacktrace (running ant in verbose mode, if necessary)? I've grepped through Ant's sources and can't find any reference to AssumptionViolatedException or he Assume class in Ant's trunk or Ant 1.7.1. It may be some other library/tool that you are using during your test. Cobertura is a likely candidate. Stefan - 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: antlib namespace and uri usage
This is in the ant manual.
http://ant.apache.org/manual/CoreTypes/antlib.html#currentnamespace
There is a special xml namespace (ant:current) for typedefs defined
within an antlib.
The namespace is only active during the processing of the antlib.
Peter
On Thu, Apr 23, 2009 at 7:53 AM, Gilles Scokart gscok...@gmail.com wrote:
Yesterday I lost 1 hour to fix an antlib namespace issue. I have no found
how to fix it, but I still don't clearly understand what is actually wrong
(=what error message should ant report).
I have an antlib defined in an XML file like this :
antlib xmlns:deco=antlib:net.sourceforge.deco.ant
taskdef name=analyze
classname=net.sourceforge.deco.ant.Analyze
/
/antlib
And I have my project was using it like this :
project name=build_base xmlns:deco=net.sourceforge.deco.ant
typedef resource=net/sourceforge/deco/ant/antlib.xml
uri=net.sourceforge.deco.ant
classpath
fileset dir=${build.script.dir}/lib/
include name=deco*.jar/
/fileset
pathelement
location=${build.script.dir}/lib/asm-3.1.jar /
/classpath
/typedef
/project
This was working fine, and I could use deco:analyse task in my build.
But then I added a presetdef in my anlib that refined analyze like this
(simplified version):
antlib xmlns:deco=antlib:net.sourceforge.deco.ant
taskdef name=analyze
classname=net.sourceforge.deco.ant.Analyze
/
presetdef name=check-compile
deco:analyze type=COMPILE
deco:check-compile-report/
/deco:analyze
/presetdef
/antlib
This was failing because deco:analyze was not found when presetdef
executed.
I tried unsuccesfully to change the usage of the namespace in different way,
then I plugged a debugger and I found that the analyze task did exist, but
with the name net.sourceforge.deco.ant:analyze while
antlib:net.sourceforge.deco.ant:analyze was searched.
The fix was to change the uri used in my build from net.sourceforge.deco.ant
to antlib:net.sourceforge.deco.ant.
But what is exactly wrong?
Was my initial declaration wrong? Should it be mandatory to use exactly the
same URI in the typedef loading the antlib than in the antlib declaration
For the moment it is not mandatory, If you don't do, you may not notice that
you don't do. But you might have the issue I had. In that case, we should
at least have a warning (failing would break backward compatibility).
Or are was it the intention to let the user of an antlib freely choose its
uri? I doubt. But if it is, how can I reference my own tasks into the
antlib.xml file ?
Gilles Scokart
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Giving the improved bzip2 code a second chance?
On Fri, Mar 27, 2009 at 8:26 AM, Kevin Jackson foamd...@gmail.com wrote: Hi, with Ant 1.7.0 we changed the bzip2 code to make it a lot faster and reverted the change in 1.7.1 because it was creating corrupt archives. Meanwhile the Hadoop folks have been using the 1.7.0 code and claim they have found and fixed the problem (a single + 1 missing somewhere IIUC). I think we have a unit test that failed with the 1.7.0 code and passes with 1.7.1 - should we give the Hadoop fixed code a second chance if it passes all our tests? If it passes our tests (and Peter's extended test), why should we not use it? +1 from me +1 from me. Peter Kev - 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: Giving the improved bzip2 code a second chance?
Excellent. My tests have shown no problems. Peter On Fri, Mar 27, 2009 at 1:53 PM, Stefan Bodewig bode...@apache.org wrote: committed as revision 759138 Stefan - 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: Giving the improved bzip2 code a second chance?
I am testing this patch at the moment.
I am running the bz2 compress with the new code, uncompessing
using the command line bunzip and comparing the
files.
The test is over ~100, 000 files, and I have had to
use the computer for other things - so the test
is not yet complete.
project name=testbz default=t
xmlns:ac=antlib:net.sf.antcontrib
import file=src/ant/simple.xml/
property name=space location=/media/disk/preilly/space/
property name=checkstatus value=if [ ! $? == 0 ] ; then exit 1; fi/
macrodef name=testbz
attribute name=file/
sequential
local name=bname/
local name=target/
basename file=@{file} property=bname/
property name=target location=${space}/${bname}/
delete quiet=yes file=${target}/
delete quiet=yes file=${target}.bz2/
bzip2 src=@{file} destfile=${target}.bz2/
ac:bash failonerror=true dir=${space}
bunzip2 '${bname}.bz2'
${checkstatus}
cmp '${bname}' '@{file}'
${checkstatus}
rm '${bname}'
true
/ac:bash
/sequential
/macrodef
target name=t
ac:for param=file
fileset dir=/media/disk excludes=preilly/**,**/*$*/
ac:sequential
testbz file=@{file}/
/ac:sequential
/ac:for
/target
/project
It looks good at the moment.
Peter
On Thu, Mar 26, 2009 at 1:20 PM, Stefan Bodewig bode...@apache.org wrote:
Hi all,
with Ant 1.7.0 we changed the bzip2 code to make it a lot faster and
reverted the change in 1.7.1 because it was creating corrupt archives.
Meanwhile the Hadoop folks have been using the 1.7.0 code and claim
they have found and fixed the problem (a single + 1 missing somewhere
IIUC).
I think we have a unit test that failed with the 1.7.0 code and passes
with 1.7.1 - should we give the Hadoop fixed code a second chance if
it passes all our tests?
Stefan
-
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: schema for junit xml output
The google-test people are going to to change the output from testsuitetestsuite*//testsuite to testsuitestestsuite*//testsuites (with a command-line switch). They have some extra attributes, and do not populate some attributes and elements. but the output is understood by hudson without mod to hudson. Peter. On Wed, Mar 18, 2009 at 3:50 PM, Jesse Glick jesse.gl...@sun.com wrote: Peter Reilly wrote: a question that has been asked a number of times on the hudson mailing list is what is the schema of the xml that junit generates. BTW: https://hudson.dev.java.net/nonav/issues/show_bug.cgi?id=3007 - 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
schema for junit xml output
a question that has been asked a number of times on the hudson mailing
list is what
is the schema of tthe xml that junit generates.
I have had a quick look at the code, and noticed that there two related schemas.
1) the xml that junit generates
and
2) the xml that junitreport uses internally.
Both these formats are used as input to other reporting tools -
including hudson.
(I assume that maven has a similar junit xml report format)
The xml that junit generates has a toplevel element of testsuite and nested
properties, testcase, system-out and system-err elements.
The xml that junitreport uses internally has a toploevel element of
testsuites and nested
testsuite elements. The content of these testsuite elements are the same as
the testsuite from the task junit *except* that it has two extra
attributes - id and package..
In any case, here is a first attempt at a schema for junit (in relaxng
compact syntax)
junit.rnc:
#--
start = testsuite
property = element property {
attribute name {text},
attribute value {text}
}
properties = element properties {
property*
}
failure = element failure {
attribute message {text},
attribute type {text},
text
}
testcase = element testcase {
attribute classname {text},
attribute name {text},
attribute time {text},
failure?
}
testsuite = element testsuite {
attribute errors {xsd:integer},
attribute failures {xsd:integer},
attribute hostname {text},
attribute name {text},
attribute tests {xsd:integer},
attribute time {xsd:double},
attribute timestamp {xsd:dateTime},
properties,
testcase*,
element system-out {text},
element system-err {text}
}
#--
and junitreport.rnc
#--
include junit.rnc {
start = testsuites
testsuite = element testsuite {
attribute errors {xsd:integer},
attribute failures {xsd:integer},
attribute hostname {text},
attribute name {text},
attribute tests {xsd:integer},
attribute time {xsd:double},
attribute timestamp {xsd:dateTime},
attribute id {text},
attribute package {text},
properties,
testcase*,
element system-out {text},
element system-err {text}
}
}
testsuites = element testsuites {
testsuite*
}
#--
Peter
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java
Perhaps we should check the target attribute - but this is very much an edge case. Peter On Wed, Feb 18, 2009 at 4:32 PM, Stefan Bodewig bode...@apache.org wrote: On 2009-02-18, Jesse Glick jesse.gl...@sun.com wrote: Stefan Bodewig wrote: this should be the equivalent of compiling a package-info.java containing only SOURCE annotations using JDK 5. Do you know whether a Java 1.4 VM will even try to load the class file under any circumstances (other than some explicit reflection invocations)? You cannot use package-info.java with JDK 1.4 to begin with. I know that. I was wondering whether there might be a situation where JDK 1.4 would try to load the class file even though it shouldn't. Stefan - 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: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java
The version is 1.5 - and it is not meant to be replaced!
Peter
On Fri, Feb 13, 2009 at 3:04 PM, Dominique Devienne ddevie...@gmail.com wrote:
On Thu, Feb 12, 2009 at 4:35 PM, jgl...@apache.org wrote:
+private static final byte[] PACKAGE_INFO_CLASS_HEADER = {
+(byte) 0xca, (byte) 0xfe, (byte) 0xba, (byte) 0xbe, 0x00, 0x00,
0x00,
+0x31, 0x00, 0x07, 0x07, 0x00, 0x05, 0x07, 0x00, 0x06, 0x01, 0x00,
0x0a,
+0x53, 0x6f, 0x75, 0x72, 0x63, 0x65, 0x46, 0x69, 0x6c, 0x65, 0x01,
0x00,
+0x11, 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x2d, 0x69, 0x6e,
0x66,
+0x6f, 0x2e, 0x6a, 0x61, 0x76, 0x61, 0x01
+};
+private static final byte[] PACKAGE_INFO_CLASS_FOOTER = {
+0x2f, 0x70, 0x61, 0x63, 0x6b, 0x61, 0x67, 0x65, 0x2d, 0x69, 0x6e,
0x66,
+0x6f, 0x01, 0x00, 0x10, 0x6a, 0x61, 0x76, 0x61, 0x2f, 0x6c, 0x61,
0x6e,
+0x67, 0x2f, 0x4f, 0x62, 0x6a, 0x65, 0x63, 0x74, 0x02, 0x00, 0x00,
0x01,
+0x00, 0x02, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00,
0x03,
+0x00, 0x00, 0x00, 0x02, 0x00, 0x04
+};
What Java version is this fake class in?
I suppose it doesn't matter much, as it's meant to be replaced, right?
Just curuous. --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
Re: svn commit: r743910 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javac.java
Neat,
that is a a brilliant solution!
Peter
On Thu, Feb 12, 2009 at 10:35 PM, jgl...@apache.org wrote:
Author: jglick
Date: Thu Feb 12 22:35:18 2009
New Revision: 743910
URL: http://svn.apache.org/viewvc?rev=743910view=rev
Log:
#43114: ensuring that package-info.class is created/touched when
package-info.java is compiled.
Modified:
ant/core/trunk/WHATSNEW
ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Javac.java
Modified: ant/core/trunk/WHATSNEW
URL:
http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?rev=743910r1=743909r2=743910view=diff
==
--- ant/core/trunk/WHATSNEW (original)
+++ ant/core/trunk/WHATSNEW Thu Feb 12 22:35:18 2009
@@ -137,6 +137,9 @@
Fixed bugs:
---
+
+ * Better handling of package-info.class. Bugzilla Report 43114.
+
* RPM task needed an inserted space between the define and the value.
bugzilla Report 46659.
Modified: ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Javac.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Javac.java?rev=743910r1=743909r2=743910view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Javac.java
(original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/Javac.java Thu Feb
12 22:35:18 2009
@@ -19,10 +19,12 @@
package org.apache.tools.ant.taskdefs;
import java.io.File;
-
-import java.util.ArrayList;
+import java.io.FileOutputStream;
+import java.io.IOException;
+import java.io.OutputStream;
+import java.util.HashMap;
import java.util.Iterator;
-import java.util.List;
+import java.util.Map;
import org.apache.tools.ant.BuildException;
import org.apache.tools.ant.DirectoryScanner;
@@ -87,9 +89,6 @@
private static final String CLASSIC = classic;
private static final String EXTJAVAC = extJavac;
-private static final String PACKAGE_INFO_JAVA = package-info.java;
-private static final String PACKAGE_INFO_CLASS = package-info.class;
-
private static final FileUtils FILE_UTILS = FileUtils.getFileUtils();
private Path src;
@@ -118,6 +117,7 @@
protected boolean failOnError = true;
protected boolean listFiles = false;
protected File[] compileList = new File[0];
+private Map/*String,Long*/ packageInfos = new HashMap();
// CheckStyle:VisibilityModifier ON
private String source;
@@ -127,7 +127,6 @@
private String errorProperty;
private boolean taskSuccess = true; // assume the best
private boolean includeDestClasses = true;
-private ListupdateDirList = new ArrayList();
/**
* Javac task for compilation of Java files.
@@ -898,6 +897,7 @@
*/
protected void resetFileLists() {
compileList = new File[0];
+packageInfos = new HashMap();
}
/**
@@ -915,8 +915,8 @@
SourceFileScanner sfs = new SourceFileScanner(this);
File[] newFiles = sfs.restrictAsFiles(files, srcDir, destDir, m);
-newFiles = removePackageInfoFiles(newFiles, srcDir, destDir);
if (newFiles.length 0) {
+lookForPackageInfos(srcDir, newFiles);
File[] newCompileList
= new File[compileList.length + newFiles.length];
System.arraycopy(compileList, 0, newCompileList, 0,
@@ -1069,10 +1069,12 @@
// finally, lets execute the compiler!!
if (adapter.execute()) {
-// Success - check
-for (Iterator i = updateDirList.iterator(); i.hasNext();) {
-File file = (File) i.next();
-file.setLastModified(System.currentTimeMillis());
+// Success
+try {
+generateMissingPackageInfoClasses();
+} catch (IOException x) {
+// Should this be made a nonfatal warning?
+throw new BuildException(x, getLocation());
}
} else {
// Fail path
@@ -1106,71 +1108,68 @@
}
}
-//
-// Code to remove package-info.java files from compilation
-// Since Ant 1.7.1.
-//
-//package-info.java are files that contain package level
-//annotations. They may or may not have corresponding .class
-//files.
-//
-//The following code uses the algorithm:
-// * on entry we have the files that need to be compiled
-// * if the filename is not package-info.java compile it
-// * if a corresponding .class file exists compile it
-// * if the corresponding class directory does not exist compile it
-// * if the corresponding directory lastmodifed time is
-// older than the java file,
Re: svn commit: r741089 - in /ant/core/trunk/src: main/org/apache/tools/bzip2/ main/org/apache/tools/tar/ main/org/apache/tools/zip/ tests/junit/org/apache/tools/zip/
some of the findbugs issues are a little too severe.
Do we really need to copy the arrays??
Peter
On Thu, Feb 5, 2009 at 12:30 PM, bode...@apache.org wrote:
Author: bodewig
Date: Thu Feb 5 12:30:01 2009
New Revision: 741089
URL: http://svn.apache.org/viewvc?rev=741089view=rev
Log:
fix a bunch of findbugs reported problems in the zip, tar and bzip2 classes.
PR 46661
Modified:
ant/core/trunk/src/main/org/apache/tools/bzip2/CBZip2OutputStream.java
ant/core/trunk/src/main/org/apache/tools/tar/TarInputStream.java
ant/core/trunk/src/main/org/apache/tools/tar/TarOutputStream.java
ant/core/trunk/src/main/org/apache/tools/zip/AsiExtraField.java
ant/core/trunk/src/main/org/apache/tools/zip/UnrecognizedExtraField.java
ant/core/trunk/src/main/org/apache/tools/zip/ZipFile.java
ant/core/trunk/src/main/org/apache/tools/zip/ZipLong.java
ant/core/trunk/src/main/org/apache/tools/zip/ZipShort.java
ant/core/trunk/src/tests/junit/org/apache/tools/zip/AsiExtraFieldTest.java
ant/core/trunk/src/tests/junit/org/apache/tools/zip/ZipLongTest.java
ant/core/trunk/src/tests/junit/org/apache/tools/zip/ZipShortTest.java
Modified:
ant/core/trunk/src/main/org/apache/tools/bzip2/CBZip2OutputStream.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/bzip2/CBZip2OutputStream.java?rev=741089r1=741088r2=741089view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/bzip2/CBZip2OutputStream.java
(original)
+++ ant/core/trunk/src/main/org/apache/tools/bzip2/CBZip2OutputStream.java
Thu Feb 5 12:30:01 2009
@@ -613,7 +613,7 @@
}
if (ge gs nPart != nGroups nPart != 1
- ((nGroups - nPart) % 2 == 1)) {
+ ((nGroups - nPart) % 2 != 0)) {
aFreq -= mtfFreq[ge];
ge--;
}
@@ -983,9 +983,7 @@
b = t;
}
if (b c) {
-t = b;
b = c;
-c = t;
}
if (a b) {
b = a;
@@ -1030,7 +1028,7 @@
med = med3(block[zptr[lo] + d + 1],
block[zptr[hi] + d + 1],
- block[zptr[(lo + hi) 1] + d + 1]);
+ block[zptr[(lo + hi) 1] + d + 1]);
unLo = ltLo = lo;
unHi = gtHi = hi;
Modified: ant/core/trunk/src/main/org/apache/tools/tar/TarInputStream.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/tar/TarInputStream.java?rev=741089r1=741088r2=741089view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/tar/TarInputStream.java
(original)
+++ ant/core/trunk/src/main/org/apache/tools/tar/TarInputStream.java Thu Feb
5 12:30:01 2009
@@ -218,8 +218,13 @@
+ numToSkip + bytes);
}
-if (numToSkip 0) {
-skip(numToSkip);
+while (numToSkip 0) {
+long skipped = skip(numToSkip);
+if (skipped = 0) {
+throw new RuntimeException(failed to skip current tar
+ + entry);
+}
+numToSkip -= skipped;
}
readBuf = null;
Modified: ant/core/trunk/src/main/org/apache/tools/tar/TarOutputStream.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/tar/TarOutputStream.java?rev=741089r1=741088r2=741089view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/tar/TarOutputStream.java
(original)
+++ ant/core/trunk/src/main/org/apache/tools/tar/TarOutputStream.java Thu Feb
5 12:30:01 2009
@@ -310,7 +310,7 @@
wOffset += numToWrite;
assemLen += numToWrite;
-numToWrite -= numToWrite;
+numToWrite = 0;
}
}
Modified: ant/core/trunk/src/main/org/apache/tools/zip/AsiExtraField.java
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/zip/AsiExtraField.java?rev=741089r1=741088r2=741089view=diff
==
--- ant/core/trunk/src/main/org/apache/tools/zip/AsiExtraField.java (original)
+++ ant/core/trunk/src/main/org/apache/tools/zip/AsiExtraField.java Thu Feb
5 12:30:01 2009
@@ -334,4 +334,14 @@
return type | (mode PERM_MASK);
}
+public Object clone() {
+try {
+AsiExtraField cloned = (AsiExtraField) super.clone();
+cloned.crc = new CRC32();
+return cloned;
+} catch (CloneNotSupportedException cnfe) {
+// impossible
+throw new
Re: which xml parse package that ant use?
Also sax is stream based - so the first errors that ant would see would be the fact that the first element is not project the malformed xml document would not be noticed at this stage as processing of the document would stop. Peter On Mon, Nov 17, 2008 at 3:46 PM, Stefan Bodewig [EMAIL PROTECTED] wrote: Ant uses a SAX parser, not a DocumentBuilder (see javax.xml.parsers,SAXParser), this alone may explain the difference. It will use whatever JAXP provides, but Ant ships with a pretty recent version of Apache Xerces. Finally, the error message you cite comes from Ant, not the parser. If the documents wasn't at least well-formed, Ant wouldn't get a chance to say which element was different from the one it expected. Stefan - 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]
Re: YUI Compressor Antlib
Fire away, this is what the sandbox is for. Peter On Fri, Oct 17, 2008 at 7:03 PM, Kevin Jackson [EMAIL PROTECTED] wrote: Hi, At work we have a need for this, so I've thrown it together just now (very rough, but it does what it says on the tin). It's using the Yahoo JavaScript and CSS compressor library and the code is licensed under BSD. My company is ok with me donating the antlib to apache, can I put this into the antlib sandbox? My idea is to extend it and add other compressors (Dean Edwards is supposed to be the best, but there's also Dojo SafeShrink). Any objections to this being committed? The other option would be to donate it back to the Yahoo team to add to their package, but they don't seem to have any source control setup for YUI that I can find. Thanks, Kev - 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]
Re: [VOTE] Release AntUnit 1.1
+1 Peter On Fri, Sep 19, 2008 at 10:41 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Hi all, since no new issues have been found with the beta that has been out for three weeks, I've created archives from the same code base and uploaded them to http://people.apache.org/~bodewig/antunit11/ I propose to adopt them as the AntUnit 1.1 release, please cast you votes, this vote will be open for a week. Stefan - 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]
Re: DirectoryScanner and Symlinks
Is it not costly (as in very costly) to get the canonical path ? I would be for the lowest tech possible here. Peter On Thu, Sep 4, 2008 at 4:38 PM, Dominique Devienne [EMAIL PROTECTED] wrote: On Thu, Sep 4, 2008 at 7:32 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: as Issue 45499 shows DirectoryScanner can run into infinite loops by symbolic links that point to parent directories of the scanned directory. Instead of trying to track traversed directories using a stack or set, what about a low-tech max-symlink-hops check (and fileset attribute), defaulting to say 5, to break out of the infinite loop? --DD - 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]
Re: svn commit: r688729 - /ant/core/trunk/src/main/org/apache/tools/ant/ComponentHelper.java
yikes! Peter On Mon, Aug 25, 2008 at 3:04 PM, [EMAIL PROTECTED] wrote: Author: bodewig Date: Mon Aug 25 07:04:01 2008 New Revision: 688729 URL: http://svn.apache.org/viewvc?rev=688729view=rev Log: reallyput the value into the map. Modified: ant/core/trunk/src/main/org/apache/tools/ant/ComponentHelper.java Modified: ant/core/trunk/src/main/org/apache/tools/ant/ComponentHelper.java URL: http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/ComponentHelper.java?rev=688729r1=688728r2=688729view=diff == --- ant/core/trunk/src/main/org/apache/tools/ant/ComponentHelper.java (original) +++ ant/core/trunk/src/main/org/apache/tools/ant/ComponentHelper.java Mon Aug 25 07:04:01 2008 @@ -214,7 +214,7 @@ entryVal = new ArrayList(entryVal); } Object entryKey = entry.getKey(); -result.put(entryKey, entryKey); +result.put(entryKey, entryVal); } } return result; - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release AntUnit 1.1 Beta 1
+1 Peter On Wed, Aug 27, 2008 at 7:44 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 just in case your mail client doesn't like the way our mailing list manager deals with multipart/signed messages (just like mine, it simply doesn't see the signed part, only the signature), here is what I wrote: Hi all, I've uploaded distribution files for AntUnit 1.1 Beta1 to http://people.apache.org/~bodewig/antunit11_beta1/. Please check them and vote whether they should be released. The vote runs for a week and needs 3 PMC member +1s to pass (and more +1s than -1s). Stefan and I forgot to add my own +1. Off to signing the emacs region instead of the message ... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFItPemohFa4V9ri3IRAlDBAJ9dQA0cCnR3ZJtd2kP4BIJzUZr12wCg2/gL Rfnilxluo/2NfzaH4ItjJGc= =0sg/ -END PGP SIGNATURE- - 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]
Re: AntUnit 1.1?
sounds good (am catching up on my e-mail queue). Peter On Tue, Jul 15, 2008 at 1:58 PM, Kevin Jackson [EMAIL PROTECTED] wrote: ant's trunk has been using a snapshot of AntUnit's trunk for quite some time now, so we seem to need some unreleased feature. How about making it available to others as well? Sounds reasonable. Kev - 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]
Re: Locking in Project and PropertyHelper
On Tue, Jun 17, 2008 at 1:57 PM, Stefan Bodewig [EMAIL PROTECTED] wrote:
On Tue, 17 Jun 2008, Stefan Bodewig [EMAIL PROTECTED] wrote:
I suggest the following changes:
* lock the listener collection in the add/remove listener methods,
in fireMessageLogged lock the listeners, clone them, give up the
lock, work on the clone
alternatively copy listeners on change in the add/remove cases since
we are probably writing far more log messages than we add or remove
listeners. Same would apply to the delegates in PropertyHelper.
We currently do copy the listeners.
public synchronized void addBuildListener(BuildListener listener) {
Vector newListeners = getBuildListeners();
newListeners.addElement(listener);
listeners = newListeners;
Simply removing the lock on the project object would
not help as multiple threads could call the add/remove method at the same time.
We would need something like jdk5's CopyOnWriteArrayListE to do this
correctly.
Peter
Stefan
-
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]
Re: 1.7.7 DOMUtilTest fixed
On Mon, Jun 9, 2008 at 3:58 AM, Kevin Jackson [EMAIL PROTECTED] wrote: Hi, I finally got the time to work out what was wrong with the DOMUtilTest failure I should have some time to look into the other failures for 1.7.1 - but this was the only new failure since the last beta release I would like to start the process for the full release since the beta has been available for some time now. Thoughts? Go for it. Peter Kev - 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]
Re: [g...@vmgump]: Project test-ant-no-xerces (in module ant) failed
This is due to: [au:antunit] Build File: /srv/gump/public/workspace/ant/src/tests/antunit/types/scriptcondition-test.xml [au:antunit] Tests run: 16, Failures: 0, Errors: 14, Time elapsed: 0.316 sec [au:antunit] Target: testBeanshellReturnTrue caused an ERROR [au:antunit]at line 100, column 42 [au:antunit]Message: The following error occurred while executing this line: [au:antunit] /srv/gump/public/workspace/ant/src/tests/antunit/types/scriptcondition-test.xml:25: Unable to load a script engine manager (org.apache.bsf.BSFManager or javax.script.ScriptEngineManager) [au:antunit]took 0.013 sec [au:antunit] Target: testNolanguage took 0.006 sec [au:antunit] Target: testBeanshellReturnFalse caused an ERROR [au:antunit]at line 108, column 43 [au:antunit]Message: The following error occurred while executing this line: [au:antunit] /srv/gump/public/workspace/ant/src/tests/antunit/types/scriptcondition-test.xml:35: Unable to load a script engine manager (org.apache.bsf.BSFManager or javax.script.ScriptEngineManager) [au:antunit]took 0.01 sec On Fri, Apr 25, 2008 at 3:32 PM, Gump Integration Build [EMAIL PROTECTED] wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project test-ant-no-xerces has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 25 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - test-ant-no-xerces : Java based build tool Full details are available at: http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Optional dependency jakarta-tomcat-4.0 prerequisite failed with reason build failed -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/ant/test-ant-no-xerces/gump_work/build_ant_test-ant-no-xerces.html Work Name: build_ant_test-ant-no-xerces (Type: Build) Work ended in a state of : Failed Elapsed: 11 mins 44 secs Command Line: /usr/lib/jvm/java-1.5.0-sun/bin/java -Djava.awt.headless=true org.apache.tools.ant.Main -Dgump.merge=/srv/gump/public/gump/work/merge.xml -Dbuild.sysclasspath=only -Dtest.haltonfailure=false -Dant.home=/srv/gump/public/workspace/ant/dist run-tests [Working Directory: /srv/gump/public/workspace/ant] CLASSPATH: /usr/lib/jvm/java-1.5.0-sun/lib/tools.jar:/srv/gump/public/workspace/ant/build/testcases:/srv/gump/public/workspace/ant/src/tests/junit:/srv/gump/public/workspace/ant/src/etc/testcases:/srv/gump/public/workspace/ant/src/etc/testcases/taskdefs/optional/out:/srv/gump/public/workspace/ant/build/lib/ant-stylebook.jar:/srv/gump/public/workspace/ant/build/lib/ant-jmf.jar:/srv/gump/public/workspace/ant/build/lib/ant-swing.jar:/srv/gump/public/workspace/ant/build/lib/ant-junit.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-resolver.jar:/srv/gump/public/workspace/ant/build/lib/ant-javamail.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bcel.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-regexp.jar:/srv/gump/public/workspace/ant/build/lib/ant-trax.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-net.jar:/srv/gump/public/workspace/ant/build/lib/ant-jsch.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-log4j.jar:/srv/gump/public/wor ksp ace/ant/build/lib/ant-antlr.jar:/srv/gump/public/workspace/ant/build/lib/ant-commons-logging.jar:/srv/gump/public/workspace/ant/build/lib/ant-jdepend.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-bsf.jar:/srv/gump/public/workspace/ant/build/lib/ant-launcher.jar:/srv/gump/public/workspace/ant/build/lib/ant-nodeps.jar:/srv/gump/public/workspace/ant/build/lib/ant-apache-oro.jar:/srv/gump/public/workspace/ant/build/lib/ant.jar:/srv/gump/public/workspace/ant/build/lib/ant-jai.jar:/srv/gump/packages/antlr-2.7.6/antlr.jar:commons-logging-gump-23042008.jar:commons-logging-api-gump-23042008.jar:/srv/gump/public/workspace/apache-commons/net/dist/commons-net-25042008.jar:/srv/gump/packages/jaf-1.1ea/activation.jar:/srv/gump/public/workspace/jakarta-bcel/target/bcel-5.3-SNAPSHOT.jar:bsf-gump-23042008.jar:/srv/gump/public/workspace/logging-log4j-12/dist/lib/log4j-25042008.jar:/srv/gump/public/workspace/jakarta-oro/jakarta-oro-25042008.jar:/srv/gump/public/workspace/jakarta-r ege
Re: [g...@vmgump]: Project test-ant (in module ant) failed
I have seen this once or twice, but have no idea why it happens. Peter On Tue, Apr 8, 2008 at 8:14 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: That's ExecTaskTest failing and I have no idea why. Some kind of race condition that might get LeadPipeInputstream get closed before it should? Stefan - 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]
Re: test-ant is fixed in Gump
Thanks Peter On Mon, Apr 7, 2008 at 11:29 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Hi, for those who haven't noticed: Since I disabled execution of the FailureRecorder test when running JUnit4 test-ant now passes in Gump. This means every nag mail generated for test-ant hints at a newly introduced problem. Stefan - 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]
Re: Fixing some naming inconsistencies in Ivy
ant attribute names are case insensitive. I do not like long attribute names - although I have created a fair few my self. Peter On Sun, Mar 30, 2008 at 4:59 PM, Xavier Hanin [EMAIL PROTECTED] wrote: On Sat, Mar 29, 2008 at 9:55 PM, Stephane Bailliez [EMAIL PROTECTED] wrote: Xavier Hanin wrote: Just pinging about this e-mail, I've had no answer so far, I think I can't make the choice alone, and we need to deal with that question before 2.0final to close IVY-297. So, anyone has an opinion about this: On Fri, Feb 29, 2008 at 12:31 PM, Xavier Hanin [EMAIL PROTECTED] wrote: Hi, As reported by IVY-297, Ivy suffers from some name inconsistencies and strange attribute names. Ivy 2.0 is a good opportunity to fix some of them, since I think we can afford some more deprecation warnings. So I'd like to fix IVY-297 by marking allownomd as deprecated, and providing a descriptor=required | optional attribute. To go further, we could rename the attribute skipbuildwithoutivy in buildlist in skipbuildwithoutdescriptor, or even better change it to buildwithoutdescriptor=skip | fail | warn | tail | head, which wold make it both more readable and more powerful. s/buildwithoutdescriptor/missing-descriptor ? onMissingDescriptor ? I like onMissingDescriptor. imnotgenerallyabigfanofwordsgluedtogetherwithoutseparator when it it's more then 2 words (onchange, on..) I'm not either, I think at the beginning I thought it was more in the spirit of Ant (where you have some examples like failonerror, preservelastmodified, ... Now we have some inconsistancies, using camel case in some cases, dash separator in others, nothing elsewhere. I don't really like those inconsistencies, but I'm not in favour of fixing them all for 2.0 (mainly for a question of delay). OtherwiseThereIsCamelCaseButThisIsUglyTooForXml Another area where the name 'ivy' is used to talk about module descriptors in general is patterns. This lead to some strange settings, where you give an 'ivy' pattern to tell where the poms are. In this case I think we could support both 'ivy' and 'descriptor' (for resolver patterns for instance), since the use case for ivy files is still predominant, so I don't think deprecating the old name would really be better. So, what do you think about these changes? I guess if you want to make it it's probably 2.0 or never... there's already a lot of deprecated right now and it will get more difficult to push them in later. After all it's a 2.0 Agreed. Xavier -- stephane - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Can I Test the NPE Bug?
As far as I am aware, there is currently no nightly build.
The easiest way to get a version is to check out the ant trunk and compile
it yourself.
- use java5 to have the same compiler as the ant release
[EMAIL PROTECTED] ~]$ echo $JAVA_HOME
/usr/java/jdk5
[EMAIL PROTECTED] ~]$ mkdir y
[EMAIL PROTECTED] ~]$ cd y
[EMAIL PROTECTED] y]$ svn co
http://svn.apache.org/repos/asf/ant/core/trunk ant-trunk
.
[EMAIL PROTECTED] y]$ cd ant-trunk
ant -f fetch.xml -Ddest=optional (to get the optional jars - currently
does not work to network problem)
(in which case, place optional jars in ${basedir}/lib/optional by hand
- bsf.jar, etc)
rm -rf bootstrap# Just in case this contains old classes from a
previous build
./build.sh # This will make an distributable in ${basedir}/dist
export ANT_HOME=~/y/ant-trunk/dist
and check..
Peter
On Thu, Mar 27, 2008 at 5:19 PM, Robert Buck [EMAIL PROTECTED] wrote:
Peter,
I submitted the report, where can I get a copy of the updated jar so I
can test against IVY 2.0 Beta2?
Bob
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
+1 from me. Peter On Fri, Mar 28, 2008 at 11:18 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 12:11 PM, Steve Loughran [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Author: peterreilly Date: Thu Mar 27 10:09:53 2008 New Revision: 641903 URL: http://svn.apache.org/viewvc?rev=641903view=rev Log: Bugzilla 44689: NPE with multiple targets and id's in task IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. +1. We could always do a quick beta 3 release with this change to see that people are happy. +1 too Xavier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r640878 - in /ant/ivy/core/trunk: CHANGES.txt RELEASE_NOTES
Text files do not specify an encoding. It this utf-8 or win1252 or latin1 ? Peter On Tue, Mar 25, 2008 at 4:11 PM, [EMAIL PROTECTED] wrote: Author: hibou Date: Tue Mar 25 09:11:41 2008 New Revision: 640878 URL: http://svn.apache.org/viewvc?rev=640878view=rev Log: Encoding fix Modified: ant/ivy/core/trunk/CHANGES.txt ant/ivy/core/trunk/RELEASE_NOTES Modified: ant/ivy/core/trunk/CHANGES.txt URL: http://svn.apache.org/viewvc/ant/ivy/core/trunk/CHANGES.txt?rev=640878r1=640877r2=640878view=diff == --- ant/ivy/core/trunk/CHANGES.txt (original) +++ ant/ivy/core/trunk/CHANGES.txt Tue Mar 25 09:11:41 2008 @@ -8,7 +8,7 @@ Committers Maarten Coene Xavier Hanin - Nicolas LalevÃ(c)e + Nicolas Lalevée Gilles Scokart Contributors Modified: ant/ivy/core/trunk/RELEASE_NOTES URL: http://svn.apache.org/viewvc/ant/ivy/core/trunk/RELEASE_NOTES?rev=640878r1=640877r2=640878view=diff == --- ant/ivy/core/trunk/RELEASE_NOTES (original) +++ ant/ivy/core/trunk/RELEASE_NOTES Tue Mar 25 09:11:41 2008 @@ -154,7 +154,7 @@ Committers Maarten Coene Xavier Hanin - Nicolas LalevÃ(c)e + Nicolas Lalevée Gilles Scokart Contributors - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Should ScriptRunner call terminate() on the BSFManager?
On Tue, Mar 25, 2008 at 8:59 PM, Paul King [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Hi, We've recently integrated Jepp (http://jepp.sourceforge.net/) into our use of Ant via the BSF engine. This is very useful because we use Python for scripting quite a lot and it allows Python code to be used in full while also allowing access to Java objects. This has resulted in a Java OOM error, which I suspect is due to this integration change. There is a comment in the Jepp usage instructions that close() must be called on the Jep objects. This is done inside the terminate() method of the BSFJepEngine, which is called by the BSFManager on all engines. However I cannot see anywhere where BSFManager.terminate() is called inside ScriptRunner or elsewhere inside Ant. Should terminate() be called by ScriptRunner(), perhaps in the finally section in the executeScript method? Just had a quick look, we should call the terminate method - it is part of the life cycle that we missed. Looking at some of the languages: beanshell does not use the terminate method jruby does rhino does not groovy does not jython does not netrexx does not jacl does not so it is not surprising that we missed this. The odd thing is that javax.scripting does not seem to have a corresponding method and the jruby javax.script engine calls the terminate for each invoke method. Others will be more familiar with the ScriptRunnerXXX classes than me but in WebTest, its Script task has a keep flag. This might be a useful concept to have here. Basically the flag allows you to distinguish between scenarios where you want the binding retained across tasks (and hence in the scenario above I suspect you don't want terminate() called) and the case where you want a fresh manager/runner for each run. Again, I haven't done a complete analysis of what gets called where in Ant at the moment. Just noting an important use case for WebTest which I know is in use in the field in many places. It should be possible to modify the scripting code in such a way that will not affect people that use the code. Peter Paul. P.S. For those that aren't aware, WebTest is an Ant extension for testing web applications. - 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]
Re: [Vote] 1.7.1beta2
On Sun, Mar 23, 2008 at 11:17 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Sat, 22 Mar 2008, Kevin Jackson [EMAIL PROTECTED] wrote: Available tarballs at http://people.apache.org/dist/ant/v1.7.1beta2/ are ready: yes [ x ] (+1) no [ ] (-1) +1 +1 Peter Stefan - 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]
Re: [EMAIL PROTECTED]: Project bootstrap-ant (in module ant) failed
Opps, sorry, I commited an jar that was compiled with javac5. Fixed now. Peter On Sat, Mar 22, 2008 at 7:39 AM, Gump Integration Build [EMAIL PROTECTED] wrote: To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at [EMAIL PROTECTED] Project bootstrap-ant has an issue affecting its community integration. This issue affects 477 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - JacORB : The free Java implementation of the OMG's CORBA standard. - JacORB-idllib : The free Java implementation of the OMG's CORBA standard. - addressing : WS-FX Project - anakia : Essentially an XML transformation tool, Anakia uses JDOM and... - annogen : Annogen is a framework which helps you work with JSR175 Anno... - ant : Java based build tool - ant-contrib : Useful little Ant tasks - ant-contrib-cpptasks : C/C++ compilation tasks for Ant - ant-contrib-cpptasks-test : JUnit tests for the C/C++ compilation tasks - ant-contrib-test : Useful little Ant tasks - ant-embed-optional : Java based build tool - ant-testutil : Java based build tool - ant-xdocs-proposal : Java based build tool - antbook-diary-core : Examples to go with Java Development with Ant - antbook-sections : Examples to go with Java Development with Ant - antunit : Task and Type Libraries for Apache Ant - antunit-test : Task and Type Libraries for Apache Ant - aopalliance : AOP Alliance (Java/J2EE AOP standards) - apache-ldapber-provider : Apache Directory Project - apacheds-core : Apache Directory Server - apacheds-main : Apache Directory Server - apacheds-shared : Apache Directory Server - apollo : Apollo Project - args4j : Java command line options parser - args4j-tests : Java command line options parser - args4j-tools : Java command line options parser - asm : A Java bytecode manipulation framework. - asn1-ber : Apache ASN.1 Tools - asn1-codec : Apache ASN.1 Tools - asn1-der : Apache ASN.1 Tools - authx-core : Apache Authentication and Authorization Framework - authx-example : Apache Authentication and Authorization Framework - authx-jdbc : Apache Authentication and Authorization Framework - authx-script : Apache Authentication and Authorization Framework - avalon-framework-api : Avalon SVN - avalon-framework-impl : Avalon SVN - avalon-logkit : Avalon SVN - avalon-meta-api : Avalon SVN - avalon-meta-impl : Avalon SVN - avalon-meta-spi : Avalon SVN - avalon-meta-tools : Avalon SVN - avalon-util-configuration : Avalon SVN - avalon-util-i18n : Avalon SVN - bcel : Byte Code Engineering Library - beaver : LALR(1) parser generator. - beepcore : BEEP is a new Internet standards-track protocol - bootstrap-ant : Java based build tool - bsh-cvs - camel : Camel :: Core - cargo : Cargo provides a Java API to manipulate Java Containers - castor : Java to XML, SQL, LDAP bindings - cddlm : Configuration and Deployment of Grid Applications and System... - checkstyle : Java style checker - commons-attributes : Commons Attributes - commons-beanutils : Bean Utilities - commons-betwixt : Commons Betwixt Package - commons-chain : GoF Chain of Responsibility pattern - commons-cli : Commons CLI Package - commons-cli2 : Commons CLI Package - commons-codec : Commons Encoding/Decoding Package - commons-collections : Collections - commons-collections-testframework : Apache Commons - commons-compress : Commons Compression Package - commons-configuration : Apache Commons - commons-daemon : Commons Daemon - commons-dbcp : Database Connection Pool - commons-digester : XML to Java Object Configuration - commons-digester-rss : Digester RSS Example - commons-discovery : Commons Discovery Package - commons-el : Expression Language - commons-email : Commons Email Package - commons-fileupload : Commons File Upload Package - commons-functor : Functor: Function Objects - commons-graph : Apache commons dormant - sandbox components which are inacti... - commons-http : Commons HTTP Utility Package - commons-httpclient : HTTP Client Library, version 3.1 - commons-httpclient-2.0-branch : HTTP Client Library, version 2.0 - commons-id : Commons Identifier Package - commons-io : Commons I/O Utility Package - commons-javaflow : Commons Javaflow - commons-jci : Commons JCI - commons-jelly : Commons Jelly - commons-jelly-tags-ant : Commons Jelly -
netrexx and image optional tasks
HI all, I have gone tru the optional ant tasks/types with a view to allow an complete automatic compilation of ant from svn and use of fetch.xml. In current ant trunk, only the netrxx and image optional tasks cannot be so built. netrexx: (http://www-306.ibm.com/software/awdtools/netrexx/download.html) has a click tru license. jai for the image task has a similar click tru licence (with different downloads for different os'es(http://java.sun.com/products/java-media/jai/downloads/download-1_1_2_01.html) I am uneasy about having the ant distribution depend on these jars and would like to vote on moving the optional jars to separate antlibs for ant 1.8.0 (in the same way as weblogic and starteam tasks are being moved (abeit slowly)). What do people think? Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DO NOT REPLY [Bug 34005] spellcheck results from ant.apache.org manual
Is is possible to revert these changes (unassinged - 1.8.0) Most of these bugs will not get fixed in ant 1.8.0 and setting the target release ensures that when ant 1.8.0 comes around, the bugs have to be updated again). (In general I do not like the custom of mass updates of the bug database when a release is being made - a lot of information can be lost. For example, there were a lot of found in 1.7..0betax that were updated to found in ant 1.7.0, and in fact the bug - although preseent in the beta was also present in ant 1.4.) Peter On Wed, Mar 19, 2008 at 2:23 AM, [EMAIL PROTECTED] wrote: https://issues.apache.org/bugzilla/show_bug.cgi?id=34005 Kev Jackson [EMAIL PROTECTED] changed: What|Removed |Added Target Milestone|--- |1.8.0 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant 1.7.1beta available
Hi Kev, I see that you have updated the beta (to 2). http://people.apache.org/~kevj/ant/ant-1.7.1beta2.tar.gz Peter On Mon, Mar 17, 2008 at 3:02 PM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Mon, 17 Mar 2008, Stefan Bodewig [EMAIL PROTECTED] wrote: I've started to make the 1.7 branch compliant to my interpretation and will also clean up a few files RAT complains about. I hope to be done by the time my lunch break is over 8-) Obviously I didn't manage that (finishing within the bounds of my lunchbreak, that is). The branch should be OK now. I'm just running svn merge of all my changes for trunk (which will be followed by running RAT on trunk, fixing remaining issues and re-generating the site, oh my). Stefan - 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]
Re: DO NOT REPLY [Bug 44630] Small error in doc (due to variable expansion?)
Yes, I have made a change to the build.xml file. It is up to kev to see if this should be in the ant 1.7.1 release. Peter On Tue, Mar 18, 2008 at 6:40 PM, Vladimir Mihai Pacuraru [EMAIL PROTECTED] wrote: [...] Good catch. This problem is in the docs directory of the tar.* (or zip) file of the release and not on the manual page in the web site or in the svn head or trunk. Just checked the current beta for ant 1.7.1 - beta 2 (http://people.apache.org/~kevj/ant/ant-1.7.1beta2.tar.gz) and the problem exists there as well.. - looks like an artifact of the ant release process. Is ANT used for that (i.e. for the build process? :) Vlad Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ant 1.7.1 beta
On Wed, Mar 12, 2008 at 5:09 PM, Stefan Bodewig [EMAIL PROTECTED] wrote: On Wed, 12 Mar 2008, Kevin Jackson [EMAIL PROTECTED] wrote: I think it's time to go ahead and push out 1.7.1 for wider testing. good. Over to the vote: That's not how this works. You create the tasballs (and zips) and we vote on them. Yep, we need the tarballs. Peter Despite the strange bug Steve uncovered for networked drives on Windows, Ant 1.7.1 is ready for beta: Yes, I'll help (I need someone to sign with pgp) [ x ] (+1) +1 I'll help. I've signed a few files but I'll happily stand on the sidelines and watch Steve and you figure it out ;-). Seriously Antoine's recipe in the ReleaseInstructions are great and you won't need more. Any reason why you can't create a key for yourself? Stefan - 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]
Re: bug: jar task with nested service does not create META-INF/services
Thanks,
this has already been noticed and a fix will be in ant 1.7.1.
In the meantime, the service nested element should not be used.
Peter
On Wed, Feb 27, 2008 at 3:12 PM, Robert Koberg [EMAIL PROTECTED] wrote:
Hi,
I am trying to use the nested service element in the jar class. It
produces a META-INF/service rather than META-INF/services:
/**
* Write SPI Information to JAR
*/
private void writeServices(ZipOutputStream zOut) throws IOException
{
Iterator serviceIterator;
Service service;
serviceIterator = serviceList.iterator();
while (serviceIterator.hasNext()) {
service = (Service) serviceIterator.next();
//stolen from writeManifest
super.zipFile(service.getAsStream(), zOut,
META-INF/service/ + service.getType(),
System.currentTimeMillis(), null,
ZipFileSet.DEFAULT_FILE_MODE);
}
}
Bug?
best,
-Rob
-
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]
Re: 1.7.1 - Beta Vote
On Tue, Feb 26, 2008 at 3:07 PM, Steve Loughran [EMAIL PROTECTED] wrote:
Steve Loughran wrote:
Kevin Jackson wrote:
Hi,
As I mentioned previously (although I'm a couple of days late).
I'd like to release a beta of 1.7.1 within the next two weeks.
The current 1.7.1 trunk is now locked for further changes (99.9% test
completion on the most troublesome platform (windows))
The beta of 1.7.1 is ready:
[x] yes (+1)
[ ] no (you missed something...)
That said, I want to look at why it doesn't work on a network mounted
windows drive. I'll do that this afternoon.
gosh, this is a fun bug.
when you run ant on a remote share, we dont get the right path to the
lancher jar, so things go horribly wrong
Launcher JAR: C:\morzine\slo\Java\Apache\ant\lib\ant-launcher.jar
launcher Directory: C:\morzine\slo\Java\Apache\ant\lib
but I factored out the test and it works; we are creating the correct path.
public void testAntOnRemoteShare() throws Throwable {
String launcher =
//morzine/slo/Java/Apache/ant/lib/ant-launcher.jar;
String jarURI
= jar:file:+ launcher
+!/org/apache/tools/ant/launch/Launcher.class;
String resolved=Locator.fromJarURI(jarURI);
assertResolved(jarURI,launcher,resolved,true);
}
Either we're pasting in the CWD in front, or new File() is doing it for us.
Does this happen in ant 1.7.0 ?
If it does, this means that this bug should be not a reason to hold up
ant 1.7.1.
Peter
-
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]
Re: 1.7.1 - Beta Vote
x yes +1 Peter On Mon, Feb 25, 2008 at 2:39 AM, Kevin Jackson [EMAIL PROTECTED] wrote: Hi, As I mentioned previously (although I'm a couple of days late). I'd like to release a beta of 1.7.1 within the next two weeks. The current 1.7.1 trunk is now locked for further changes (99.9% test completion on the most troublesome platform (windows)) The beta of 1.7.1 is ready: [x] yes (+1) [ ] no (you missed something...) Kev PS - my +1 is already in the above :) - 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]
Re: xmlproperties task
ANT svn (trunk) supports loadFromXML in the properties task. This has not been ported to the ANT 1.7 branch. Peter On Mon, Feb 25, 2008 at 12:21 PM, Thorsten Scherler [EMAIL PROTECTED] wrote: On Fri, 2008-02-22 at 14:56 -0800, Bruce Atherton wrote: What I think you are missing is that the XML hierarchy translates into the name of the property. This is true whether you use Semantic Attributes or not, since they do not alter the name. Hmm, then I misunderstood http://ant.apache.org/manual/CoreTasks/xmlproperty.html Semantic Attributes ... id: The property is associated with the given id value. For me that sounds (and actually IMO makes awfully lot of sense) that if I use @id, the property will use this id as name. Then the java xml files from properties.loadFromXML(...) method will not work with the xmlproperty task either (let alone that they do not even have a @id), since they look like: ?xml version=1.0 encoding=UTF-8? !DOCTYPE properties SYSTEM http://java.sun.com/dtd/properties.dtd; properties entry key=plugin.TestPlugincom.plugin.test.TestPluginModule/entry entry key=messages.TestPluginTestPluginMessages.properties/entry /properties Is there interest to have a java compatible xml properties task, if so I will likely need to write one for my current project and can submit a patch. Thanks for your answer Bruce. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions - 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]
Re: [VOTE] add Nicolas Lalevée as committer
On Feb 13, 2008 3:06 PM, Dominique Devienne [EMAIL PROTECTED] wrote: On Feb 13, 2008 3:35 AM, Xavier Hanin [EMAIL PROTECTED] wrote: Even though only votes cast by PMC members are binding [12], all votes are welcome and important to us. +1. --DD +1 Peter - 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]
Re: AW: Need documentation change for if / unless
Mmm,
the manual states:
A target also has the ability to perform its execution if (or unless)
a property has been set. This allows, for example, better control on
the building process depending on the state of the system (java
version, OS, command-line property defines, etc.). To make a target
sense this property, you should add the if (or unless) attribute with
the name of the property that the target should react to. Note: Ant
will only check whether the property has been set, the value doesn't
matter. A property set to the empty string is still an existing
property. For example:
target name=build-module-A if=module-A-present/
target name=build-own-fake-module-A unless=module-A-present/
In the first example, if the module-A-present property is set (to any
value, e.g. false), the target will be run. In the second example, if
the module-A-present property is set (again, to any value), the target
will not be run.
I do not know how it could be more explicit.
Peter
On Feb 5, 2008 3:08 PM, Dean Schulze [EMAIL PROTECTED] wrote:
Rainer,
You couldn't be more wrong about the lack of documentation of the non-use of
the ${} notation in if / unless.
The section about targets DOES NOT say that you don't use the ${} notation
for if / unless. It does say this, however:
'This is done by placing the property name between ${ and } in the
attribute value.'
which leads you to believe that you need ${} notation wherever you need a
property in an attribute, such as in if / unless.
How about helping your users out and making it clear that you don't use ${}
notation with if / unless, in marked contrast to everywhere else in Ant.
Since if / unless are apparently the only place in Ant where you don't use
${} notation that fact should also be pointed out explicitly so people don't
forget the ${} notation elsewhere.
Rainer Noack [EMAIL PROTECTED] wrote: Hi Dean,
${} refers to the value of a property.
if / unless attributes refers to the existence (i.e. name) of a property.
IMHO, the different notation is reasonable.
However, this syntax and behaviour is pointed out explicitely in the manual:
-Using Ant-Targets
Cheers
Rainer
-Ursprüngliche Nachricht-
Von: Dean Schulze [mailto:[EMAIL PROTECTED]
Gesendet: Samstag, 2. Februar 2008 16:15
An: dev@ant.apache.org
Betreff: Need documentation change for if / unless
I filed this bug regarding the use of the if and unless attributes of
:
http://issues.apache.org/bugzilla/show_bug.cgi?id=44315
Matt Benson pointed out that the problem is that you don't use the ${}
notation when naming a property in an if or unless attribute. This is
confusing because everywhere else in Ant when you reference a property you
use the ${} notation.
The documentation for Targets doesn't mention this:
http://ant.apache.org/manual/using.html#targets
The fact that you don't use ${} notation for the if / unless attributes
needs be made explicit in the documentation.
Are there any other places where you use a property without using the ${}
notation? If so these also need to be made explicit. If the if / unless
attributes are the only place where this applies that should also be noted
in the documentation for if / unless.
Thanks.
Dean
-
Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
now.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: import re-imports top-level build.xml
On Jan 28, 2008 10:55 PM, Vallon, Justin [EMAIL PROTECTED] wrote: When import is given the same path twice, it skips the second import. However, if import is given a path to the original (top-level) build-file, it does not consider it a duplicate import, and imports it (again) ... unless ant is invoked as ant –f /full/path/to/build.xml - then import does recognize that the file has already been imported. That does sound like a bug!. Please file a bugzilla report. Ta. Peter I would expect that import should not (ever) import the top-level build file again. Is this a bug? I can submit a bug report and try to fix it. Why import the top-level file? In a (parent, subproject1, subproject2, subproject3) setup, my parent project imports the subprojects and the subprojects import the parents – subprojects do not import each other. When the parent is built, the top-level project imports subproject A, and subproject A imports the parent. The import of the parent is not suppressed because the top-level build was not invoked with a full-path to the build file, and confusion ensues. Example: $ cat build.xml project name=test echo message=test-top / import file=./build.xml / echo message=test-bottom / /project $ ant Buildfile: build.xml [echo] test-top [echo] test-top [echo] test-bottom [echo] test-bottom BUILD SUCCESSFUL Total time: 0 seconds $ ant -f $PWD/build.xml Buildfile: /a/vallon/tmp/tmp.20080128/build.xml [echo] test-top [echo] test-bottom BUILD SUCCESSFUL Total time: 0 seconds $ ant -version Apache Ant version 1.7.0 compiled on December 13 2006 -Justin office 8-383-6725, 212-272-6725; cell 917-861-6042 *** Bear Stearns is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity contained in this communication. *** - 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]
Re: AW: ant java versions
On Jan 16, 2008 10:28 AM, Steve Loughran [EMAIL PROTECTED] wrote: Peter Reilly wrote: I do not think we should do this. As far as I know, there is no super compelling reason to make ant only work on java 1.4 +, I was curious as it is a lot easier to do relative URLs with the java.net.URI class, which is java 1.4+ only java5, on the other hand we switched to java5 @ Work, primarily because once you read all the (wonderful) papers on the Java Memory Model, you can't trust the JVM's memory accesses to volatile keyworded data in a multithreaded app. It does offer lots of advantages -new collections -iterators -ability to have subclasses return subtypes on overridden methods -concurrency API That's before you worry about annotations. I think if we made a jump to java5 for Ant1.8 we'd upset all the java1.4 users out there (and there are still a lot -I can see that for discussons on testng-users mailing list, people who annotations in javadoc. However, I can also see that we'd want to move to java 5 eventually, and we need to move from java1.3 to 1.4 first. So having a move from java1.3 for java 1.8 would seem a first a step. There are a woe-full amount of java 1.3 users as well.. Peter -- Steve Loughran http://www.1060.org/blogxter/publish/5 Author: Ant in Action http://antbook.org/ - 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]
Re: moving to Jira
I use gmail, and find the JIRA conversation per message a mess. I would be -1 until this has been resolved. Peter On Jan 16, 2008 4:47 PM, Xavier Hanin [EMAIL PROTECTED] wrote: On Jan 16, 2008 5:25 PM, Steve Loughran [EMAIL PROTECTED] wrote: I know its been discussed before, but I'd to raise the idea again: moving to JIRA for reporting putting aside the main feature for end users -a better UI- what I like about using at work is - automatic polling of SVN and building of a change log from keywords like SFOS-123 http://jira.smartfrog.org/jira/browse/SFOS-570?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel -automatic release note building http://jira.smartfrog.org/jira/secure/ReleaseNote.jspa?projectId=1styleName=Htmlversion=10092 the tool encourages you to move to a world of 'declare the bug', commit with the bug ID, close the bug. This is something we sort of do in Ant, but not rigorously enough. Having just started doing some Ant work this week, I can really feel the difference that switching to bugzilla gives, its like moving backwards +1 And for Ivy we use JIRA, so it would also be more uniform to use the same tools. Xavier -steve -- Steve Loughran http://www.1060.org/blogxter/publish/5 Author: Ant in Action http://antbook.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: ant java versions
On Jan 17, 2008 12:19 AM, Bruce Atherton [EMAIL PROTECTED] wrote: Peter Reilly wrote: There are a woe-full amount of java 1.3 users as well.. Peter And of 1.2 users that we abandoned during the 1.7 release. But the thinking at that time, and I think it holds up here as well, is that if those users are too conservative to move beyond a JVM which has now reached end-of-life, they are also too conservative to upgrade to the latest version of Ant. The main reason (IMO) we moved from java 1.2, was that it java5's javac generated bad byte code for java 1.2. Peter - 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]
Re: AW: ant java versions
On Jan 15, 2008 12:51 PM, [EMAIL PROTECTED] wrote: 2. What is the minimum version of Ant that 1.8 is targeting? I'm not sure whether we've made any decision to change what we have as a minimum requirement for 1.7. we dropped 1.2, so it is 1.3 http://marc.info/?l=ant-devm=117794737813795w=2 OK. Ant 1.3 is still out there. It would be nice to move up to 1.4 for the 1.8 codebase, at least for some things. I wonder how much use of 1.3 is out there? I think there was already a try to start a vote of dropping Java 1.3 as it should be at end of life. I do not think we should do this. As far as I know, there is no super compelling reason to make ant only work on java 1.4 +, java5, on the other hand Peter But if I remember right without any success. What is the newest JDK version on our supported platforms? Jan - 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]
