Re: Hoped for advantages of migrating to git
On Mon, May 5, 2014 at 8:22 AM, Nicolas Lalevée nicolas.lale...@hibnet.org wrote: once a committer is satisfied with the result, the work is being imported into the git repo with a script A much more straightforward workflow is just to do all work in the GitHub repo, accepting pull requests simply by pressing the Merge button, and have some cron process to push from the GH repo to the ASF repo—using the latter merely as a mirror to satisfy legal requirements, and acknowledging that GH is far more functional and pleasant to work with. I am not working on Ant these days (everything pertaining to my job uses Maven) so I have little personal stake; this is just a suggestion. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AntClassLoader performance problem
Just an FYI that resource loading in AntClassLoader can be extremely inefficient; this change https://github.com/jenkinsci/jenkins/commit/9a2882dd704bece9b7ca51a52347dad15d79f843#diff-8350d999dfd5b0afa845690062db133fR250 in a modular system resulted in a 2–3 order of magnitude (!) improvement in resource lookup times. https://issues.jenkins-ci.org/browse/JENKINS-22310?focusedCommentId=197405page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-197405 has an explanation. (I am not convinced that patch is the right solution; perhaps it is the findResources method which should be corrected, or perhaps Jenkins is misusing ACL.) Whether this would really affect Ant builds is dubious; the problem arises when you have a DAG of class loaders with a lot of alternate pathways to the root. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1560253 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/Javadoc.java
FYI there is a FindBugs rule for this.
Re: unpredictable failure of FileChannel#transferFrom
On Sat, Jan 4, 2014 at 10:23 AM, Stefan Bodewig bode...@apache.org wrote: all Ant sees is a plain IOException so we cannot handle the case by falling back to stream based copying. Why not? Even if the IOException is “genuine” (missing permissions, etc.), a fallback to stream copying would presumably fail with the same error. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1554758 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/AntClassLoader.java src/tests/antunit/taskdefs/optional/junit/junit-test.xml src/tests/junit/org/apache/tools/ant/
On Thu, Jan 2, 2014 at 2:22 AM, bode...@apache.org wrote:
+try {
+jarFile = new JarFile(file);
+} catch (ZipException notAJar) {
+// raised if a file that is not a ZIP
Would also be thrown if the file _is_ a ZIP file but there was some
(potentially significant) error opening it. Could consider checking
the file header for the magic sequence {0x50, 0x4b, 0x03, 0x04} and
rethrowing the exception. (Have observed {0x50, 0x4b, 0x05, 0x06} in
empty archives as well, so maybe just check for {0x50, 0x4b} i.e.
PK.)
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1554684 - in /ant/core/trunk: ./ src/main/org/apache/tools/ant/ src/main/org/apache/tools/ant/helper/ src/main/org/apache/tools/ant/taskdefs/ src/main/org/apache/tools/ant/types/
On Wed, Jan 1, 2014 at 4:55 PM, bode...@apache.org wrote: +URLConnection conn = resource.openConnection(); +conn.setDefaultUseCaches(false); +ArgumentProcessor processor = getProcessorByService(conn.getInputStream()); Why setDefaultUseCaches, which sets a static flag applicable to all future connections? I think setUseCaches was meant here. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Future of JDK 5 support in Ant
On 07/19/2013 11:00 AM, Stefan Bodewig wrote: · javax.script instead of having to depend on BSH we already do that. Well, using reflection yes; the same is true of some other post-5 APIs. Updating the minimum version would merely allow the code to be simplified. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Future of JDK 5 support in Ant
It has now been almost a year and a half since I called a vote to drop JDK 1.4 support for 1.9.0. Is anyone thinking about when to drop JDK 5 support for running Ant itself, e.g. in 1.10.0 or whatever? (Keeping the ability to fork older tools for javac etc. of course.) Jenkins has already done so in dev builds, and Maven devs are discussing it. Eclipse Kepler and IDEA 12 both seem to require JDK 6+, and NetBeans 7.4 beta already requires JDK 7+. Potential benefits of a 6+ dependency include: · fewer combinations to test—do not need to debug test failures only occurring on JDK 5 any more · easier to test against baseline JDK (cannot download JDK 5 without oracle.com login, and IIUC it is not available on Macs at all) · OpenJDK 6 exists, so we would be based on an OSS platform (no OSS Java 5 impl is widely used) · -target 6 bytecode is faster to load due to split verifier, reducing Ant run time a bit · miscellaneous new APIs useful to us, e.g. File.setWritable which makes /usr/bin/chmod unnecessary in most cases, or java.io.Console, etc. · javax.script instead of having to depend on BSH . javax.tools so that in-process javac can be run with a supported API (incl. rich diagnostics, virtual input files, etc.) · javax.annotation.processing javax.lang.model for various purposes, e.g. compile-time verification of task class signatures if defining tasks w/ annotations Of course Java 7 introduces more things of interest, such as java.nio.file and minor language improvements, but I expect Java 6 is still widely enough used at this point that requiring 7+ would be unpopular. This message should not be considered a proposal so much as a testing of the waters. - 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; 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
Version updates in BZ
E.g. https://issues.apache.org/bugzilla/show_bug.cgi?id=54583 Antoine Levy-Lambert anto...@apache.org changed: What|Removed |Added Version|1.9.0 |1.9.1 Is this really necessary/desirable? If the bug was reported against 1.9.0 and not fixed we can presume it still applies to 1.9.1 as well. Or is there a longstanding convention about 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; my NetBeans colleagues say an exploratory integration went well. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: JUnit4 requirement
On 04/03/2013 12:14 AM, Stefan Bodewig wrote: I don't really have an opinion myself whether we still want to support JUnit 3.x or not. To be clear, we absolutely need to support 3.x *tests*. The question is whether we want to mandate that junit-4.*.jar be in the test classpath even for projects using only JUnit 3.x features. I do not think this is an unreasonable concession to progress, but it will break some builds. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1462911 - in /ant/core/trunk/src: main/org/apache/tools/ant/taskdefs/Jar.java main/org/apache/tools/ant/taskdefs/Zip.java tests/junit/org/apache/tools/ant/taskdefs/ZipExtraFieldTest.j
On 03/31/2013 06:22 AM, bode...@apache.org wrote:
+public static final class Zip64ModeAttribute extends EnumeratedAttribute {
BTW for new code you can simply use an enum.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1462931 - in /ant/core/trunk: WHATSNEW manual/Tasks/ear.html manual/Tasks/jar.html manual/Tasks/war.html manual/Tasks/zip.html
On 03/31/2013 07:24 AM, bode...@apache.org wrote: +pWhen Ant writes compressed entries into the archive it creates it + doesn't know the compressed size of an entry before it has been + written. Unfortunately the decision whether a Zip64 extra field + will be written has to be made before writing the entry's + content./p Seems like there should be some way around this, by compressing to a temporary buffer perhaps? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1462911 - in /ant/core/trunk/src: main/org/apache/tools/ant/taskdefs/Jar.java main/org/apache/tools/ant/taskdefs/Zip.java tests/junit/org/apache/tools/ant/taskdefs/ZipExtraFieldTest.j
On 03/31/2013 02:23 PM, Stefan Bodewig wrote: I must admit I haven't checked whether IntrospectionHelper supports enums, does it do so already? If so, great. Yes, see getEnumSetter. If I want a different string representation like as-needed then I still end up writing a mapping class Or just use ‘as_needed’ or ‘asNeeded’ etc. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1462931 - in /ant/core/trunk: WHATSNEW manual/Tasks/ear.html manual/Tasks/jar.html manual/Tasks/war.html manual/Tasks/zip.html
On 03/31/2013 02:20 PM, Stefan Bodewig wrote: compressing to a temporary buffer perhaps? We do so for STORED entries and risk OutOfMemoryExceptions (we could throw away the buffer and just count). The performance impact would be non-trivial for big files, which is what Zip64 really is about. Do you know when you start the entry how big it is _uncompressed_? If so, you could say that for anything largish, just compress to a temporary file, and then write the entry from that. Not sure if such hacks are worth the effort just to support Java 5, which is long past EOL anyway. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1460264 - in /ant/core/trunk: WHATSNEW build.xml src/etc/poms/ant-junit/pom.xml src/etc/poms/ant-junit4/ src/etc/poms/pom.xml
On 03/27/2013 06:48 PM, Michael Clarke wrote: https://github.com/mc1arke/ant/commits/JUnitNonTestsSkipped FYI: the more helpful URL is https://github.com/mc1arke/ant/compare/JUnitNonTestsSkipped which shows that you have mixed some changes into this branch which do not really belong there. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1461421 - in /ant/core/trunk/manual/Tasks: ear.html jar.html war.html zip.html
On 03/27/2013 02:02 AM, bode...@apache.org wrote: URL: http://svn.apache.org/viewvc/ant/core/trunk/manual/Tasks/zip.html?rev=1461421r1=1461420r2=1461421view=diff - brPossible values are never, always and not-encodable + brPossible values are never, always and not-encodeable Is this the actual enum value? Because “encodable” would be the correct English spelling. (java.lang.Cloneable was the product of ignorance and seems to have spawned a generation of mistakes.) - 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. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Contributions (was: Re: Suggestion - JUnit4 tests for Ant)
First, BuildFileRule sounds like a great idea; do not see a patch so cannot comment further. Second, should Michael just be nominated as a committer? The @Ignore change was complex and valuable, and refactoring unit tests demonstrates serious intent. Third, why are we still using Subversion when we could be using Git [1]? Apache makes us keep the “official” repo on git.apache.org. That is lame, especially given the existence of CLAHub [2]; but with Git you can still do your real work on GitHub, whose crown jewel is of course the pull request system. PRs make it much, much easier to evaluate, comment on, iterate, and accept contributions than patches attached to Bugzilla—and make the distinction between “committer” and “frequent contributor” only a matter of whether you have the permission to click the “Merge” button at the end. That said, Antoine is doing most of the work these days so whatever environment he is most comfortable in wins. Just thought I would put out a probe. [1] http://www.apache.org/dev/writable-git [2] http://www.clahub.com/ - 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]
“Changes that could break older environments” fails to list the Java 5 requirement! Typo in WHATSNEW: “NullPointerExcpetion” Otherwise, +1. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Build failed in Jenkins: Ant-Build-Matrix » JDK 1.6 (latest),Windows #555
On 03/05/2013 11:13 PM, Apache Jenkins Server wrote: [exec] [au:antunit] Build File: https://builds.apache.org/job/Ant-Build-Matrix/./jdk=JDK%201.6%20(latest),label=Windows/ws/trunk\src\tests\antunit\taskdefs\exec\apply-test.xml [exec] [au:antunit] Tests run: 30, Failures: 0, Errors: 0, Time elapsed: 0.539 sec [exec] [au:antunit] Target: testSrcfilePrefix took 0.002 sec [exec] [au:antunit] Target: testRedirectorWithParallel took 0.002 sec [exec] [au:antunit] Target: testLsPathParallel took 0.002 sec [exec] [au:antunit] Target: testForce took 0.003 sec [exec] [au:antunit] Target: testRedirector14 took 0.001 sec [exec] [au:antunit] Target: testRedirector13 took 0.001 sec [exec] [au:antunit] Target: testRedirector12 took 0.002 sec [exec] [au:antunit] Target: testRedirector11 took 0.002 sec [exec] [au:antunit] Target: testRedirector10 took 0.002 sec [exec] [au:antunit] Target: testTargetfileSuffix took 0.001 sec [exec] [au:antunit] Target: testRedirector9 took 0.001 sec [exec] [au:antunit] Target: testNoRedirect took 0.001 sec [exec] [au:antunit] Target: testRedirector8 took 0.002 sec [exec] [au:antunit] Target: testRedirector7 took 0.001 sec [exec] [au:antunit] Target: testRedirector6 took 0.001 sec [exec] [au:antunit] Target: testIgnoreMissing took 0.002 sec [exec] [au:antunit] Target: testRedirector5 took 0.002 sec file:///f:/hudson/hudson-slave/workspace/Ant-Build-Matrix/jdk/JDK%201.6%20(latest)/label/Windows/trunk/build/antunit/xml/TEST-src.tests.antunit.taskdefs.exec.apply-test_xml.xml; lineNumber: 257; columnNumber: 1; XML document structures must start and end within the same entity. Indeed the file ends with testcase name=testLsPath time0.0020/time /testcase with no closing /testsuite. Perhaps the test itself somehow kills the test runner? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Build failed in Jenkins: Ant-Build-Matrix » JDK 1.6 (latest),Windows #555
On 03/06/2013 07:44 AM, Jesse Glick wrote: Perhaps the test itself somehow kills the test runner? More likely an OOME of some kind; asked for help on bui...@apache.org. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [Bug 54641] XSLTC problem with StringUtils
On 03/05/2013 11:19 PM, Antoine Levy Lambert wrote: can this problem with the junit-frames.xsl wait for ant 1.9.1 ? I feel like making another release in one month to 6 weeks from now. If you are volunteering to do another release that soon, then sure! I marked it high priority since it seems to completely break junitreport on currently released JDKs. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1452722 - in /ant/core/trunk: WHATSNEW lib/optional/hamcrest-core-1.3.jar src/etc/poms/ant-junit4/pom.xml src/etc/testcases/taskdefs/optional/junit.xml
On 03/05/2013 05:29 AM, anto...@apache.org wrote:
adding hamcrest to the lib/optional because it is required at runtime for some
tests, also bumping junit dependency in pom file
URL:
http://svn.apache.org/viewvc/ant/core/trunk/src/etc/testcases/taskdefs/optional/junit.xml?rev=1452722r1=1452721r2=1452722view=diff
==
target name=testTestMethods
+property name=tmp.dir value=out/
echo file=${tmp.dir}/T1.javapublic class T1 extends
Intentional?
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1453118 - in /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/optional/junit: BriefJUnitResultFormatter.java PlainJUnitResultFormatter.java TestListenerWrapper.java XMLJUnitResu
On 03/05/2013 08:29 PM, jgl...@apache.org wrote:
-if (annotation != null annotation.value() != null
!annotation.value().isEmpty()) {
+if (annotation != null annotation.value().length() 0) {
(And yes removing the null check was intentional—annotation values are never
null.)
-
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
On 03/04/2013 11:25 PM, Antoine Levy Lambert wrote: in fact the patch is failing one test : testTestMethods in junit-test.xml Now fixed? Reports: skipping tests since it fails when using JUnit 4 But there is one genuine failure I know about, which predates @Ignore support: https://builds.apache.org/job/Ant-Build-Matrix/jdk=JDK%201.7%20(latest),label=Ubuntu/lastCompletedBuild/testReport/org.apache.tools.ant.taskdefs.optional.junit/XMLResultAggregatorTest/testFrames/ Reproducible locally when running on Java 7. Not yet sure what it means but it looks bad. - 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
On 03/05/2013 08:45 PM, Jesse Glick wrote: Reproducible locally when running on Java 7. Not yet sure what it means but it looks bad. https://issues.apache.org/bugzilla/show_bug.cgi?id=54641 - 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
-0. My main reservation is that an important patch, JUnit @Ignore support [1], is outstanding. (I promised Michael Clarke it would get reviewed.) It could be pushed back to 1.9.1 of course, but that could be a long way off. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43969 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant 1.9.0
On 02/19/2013 10:31 AM, Justin Georgeson wrote: have an issue with the javac task and package-info.class Please use Bugzilla to report things like this. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant 1.9.0
On 01/30/2013 10:09 PM, Antoine Levy Lambert wrote: Are there other bugs - ideally with patches - that the community needs? Those with PatchAvailable [1] should be checked. (Pity that we cannot just get pull requests; coming from the land of GitHub this feels really primitive.) There were a fair number recently, e.g. the 54298–54305 series. I cannot see myself spending much time on this now unfortunately, but if you are willing to put together a 1.9.0, +1 to the effort (and incidentally a belated +1 for removing proprietary tasks). [1] https://issues.apache.org/bugzilla/buglist.cgi?keywords=PatchAvailablekeywords_type=allwordsbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDbug_status=NEEDINFOproduct=Antlist_id=95004 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1429602 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/optional/ssh/SSHBase.java
On 01/06/2013 04:46 PM, anto...@apache.org wrote: URL: http://svn.apache.org/viewvc/ant/core/trunk/WHATSNEW?rev=1429602r1=1429601r2=1429602view=diff @@ -1,4 +1,4 @@ -Changes from Ant 1.8.4 TO Ant 1.9.0 +Changes from Ant 1.8.4 TO Ant 1.9.0 Why the indentation? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: New External Task: Reencode
On 10/23/2012 08:25 AM, Nick Watts wrote: I would like to have this task added to the External Tools and Tasks page. http://ant.apache.org/external.html#Reencode - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: File.toURL() and org.apache.tools.ant.launch.Locator.fileToURL(File)
On 08/22/2012 08:50 AM, Nicolas Lalevée wrote: Don't understand the encoding issue there, since we are manipulating Strings. But String's which represent pathnames on an OS which might natively represent pathnames as octet sequences in some encoding. Again I am not sure what the defining example of this problem would be - my former attempts to make Windows deal sanely with non-ASCII filenames from Java failed miserably no matter what I tried, whereas everything just works on Linux. Not sure about Macs. As far I understand, such path reference some file on a remote computer. But then why the host part of the URI being build is left to null? Line #3059 (JDK 7) would not be executed for a UNC path because you would have file://server/share/path. Line #3072 (JDK 6) does pass null for host but the path starts with // so the constructor produces the proper URI in the end. You can check the unit tests if you are interested. It seems we cannot become watchers of jvm bugs, can we? Not sure. You used to be able to, but I have not managed to do this on bugs.sun.com for years. There has been talk of setting up a public JIRA/Bugzilla/etc. instance for the JDK it keeps on getting delayed, and anyway it is unclear if existing bugs would get migrated automatically. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: File.toURL() and org.apache.tools.ant.launch.Locator.fileToURL(File)
On 08/22/2012 02:30 PM, Nicolas Lalevée wrote: I could not think we can put 4 slashes file:server/share/path is the broken result of new File(server\\share\\path).toURI(). While new File(URI) works to round-trip it (IIRC), if you call URI.normalize() or otherwise do any kind of interesting manipulation at the URI level, you wind up with C:\server\share\path which is dead wrong. Path.toUri fixes this problem using the host field. The test is just checking that URI - File conversion is forgiving enough to accept the undesirable URI format if you happened to use File.toURI initially. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: deprecations
On 08/20/2012 01:52 PM, Matt Benson wrote: 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? I think OK so long as you are talking about members in the Java API - I guess we are still keeping compatibility for deprecated task names and attributes. We could probably remove things deprecated in 1.7 as well, since anyone using 1.8.x would have already seen the deprecation warnings, but up to you. Lots of things are marked deprecated but do not mention since when; that needs to be corrected if they are retained. I note with amusement that there are several @deprecated private members. If something is private you do not need to deprecate it - just delete it right away! Make a record in the incompatible changes section of WHATSNEW of course. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: File.toURL() and org.apache.tools.ant.launch.Locator.fileToURL(File)
On 08/21/2012 03:41 PM, Martin Gainty wrote: Make sure you catch IllegalArgumentException - If this URL is not absolute Should never happen in this case. MalformedURLException - If a protocol handler for the URL could not be found, or if some other error occurred while constructing the URL Should also never happen, but unfortunately it is a checked exception so you have to catch it and rethrow as e.g. AssertionError anyway. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: File.toURL() and org.apache.tools.ant.launch.Locator.fileToURL(File)
On 08/21/2012 03:13 PM, Nicolas Lalevée wrote: Or is there some code which rely on the broken behavior? Not that I know of. See the various commented-out code blocks and XXX comments in this class; it has a long and messy history. I do not know whether the current code successfully works around all of File.toURL's failures. Just beware that File.toUri is also broken for UNC paths. For a hint, [1] shows some analogous code in NetBeans which uses the better Path.toUri on JDK 7+, simplifying file:///path to file:/path; falling back to File.toUri with a manual file:server/share/path - file://server/share/path correction. You may also need to be wary of non-ASCII characters in pathnames on operating systems not using UTF-8 consistently. The explanation I got from the author of Path.toUri ([2] p.c.) is that file:///some/path as produced by Path.toUri is expected to retain the original octet sequence used to construct the pathname, whereas file:/some/path may lack this information. The issue might affect interactions with forked processes. I do not understand this very well (on Linux you never have to worry about this kind of nonsense) but it may make sense to you. [1] http://hg.netbeans.org/main/file/release72_base/openide.util/src/org/openide/util/Utilities.java#l3025 [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7176702 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Request for list of core classes in Apache Ant
On 04/15/2012 06:53 PM, Phillip Meyer wrote: If any list like this already exists, please let me know. Not that I know of, though the section of the manual that deals with extending or embedding Ant at the Java level [1] refers to a variety of types which would generally be thought of as core. [1] http://ant.apache.org/manual/developlist.html - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AntUnit test failures in Jenkins
Looks like Ant-Build-Matrix is finally fixed! I have reenabled mail sent to notificati...@ant.apache.org so we can track regressions. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Merging to the 1.8.x branch
On 03/16/2012 04:48 PM, Bruce Atherton wrote: If there are bug fixes that need to go into a future 1.8.4 release we can deal with them when the time comes. Agreed, i.e. option 2. Rather than sifting through all commits made into trunk - which besides Java 5 could include all sorts of code cleanups or other minor stuff - looking to see what might be applicable to 1.8.x, I think it would make more sense to keep the 1.8.x branch relatively frozen. If and when we decide to do a 1.8.4 release, we can look through Bugzilla for fixed bugs with TM = 1.9.0, decide which ones are good backport candidates (important bug, safe and well-tested fix), and merge or otherwise backport just the necessary bug fix commits. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java5 move and Jenkins
On 03/09/2012 04:16 AM, Nicolas Lalevée wrote: As a quick fix I guess we can add in the command line launched by Jenkins a -Djava.io.tmpdir=$WORKSPACE/tmpdir I guess that would work for the AntUnit tests, so try that. For JUnit tests it would probably have no effect since these run in a forked JVM by default. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java5 move and Jenkins
On 03/08/2012 12:04 AM, Stefan Bodewig wrote:
do we have to do anything special to provide the Jenkins build with a
${java.to.tmpdir} that it actually is allowed to write to?
Using ${java.io.tmpdir} from tests is a bit dangerous anyway; the files may rarely or never get cleaned up, you need to consider possible race conditions between
different jobs running on the same node, etc. Can the tests be made to use a tempdir inside the ${basedir} somewhere?
By comparison, most NetBeans unit tests use a utility NbTestCase.getWorkDir() [1] which takes a static root (e.g. ${basedir}/build/test/unit/work/) and appends a suffix
based on the test suite case names. For tests needing File access this is very convenient.
[1]
https://hg.netbeans.org/core-main/raw-file/default/nbjunit/src/org/netbeans/junit/NbTestCase.java
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java5 move and Jenkins
On 03/06/2012 06:21 PM, Jesse Glick wrote: #462 shows tons of AntUnit failures BTW I disabled email notifications as it looks like we are a long way from fixing all of these tests. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java5 move and Jenkins
On 03/05/2012 01:33 PM, Jesse Glick wrote: I am looking into some of the test failures. I think I have fixed most of the failures, though there are still some things that seem to fail at random, especially on Windows. Two points of confusion: 1. All the JDK 1.5 and 1.6 history - including test results - seems to have been deleted, though JDK 1.7 history remains. Anyone know why? Perhaps a bug in the way the build archiver logic works in matrix builds, after a first stable build (#461)? Also the workspace is missing. Note that #461's console reports all six configs being run and ending with SUCCESS. 2. I do not see any test results from AntUnit - do these get run but just not reported? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java5 move and Jenkins
On 03/06/2012 12:53 PM, Nicolas Lalevée wrote: [AntUnit] results were not aggregated by Jenkins. I have fixed it. Confirmed; #462 shows tons of AntUnit failures. Whoever wrote these tests and is still around, consider reviewing them. (I do not think it is safe to do much of anything in trunk until tests are cleaned up.) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Java5 move and Jenkins
On 03/03/2012 12:51 PM, Nicolas Lalevée wrote: So we would have Ant_Nightly which builds the distrib of Ant and gather findbugs warnings, java warnings and TODO/FIXMEs, and we would have the tests run by Ant-Build-Matrix. Looks like an improvement - thanks for setting this up. I am looking into some of the test failures. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [ANNOUNCE] Apache Ant 1.8.3 Released
BTW the 201203010400 development build of NetBeans 7.2 bundles it. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ant 1.8.3 Take 2
+1; have not found any problems so far. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AntUnit test failures
On 02/24/2012 12:12 AM, Stefan Bodewig wrote: It is supposed to be used via ./build.sh antunit-tests. Ah. But when I do that, I get failures that I do not get when I use ./dist/bin/ant -lib lib/optional antunit-tests, e.g.: Build File: .../src/tests/antunit/bugfixes/br50866/br50866-test.xml Tests run: 1, Failures: 0, Errors: 2, Time elapsed: 0.055 sec Target: testinclude caused an ERROR Message: Target middle.common does not exist in the project br50866. It is used from target testinclude. took 0.005 sec caused an ERROR Message: Target middle.common does not exist in the project br50866. It is used from target testinclude. Build File: .../src/tests/antunit/bugfixes/bugzilla-43324-stackoverflow-test.xml Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.033 sec Target: testnested took 0.003 sec caused an ERROR at line 38, column 29 Message: Unable to delete directory /tmp/testinput/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base/A/base BTW this script also fails when run from another dir - which is a useful thing to do sometimes, as it finds things which rely on the CWD (as I did yesterday). I'm not sure how build.xml could detect you were not using the current trunk version of Ant or some older build with the same version. I think it can and will try to fix it to do so in the trunk. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AntUnit test failures
I get a bunch of test failures in trunk using $ ant -lib lib/optional/ant-antunit-1.2.jar antunit-tests under JDK 7u3, Ubuntu. Are these tests normally expected to pass? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AntUnit test failures
On 02/23/2012 04:09 PM, Jesse Glick wrote: $ ant -lib lib/optional/ant-antunit-1.2.jar antunit-tests Never mind, just figured out that you need to use $ ./dist/bin/ant ... to actually test trunk code! Maybe build.xml should detect this somehow and warn you (though of course it would be better if it automatically ran the right copy of Ant). - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AntUnit test failures
...though it hangs in taskdefs/exec/apply-test.xml: apply-test.antunit: Build File: .../src/tests/antunit/taskdefs/exec/apply-test.xml ... main prio=10 tid=0x091c7c00 nid=0x24e0 in Object.wait() [0xf6947000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xdc91bc58 (a java.lang.UNIXProcess) at java.lang.Object.wait(Object.java:503) at java.lang.UNIXProcess.waitFor(UNIXProcess.java:210) - locked 0xdc91bc58 (a java.lang.UNIXProcess) at org.apache.tools.ant.taskdefs.Execute.waitFor(Execute.java:586) at org.apache.tools.ant.taskdefs.Execute.execute(Execute.java:516) at org.apache.tools.ant.taskdefs.ExecTask.runExecute(ExecTask.java:631) at org.apache.tools.ant.taskdefs.ExecuteOn.runParallel(ExecuteOn.java:717) at org.apache.tools.ant.taskdefs.ExecuteOn.runExec(ExecuteOn.java:480) at org.apache.tools.ant.taskdefs.ExecTask.execute(ExecTask.java:498) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.Target.performTasks(Target.java:413) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.ant.antunit.AntUnitScriptRunner.runTarget(AntUnitScriptRunner.java:224) at org.apache.ant.antunit.AntUnitScriptRunner.runSuite(AntUnitScriptRunner.java:303) at org.apache.ant.antunit.AntUnit.doFile(AntUnit.java:268) at org.apache.ant.antunit.AntUnit.doResourceCollection(AntUnit.java:247) at org.apache.ant.antunit.AntUnit.execute(AntUnit.java:218) ... - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Property expansion in macrodef attributes
On 02/21/2012 10:40 AM, Stefan Bodewig wrote: can do the implementation if you agree. If you can beat me to it, please do. Done in trunk, please review. (Especially whether your changes to property-test.xml and propertyhelper-test.xml still stand - I did not understand what was going on with these.) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Property expansion in macrodef attributes
Any updates on #52621 and what we want the behavior to be in 1.8.3? My suggestion still stands to restore the 1.8.2 behavior by default but add an optional parameter to implement the fix of #42046 where needed; can do the implementation if you agree. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Property expansion in macrodef attributes
On 02/14/2012 07:39 AM, Stefan Bodewig wrote:
Most likely you don't want double expansion in most cases.
Right, but how often would you even notice the difference? Usually property values do not themselves contain interpolable variables, as seen by the fact that this problem
has just been reported twice since macrodef was introduced.
The biggest problem I see is AntUnit. Here the macro is defined in a
different place and we'd need a new release that requires Ant 1.8.3 to
fix it.
True; so release a new AntUnit - a much smaller user audience than Ant itself I
suppose.
add the attribute to trunk but make trunk's behavior
default to not expand ${} twice (flagging it as breaking BWC)
This would cause a major problem for the many scripts out there which rely on the current behavior. They could not run unchanged on 1.9 (and few people will find this
item in the release notes, much less understand its implications); nor could they be fixed in advance, since the attribute would be rejected by 1.8.x.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On 02/13/2012 01:25 PM, Bruce Atherton wrote: could Java 7 and NIO 2.0 be a good reason to create Ant 2.0? While the new java.nio.file.* APIs are indeed valuable for a tool like Ant, I hardly think a fork or major rewrite is required to take advantage of them. As Stefan pointed out, it would be as easy as creating a new FileUtils subclass, and for now compiling it conditionally. Whenever we drop JDK 5 and 6 support and require JDK 7 (which BTW is soon to be available for all major platforms when the Mac version is released), it will be simple to make that be the standard impl. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Property expansion in macrodef attributes
On 02/12/2012 05:13 AM, Stefan Bodewig wrote:
I'm not sure whether the macrodef writer will always know whether she
wants double-expansion or not.
I would say that if you come across a problem like that mentioned in #42046
then you know you do not want double expansion and should explicitly turn it
off.
In most cases the script calling the macro will be the same as the script defining it, or at least located in the same project, so I doubt documentation of the macrodef
is an issue; though discoverability of the flag in the macrodef task may be poor even with a FAQ entry.
If this problem had been noticed when macrodef was first introduced, then single expansion would be the more intuitive behavior, especially if #29347 were fixed properly
so that ${thing.${choice}} works the way people expect it to, but it is too late to change the default behavior of macrodef.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ant 1.8.3
On 02/06/2012 03:28 PM, Stefan Bodewig wrote: Maven artifacts: https://repository.apache.org/content/repositories/orgapacheant-203/org/apache/ant/ Typo in Javadoc artifact: ant-1.8.3-javadocs.jar should be ant-1.8.3-javadoc.jar. (Not just cosmetic; Maven-based tools including IDEs may fail to find Javadoc under the wrong name.) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ant 1.8.3
On 02/07/2012 10:27 AM, Stefan Bodewig wrote: I have re-uploaded the Maven artifacts, the only change is that ant-1.8.3-javadocs.jar* has been renamed to ant-1.8.3-javadoc.jar* New URL is: https://repository.apache.org/content/repositories/orgapacheant-206/org/apache/ant/ Good. Confirmed that dependency groupIdorg.apache.ant/groupId artifactIdant/artifactId version1.8.3/version /dependency works for a Maven project using Ant tasks when ~/.m2/settings.xml specifies profile idverify-stage/id repositories repository idapache-staging/id urlhttps://repository.apache.org/content/groups/staging//url releases enabledtrue/enabled /releases /repository /repositories /profile and -Pverify-stage is passed. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Release Ant 1.8.3
-1 because of regression #52621 [1] which completely breaks a lot of build scripts used by and generated by NetBeans, and probably anything else requiring recursive property expansion. [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=52621 - 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
On 01/27/2012 05:29 PM, Maarten Coene wrote: +1 to drop JDK1.4 support for Ant 1.9, and after 1.8.3 is branched we permit trunk sources to assume JDK5+ Agreed and sorry for not offering this as an option to begin with. So let us assume with a +1 that if there is any demand for a 1.8.4 supporting JDK 1.4, we svn cp https://svn.apache.org/repos/asf/ant/core/tags/ANT_183 https://svn.apache.org/repos/asf/ant/core/branches/ANT_18_BRANCH and backport selected fixes there. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: 1.8.3?
On 01/26/2012 12:19 PM, Stefan Bodewig wrote: One thing I want to do is giving a recent OpenJDK8 snapshot a try so Ant 1.8.3's javac would support building for 1.8/8 when that gets released. I would not bother with that at this point. JDK 8 is expected to include a module system, which is likely to have a huge impact on how javac is invoked. Earlier builds will likely include support for lambdas; I doubt Ant needs to do anything in particular except support source=1.8. There are more bugs we could address but then again if anybody wants to work on them nobody will stop us from doing more frequent releases. Agreed, it is better to release what exists now. Thank you for taking initiative on this. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[VOTE] Drop JDK 1.4 after 1.8.3
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.) Switching trunk sources to assume JDK 5 would, among other things, permit use of generics to make code clearer. It is also possible that annotations could be used to document tasks/types and their configuration. And of course there are various API enhancements that may be of use; a search for jdk1.5 in build.xml shows some things that could be simplified, and there is likely more that would be used if it were easy to do so. [X] +1: announce that 1.8.3 will be the last version of Ant to support JDK 1.4, and after it is branched, permit trunk sources to assume JDK 5+, updating CI jobs accordingly [ ] ±0: not sure, maybe continuing to support JDK 1.4 is useful, leave it alone for now [ ] -1: please no, we still need to support JDK 1.4 in 1.8.4 or 1.9 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: 1.8.3?
On 01/20/2012 12:25 AM, Stefan Bodewig wrote: I don't have Java 1.4 around anymore and wouldn't really know where to obtain one. http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase14-419411.html#j2sdk-1.4.2_19-oth-JPR I still have a copy of this running on Ubuntu Oneiric if you cannot get this installed. A committer needs to be the one to do release builds I guess. (I hope this will be the last Ant release running on such an ancient VM...) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: 1.8.3?
On 01/16/2012 12:27 AM, Stefan Bodewig wrote: what do you think about putting out a new release? +1; looks like around forty issues fixed so far in 1.8.3 - not a lot, but enough time has passed. A few issues are still open but marked as TM=1.8.3. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: trouble fetching Ant dependencies -- getting HTTP 403 forbidden
On 10/21/2011 11:34 AM, Nicolas Lalevée wrote: I have search in every maven repository I know, it seems the jai-core.jar has disappeared... fetch.xml:116: Unable to resolve artifact: Unable to get dependency information: Unable to read the metadata file for artifact 'javax.media:jai-core:jar': Error getting POM for 'javax.media:jai-core' from the repository: Error transferring file javax.media:jai-core:pom:1.1.3 from the specified remote repositories: remote (http://repository.jboss.org/maven2), central (http://repo1.maven.org/maven2) It it still there, but the repo URL is wrong; should be [1]. I have fixed fetch.xml accordingly. (There is a similar artifact at [2].) [1] https://repository.jboss.org/nexus/content/groups/public/ [2] http://maven.glassfish.org/content/groups/public/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: xor condition
On 07/16/2011 08:59 PM, Matt Benson wrote: xor(true, false) == true xor(true, false, true) == false xor(true, false, true, false) == false Is this correct? Follows the usual semantics; cf.: http://en.wikipedia.org/wiki/Exclusive_or#Associativity_and_commutativity It would seem that semantically an xor over multiple nested conditions should mean that exactly one value should evaluate true in order for the xor operation to yield truth. Which is in fact the case in the examples you mentioned, but probably you are thinking of xor(true, true, true) == true which is consistent with the algebraic definition, and the behavior of Java's ^ operator for that matter. If you wanted a condition with the semantics you describe, it should be named something else. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant Plugins - ant version compatibility
On 06/20/2011 09:40 AM, Michael Nellis wrote: I am investigating how to determine whether an Ant plugin, built with Ant 1.8.1, will work with Ant 1.8.2. Do you mean an Ant task? Generally it should work this (not the reverse of course), though specific incompatibilities ought to be mentioned in the changelog. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Command Line Debugging
On 06/09/2011 05:42 AM, Nicolas Lalevée wrote: At some point we may imagine a debugger in an IDE like Eclipse too. By the way there has long been an Ant debugger in NetBeans. Just select Debug Target from the context menu of a build script in e.g. the Files tab. Breakpoints and property inspection are supported. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Sources of the ant jars into the maven repository
On 04/12/2011 02:06 PM, Nicolas Lalevée wrote: Is there any objection regarding the publication of such jars ? Please do so. In fact I am surprised that earlier releases were accepted into the Central repository without sources and Javadoc attached. Note that you ought to be able to just run: mvn -f src/etc/poms/pom.xml -Prelease-profile -DskipTests install but it seems to be broken. I tried to clean up src/etc/poms/ a while back. The main source of complexity is that there is a single source tree from which 22 JARs are built, and the division of sources into these JARs is not at all obvious. I proposed refactoring the tree into one source root per output JAR, each with its own classpath and dependencies, but there was no consensus among Ant committers to do so (thread: Ant source tree reorganization). - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: list iteration (was: svn commit: r1066963 ...)
On 02/17/2011 11:30 PM, Kevin Jackson wrote: I tried to introduce some micro-optimizations (pretty much like these) into the Tomcat codebase 8 years ago, but was met with 'meh why bother?' responses as the thinking was that the vm would pretty much make optimizations pointless. I suppose it depends on where the hotspots are. And for a tool like Ant, it is unlikely that iterating a vector is consuming any measurable proportion of execution time, unless for some reason this particular vector is enormous or you are scanning it many thousands of times. Most of the time will be spent waiting for disk I/O, or CPU in some tool like javac. If you actually run a profiler on some typical loads and ignore unavoidable overhead (such as logically necessary file stats), usually you find some weird and vaguely embarrassing problem that you would never have guessed otherwise. - 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
On 02/04/2011 09:03 AM, Antoine Levy-Lambert wrote: 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. Generally the preferred idiom is to use an iterator, which the Java 5 for loop would do if we were not source=1.4. (In the quoted case you are iterating two lists at once so an enhanced for loop would not suffice but Iterator can still be used. In a few other cases the index is needed for another purpose so using an Iterator is less desirable.) - 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.2
On 12/20/2010 12:32 AM, Antoine Levy-Lambert wrote:
However I was not able to reproduce the problem that you mentioned.
Is it possible that you did not put junit-4 on the classpath when running the
junit 4 style test suite ?
No, the property was defined to point to a copy of JUnit 4.8.1. Anyway I can
confirm that my test case works in the 1.8.2 final release (and not with the
initial candidate).
Or else the antunit testscase which I added does not reproduce the failure case.
Well, editing the control method to be clearly bogus
public void ok() {throw new RuntimeException(XXX just testing);}
does not cause a failure either, so the testcase is obviously broken. Even making the test class uncompilable does not cause a failure! I am working on fixing the test
case; the test was being skipped.
Also note that running 'ant test -Dtestcase=...' tests the version of Ant in $PATH, not that from the source tree! I fixed this for JUnit tests but I guess it is still
broken for AntUnit tests.
-
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.2
On 01/04/2011 12:32 PM, Antoine Levy-Lambert wrote: Can you point me to the changes you did to make ant test the version of the source tree? http://svn.apache.org/viewvc?diff_format=hview=revisionrevision=944377 - 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.2
Jesse Glick jesse.glick at oracle.com writes: there seems to be some problem with #34748 not working correctly on JUnit 4.x-style @Test's Found it. In JUnitTask.init, need to add: addClasspathEntry(/org/apache/tools/ant/taskdefs/optional/junit /JUnit4TestMethodAdapter.class); (Can't get my work laptop online just at the moment or I would commit this to trunk.) Regression caused by split of ant-junit4.jar. (Cannot add a test for it easily without relying on JDK 5 to build.) So -1 from me on binaries built without this fix. - 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.2
Jesse Glick jesse.glick at oracle.com writes:
Cannot add a test for it easily without relying on JDK 5 to build.
Manual test case (retyped by hand so please excuse any typos):
property name=junit.jar location=.../
echo file=T1.javapublic class T1 extends
junit.framework.TestCase {
public void testOK() {}
public void testBad() {throw new RuntimeException(failed);}
}/echo
echo file=T2.javapublic class T2 {
@org.junit.Test public void ok() {}
@org.junit.Test public void bad() {
throw new RuntimeException(failed);}
}/echo
javac srcdir=. destdir=. includes=T1.java,T2.java source=6
classpath=${junit.jar} includeantruntime=false/
junit fork=true printsummary=true
classpath path=.:${junit.jar}/
test name=T1 methods=testOK/
test name=T2 methods=ok/
/junit
Expected: both test suites pass with one method each.
Actual 1.8.2 proposed build: T1 passes with one method;
T2 fails in bad() which is supposed to be skipped.
-
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.2
On 12/13/2010 03:59 PM, Antoine Levy-Lambert wrote:
http://people.apache.org/~antoine/dist/
Built big chunks of NetBeans sources without problems. Generally seems to be
working embedded on various scripts.
But there seems to be some problem with #34748 not working correctly on JUnit 4.x-style @Test's which I have not yet tracked down (this works under 1.8.1 with a binary
patch from the #34748 branch). I'm mostly on holiday now, may not be able to get to the bottom of this before the new year. So far I know that JUnitTestRunner is being
called with 'methods' as expected, but runs all the test methods anyway:
import org.junit.Test;
public class SomeTest {
@Test public void a() {}
@Test public void b() {}
}
Execute:Java13CommandLauncher: Executing '.../jdk1.6.0_22/bin/java' with
arguments:
'-ea'
'-classpath'
'...:.../junit-4.8.2.jar:.../ant-launcher.jar:.../ant.jar:.../ant-junit.jar'
'org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner'
'SomeTest'
'methods=a'
'filtertrace=true'
'haltOnError=false'
'haltOnFailure=false'
'showoutput=true'
'outputtoformatters=true'
'logfailedtests=true'
'logtestlistenerevents=true'
'formatter=org.apache.tools.ant.taskdefs.optional.junit.BriefJUnitResultFormatter'
'formatter=org.apache.tools.ant.taskdefs.optional.junit.XMLJUnitResultFormatter,/tmp/TEST-SomeTest.xml'
'crashfile=...'
'propsfile=...'
The ' characters around the executable and arguments are
not part of the command.
Testsuite: SomeTest
junit.framework.TestListener: tests to run: 2
junit.framework.TestListener: startTest(b)
junit.framework.TestListener: endTest(b)
junit.framework.TestListener: startTest(a)
junit.framework.TestListener: endTest(a)
Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.05 sec
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Credentials With Turkish Locale
On 12/02/2010 12:47 PM, Faruk Can Kaya wrote: It is possible due to a String.toLowerCase function. I have seen something like bas?ic. I guess you mean basıc, from BASIC.toLowerCase(). This bug plagues Java software generally. (*) All uses of toLowerCase and toUpperCase in Ant have long since been fixed to pass Locale.ENGLISH but perhaps this fix has not been made in Ivy. (*) I have lobbied without success to get no-arg String.toUpper/LowerCase() to be formally @Deprecated in the Java platform so developers would take notice and fix their code. (On the rare occasions when you actually want a locale-sensitive case conversion, passing Locale.getDefault() makes your intent explicit.) I guess I can try again. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1034687 - /ant/core/trunk/src/main/org/apache/tools/ant/Main.java
On 11/13/2010 02:07 AM, bode...@apache.org wrote: URL: http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/Main.java?rev=1034687r1=1034686r2=1034687view=diff +msg.append(Apache Ant(TM) version ); I guess ™ would not display properly in shells on lame OSs? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: issues with ant
On 11/11/2010 03:35 PM, Stefan Bodewig wrote: javac should do what Ant does for it in the Java5 case. If the user only specifies -target but not -source, assume the user wanted the same version as well (and vice versa). Probably would be beneficial. I can file an issue for it in the Java bug tracker. But there may be compatibility issues with making a change like that, too. I wasn't complaining about JDBC breaking backwards compatibility - I understand it has to be done from time to time. Well, they could have simply introduced Driver2 extends Driver for the new methods, and checked instanceof Driver2 before calling them. Fully compatible, simple, no need for reflection (well technically instanceof + cast are reflective, but no java.lang.reflect.*). Too late. your best bet is to use java.lang.reflect.Proxy. Never thought about that. Wouldn't that cause problems for performance critical implementations Proxy shouldn't be too bad; a proxy class is generated when you create the proxy, so each method call just gets one indirection AFAIK. Method.invoke is a bit trickier - it runs interpreted a few times, and then if you keep on calling it, does some bytecode generation to make an fast inlined method handle. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: issues with ant
On 11/10/2010 12:17 AM, Stefan Bodewig wrote: The projects use a javac task like javac target=1.5.../javac which is translated to a command line javac -target 1.5 ... This works fine with JDK6's javac but causes the error you've cited when run with OpenJDK 7. This is not the first time this happens, the javac developers obviously don't care a bit for backwards compatibility. The real problem is neither javac nor Ant, but the build script, which fails to specify source= The source level defaults to the newest level supported by the compiler, now 1.7; and it may not be *possible* to compile 1.7 sources to 1.5 bytecode in general. Specify source=1.5 and you should be fine. attributes.log(If you specify -target + t + you now must also specify -source + s + ., Project.MSG_WARN); attributes.log(Ant will implicitly add -source + s + for you. Please change your build file., Project.MSG_WARN); And pay attention to warnings in the future. this really is javac's fault There's not really any good alternative policy for javac when the user does not bother to specify a source level. Perhaps the -source and -target parameters should have been mandatory from the very beginning, but they were not; and defaulting them to an old value (how old? 1.0?) would be unintuitive and cumbersome for casual command-line usage. It is the responsibility of a project configuration to always specify these parameters, and Ant is doing its best by issuing a warning if they are omitted. BTW maven-compiler-plugin uses fixed defaults for source and target level, long 1.3 but now 1.5 in recent plugin releases. This is sensible enough given that it forces builds to be repeatable - a given default applies only to a given version of the plugin, which at least as of Maven 3 is also required to be specified by the project. But then users have complained that it should use javac's defaults instead. A similar heated controversy over platform default encoding vs. UTF-8 (when compiling, replacing tokens in text files, etc.) was put to a vote, with Japanese users in particular insisting on using platform default encoding at the expense of build reproducibility - though the affected plugins do issue a warning if platform defaults are used. JDBC is changing in backwards incompatible ways again. [...] I haven't checked the new definition of Driver, let's hope it is possible to implement it in a way that also compiles on JDK 1.4 In general I have found that changes in JDBC, DOM, and some other APIs in the JRE often add interfaces to methods under the assumption that this is breaking only to providers and not consumers. In general it is not possible to implement the new interfaces while remaining compilable against the old APIs, since new methods often have signatures using newly introduced types. If you are implementing this kind of SPI just for unit test mocks, your best bet is to use java.lang.reflect.Proxy. I can look at this particular case. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: class BuildTimeoutException extends BuildException
On 10/28/2010 06:17 AM, Steve Loughran wrote: Ant uses getMessage() primarily to extract some text from BuildException to use in a log or other exception. Probably this should be fixed to use getLocalizedMessage(), if only for consistency with Throwable.printStackTrace. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: class BuildTimeoutException extends BuildException
On 10/27/2010 06:01 AM, Steve Loughran wrote: 4. we leave the error strings alone for fear of [...fear itself?] #4 irritates me, I'd like some details about which subprocess got killed, but if we are searching for the string in Ant's own codebase, then we can be confident that others will be doing the same trick as well. Possible hack: leave Throwable.detailMessage ~ getMessage() alone, but add extra fields getters for the info about the subprocess, and override getLocalizedMessage() to include that information. Then the richer info will be shown in a stack trace, but other code checking e.getMessage() will not be broken. The only problem would be foreign code checking e.toString(), since this also uses getLocalizedMessage(), but I will bet people would naturally look at getMessage() instead. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
ReviewBoard for Ant?
Would this be useful? https://blogs.apache.org/infra/entry/reviewboard_instance_running_at_the It seems we often have in-progress patches that need to be tweaked a bit before use. (I could have used this on #34748; I was accustomed to just creating a Mercurial branch or patch queue for experimental work, but have found that to be a disaster in Subversion.) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ReviewBoard for Ant?
On 10/26/2010 11:12 AM, Stefan Bodewig wrote: I've never used it, but nothing stops us from giving it a try. OK, I filed: https://issues.apache.org/jira/browse/INFRA-3104 So far I haven't been able to register with the site, though. Interesting. I was able to register OK. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1026123 [1/3] - in /ant/core/trunk: docs/antlibs/proper.html docs/antlibs/sandbox.html docs/bylaws.html docs/external.html docs/nightlies.html docs/projects.html docs/resources.html x
On 10/21/2010 04:05 PM, j...@apache.org wrote: URL: http://svn.apache.org/viewvc?rev=1026123view=rev ant/core/trunk/docs/antlibs/proper.html ant/core/trunk/docs/antlibs/sandbox.html ant/core/trunk/docs/bylaws.html ant/core/trunk/docs/external.html ant/core/trunk/docs/nightlies.html ant/core/trunk/docs/projects.html ant/core/trunk/docs/resources.html ant/core/trunk/xdocs/nightlies.xml ant/core/trunk/xdocs/stylesheets/site.vsl URL: http://svn.apache.org/viewvc/ant/core/trunk/docs/antlibs/proper.html?rev=1026123r1=1026122r2=1026123view=diff -a href=./antunit/index.htmlhttp://ant.apache.org/antlibs/antunit//a +nbsp; Something wrong with HTML generation? A lot of things got replaced by nbsp; for no apparent reason. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r1001756 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/helper/ProjectHelper2.java src/main/org/apache/tools/ant/launch/Locator.java src/tests/antunit/taskdefs/taskdef-te
On 09/27/2010 10:49 AM, Stefan Bodewig wrote:
(2) The new tests create JARs that will be loaded by a classloader -
which means Ant cannot delete them because they remain locked until
the JVM has exited.
Can't this at least use something inside ${build.dir}, rather than
${java.io.tmpdir}?
Maybe classloader reset=true ... could be used, if the to-do comment in it to close the old loader were implemented? Or a project when finishing a build could close
all of its outstanding class loader references automatically?
(And AntClassLoader should probably implement Closeable to match URLClassLoader and automatic resource management https://docs.google.com/View?id=ddv8ts74_3fs7483dp
in JDK 7!)
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Hudson target to build Ant via Maven
On 06/25/2010 08:20 AM, Jesse Glick wrote: I'm not an admin so I can't see the job configuration. I am now. I think I finally managed to get all the Ant-related (not Ivy-related) jobs at least succeeding, though there remain various test failures. Building on JDK 1.4 across various slave nodes was the biggest hurdle, as well as replacing shell scripts with (release) Ant invocations to be able to run on Windows. - 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
On 08/19/2010 11:19 AM, Chet Hosey wrote: Perhaps the project tag could be given a behavior attribute Note that there is the antversion condition which lets you enforce a minimum version of Ant, but this is procedural rather than declarative so Ant cannot tell what version of Ant your script expects to be using and adjust its own behavior accordingly. I had long ago suggested a version attribute on project but the response was the new condition - more flexible for the user but unusable for this purpose. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Testlistener Events in JUnit Slows Down Forked Tests in 1.8.x
On 08/19/2010 08:25 AM, Stefan Bodewig wrote: I've added an attribute to enable the events (defaults to false) and a magic property that overrides the attribute setting. OK, though I still think the attribute is useless since the only known use case is for container control. - 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
On 08/18/2010 10:14 AM, kwut...@web.de wrote:
Why doesn't Ant just default to false and just omit warning me about this for
every Ant build?
That would be an incompatible change. Some old build scripts may be intentionally compiling sources against ant.jar (typically because they define Ant tasks), tools.jar
(who knows why), etc. They also ought to set includeantruntime=false but then explicitly add the desired classpath, e.g. pathelement location=${ant.core.lib}/. (The
warning will also go away if you set includeantruntime=true, but this will make your script be less portable.)
I agree that it is irritating to issue this warning so often, but the alternative of breaking compatibility even for a minority of existing scripts seems worse. There are
similar places in Ant where an old default was a bad choice but cannot now be changed compatibly.
(You could also define ANT_OPTS=-Dbuild.sysclasspath=ignore for yourself but
this will not help other people running your script.)
-
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
On 08/18/2010 12:31 PM, Matt Benson wrote: require those running such ancient buildfiles Unfortunately they need not be so ancient. I have come across more than one build.xml from an actively developed project which just assumed that sources could be compiled against org.apache.tools.ant.** without doing anything. Of course fixing such a script is easy if you know what is wrong, but the authors (or new maintainers) may not know what to do when a new Ant release breaks their build. - 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
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
Re: New task contribution
On 08/13/2010 06:35 AM, Andrey Pavlenko wrote:
Exporting properties and references from a sub-project to its parent project
This is something I struggled with in NetBeans-generated Java projects. I wanted to permit build scripts to call dependencies recursively without reentering any
dependencies during a single build (and maintaining locality of information: a script knows only about its own direct dependencies). The natural idea is to just set a
property mentioning ${basedir} when building one project and exit early if it is already set, but this does not work since properties set in a child cannot be propagated
to the parent. The ugly workaround I found was to create a properties file in a build dir when building the topmost project, passing its location to children, and loading
and saving it from each build. Obviously this involves otherwise unnecessary file I/O and is very hard to follow, especially considering that it is tricky to load
properties in an isolated namespace in Ant, and if (...) return; is impossible from the dependency so a subbuild can be skipped only from the depending script.
http://hg.netbeans.org/main-silver/diff/c01e2c997e19/java.j2seproject/src/org/netbeans/modules/java/j2seproject/resources/build-impl.xsl
The lesson I draw is that Ant without script is ill suited to even moderately
complex builds.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Testlistener Events in JUnit Slows Down Forked Tests in 1.8.x
On 08/10/2010 03:00 PM, Stefan Bodewig wrote: buffering on the testrunner side would help but at the same time make the lines unusable for the test listener events that must happen in step with the test to be useful. It would suffice for test listener events to be delivered fairly soon after the fact, say within a second or so. Buffering would be fine if output were flushed after some delay (not just based on exceeding some buffer size). Or you could print to a buffered stream and only flush at one-second intervals, say. do you want to turn events off by default and enable them based on the magic property? Exactly. (Assuming that no proper fix as discussed above is forthcoming.) [This] would break backwards compatibility. Yes, but only from the point of view of Ant containers, of which there are a very limited number (and I do not know if any besides NetBeans use this feature). They need only begin setting this flag unconditionally, which would be ignored by older versions of Ant. The breakage would only be for people running old versions of containers with new versions of Ant - an unusual case. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Testlistener Events in JUnit Slows Down Forked Tests in 1.8.x
On 08/09/2010 03:42 AM, Stefan Bodewig wrote: I plan to add an disableTestListenerEvents First I would like to hear an explanation of why printing a few lines to System.out causes such a big performance hit and why this cannot be fixed. What is waiting for what to finish? Does the problem only occur on Windows? And can it be avoided by just removing calls to flush(), possibly using System.err? We could add a YAMP (yet another magic property) ... This would be much preferable IMHO. The property would just be set by any container which wants to listen to junit progress. (An attribute in the build script is useless for this purpose, even if the default is on - since the user might turn it off for speed of builds in other environments!) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: bug in DOMElementWriter
On 06/27/2010 01:35 PM, Dominique Devienne wrote: with \n, which is just like any other character*, the serializer doesn't do anything special, and the output the also contain a plain \n. Jon is correct: #10; or similar should be emitted for \n. Newlines are _not_ just like any other character; in XML attributes they are collapsed into a generic whitespace sequence. For example, project default=run target name=run echo message=hello there/ echo message=hello#10;again/ /target /project prints hello there hello again In general, there is a certain class of characters other than the usual ' which should be emitted in character entity form by any tool which purports to create round-trippable XML. Others, like #8;, are simply invalid in XML content and cannot be encoded at all. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Hudson target to build Ant via Maven
On 06/25/2010 06:52 AM, jan.mate...@rzf.fin-nrw.de wrote: Building modules in parallel. Good luck there... these are only modules by fiat; they share some source and target dirs. The include/exclude definitions very likely do not form a disjoint union of all source files, so I have no idea if parallel builds will work. But haven't found the place for the patternset. The job is a Maven2-Job Ah, I thought (*) you were using a freeform job (since the master POM is not at the top of the source tree). In that case Hudson ought to collect test results automatically and not abort the build if tests from a module fail. But again, with the pathological source layout it is hard to know whether everything will work automatically. (*) I'm not an admin so I can't see the job configuration. It is possible to configure Hudson to permit anonymous users to view /job/*/config.xml but probably this server does not. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AW: Hudson target to build Ant via Maven
On 06/24/2010 08:30 AM, jan.mate...@rzf.fin-nrw.de wrote: Configuration: Looks like the build node is misconfigured: Unable to locate the Javac Compiler in: C:\java\jre6\..\lib\tools.jar If you have admin access you can set the job to use JDK 1.4.2_19 or whatever you like. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
