junit4 test runners
I'm doing something non-ant related, but I'm wondering if anyone has seen this problem here, as it's the closest to what I'm trying to do 1. I have some code that is a test runner for Junit3.8.x classes, it works. 2. I am trying to flip the ivy version to junit 4.8.2 something. 3. I rerun my test runner tests 4. I get sealing violations on dependent JARs from my own upstream projects Neither my JARs or JUnit4 is sealed, yet as soon as say JUnit 4, things stop working. Anyone else seen something like this? Or am I deep in a classloader hell of my own making? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: junit4 test runners
On 06/09/2011 11:58 AM, Steve Loughran wrote: I'm doing something non-ant related, but I'm wondering if anyone has seen this problem here, as it's the closest to what I'm trying to do 1. I have some code that is a test runner for Junit3.8.x classes, it works. 2. I am trying to flip the ivy version to junit 4.8.2 something. 3. I rerun my test runner tests 4. I get sealing violations on dependent JARs from my own upstream projects Neither my JARs or JUnit4 is sealed, yet as soon as say JUnit 4, things stop working. Anyone else seen something like this? Or am I deep in a classloader hell of my own making? -turns out one file in a package was sealed. What's interesting is that this triggered a problem only in junit4 builds, which makes me thing that the classloading was different. Perhaps a sealing violation only triggers if the first class is loaded from a sealed JAR, and rest from unsealed ones. Odd though -reverting to junit3 did fix it, even though ivy set the build up both times. - 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 27/10/10 18:34, Jesse Glick wrote: 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. good trick. All the places I've seen it do use getMessage() and would be brittle to change. I think for my short-term needs (translation of a parallel exec timeout into a more meaningful message) in funtest, I just need the error class. I just noticed that java was playing the same trick with exec, and again, classtype is all it needs. I'll look through the code to see where it looks for the toString() or getMessage() of buildexceptions (pause) Ant uses getMessage() primarily to extract some text from BuildException to use in a log or other exception. Kaffe and Gcjh search the message for the string failed with return code when execing their apps and deciding whether to rethrow the exceptions. This is a bit naughty, again there should be a separate exception from Execute which signals that execution failed which these tasks should look for -steve - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
class BuildTimeoutException extends BuildException
I'm thinking we need a specific class BuildTimeoutException that extends BuildException -Java.java looks for the specific error message Timeout: killed the sub-process in Exec.java to recognise a timeout, and doesn't even share the constant string across classes. -my own code looks for Parallel execution timed out in a test run and inserts a more meaningful message. I propose 1. a new BuildTimeoutException 2. Exec, Parallel and other things that can timeout raise it. 3. Calling code in the Ant codebase can look for this. 4. we leave the error strings alone for fear of #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. I'll do the coding... -Steve - 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 27/10/10 11:01, Steve Loughran wrote: I'm thinking we need a specific class BuildTimeoutException that extends BuildException I'll do the coding... Of course, there is a well documented exception of just that name in org.apache.tools.ant.taskdefs.optional.testing Which implies that I should really 1. move that into the core codebase 2. retain a subclass in that location, though that really confuses code: class BuildTimeoutException extends org.apache.tools.ant.BuildTimeoutException Better to have some new Exception name like BuildOperationTimeoutException to eliminate confusion - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: move-test fails on Windows7
Stefan Bodewig wrote: Hi, my work machine has been upgraded from XP to Win7 and now I get an error in test-move-caseonly: abc was not renamed aBc at line 31 , column 80 This is true for trunk as well as Ant 1.8.0. Does anybody else see this or is it something specific to my (still incomplete) environment? My only datapoint is using Java6 right now. I'd have expected that rename to fail on any of the windows platforms, as the existing name gets priority. So perhaps the check for windows (and special handling) is failing - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: And calling python
On 16/04/2010 00:56, Antoine Levy Lambert wrote: This would be more a user question. Anyway, ant can execute python with the exec/ task. What is hard is to return something to ant. Maybe if the python script prints out what ant needs to capture on systemout, then using the outputproperty attribute of the exec task, you can store the output of the python script. Another possibility would be to have the python script create a property file which would be read by ant after executing the python script. I'd look at jython and try doing this stuff in-JVM with script or the related tasks; this will make it easier to integrate with ant - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r901218 - in /ant/core/trunk: WHATSNEW src/main/org/apache/tools/ant/taskdefs/optional/ssh/Scp.java
Antoine Levy Lambert wrote: I think it is OK to commit bug fixes, but not OK to introduce new concepts. Just my 2cents. OK. I'll leave out the junit stuff as they are trying to be more robust against OOM errors, and they are trickier to test that they actually work without causing damage - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: svn commit: r894136 - /ant/sandbox/antlibs/git/trunk/src/main/org/apache/ant/git/AbstractGitTask.java
k...@apache.org wrote: + throw new BuildException(The repository [ + getGitRepo()+ ] specified is not recognised); + } A UK spelling of recognised is just going to lead to more bugreps, we need a phrase that is more locale-neutral - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE][RESULT] name for target-group
Antoine Levy Lambert wrote: I am thinking of building the first ant 1.8.0 release candidate tomorrow. I need to get my funtest docs together; won't be able to do it today in EU working hours. what is the timetable for getting doc patches into the release chain? - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Tentative 1.8.0 Release Proposal
Stefan Bodewig wrote: On 2009-12-18, Stefan Bodewig bode...@apache.org wrote: If I'd be the one to create the release, I'll need some help by Kev and/or Antoine to become able to compile the optional tasks with commercial dependencies. That being said, if Antoine wants to take things over, I'll happily let him do so. Even though Antoine shared all necessary jars with me, he'll take over as a release manager for this release because I'll be without a working JDK 1.4 installation for the next two weeks. I hope to be available for subsequent releases. * decide on a name for target-group: Dec 22 are we there yet? * build 1.8.0 RC1 and call for a vote on it: Dec 23 I'd better make sure all my funtest stuff is documented then, hadn't I - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: distribution of ivy with ant
Enis Soztutar wrote: I don't know if it is discussed previously but I was wondering why ivy is not included in the ant distribution. More and more projects previously depending on ant start to use ivy, but the build files are cluttered with ivy-download, check-ivy-antlib, etc. Technically ivy is a subproject of ant, and it can be used optionally. However if they are distributed together there will be several benefits: 1. Out-of-the-box support for dependency management for ant 2. Better integration of ivy with ant 3. No more check, download and load ivy targets in build files 4. Lowered entry barrier to using ivy for existing ant users 5. Exposure of ivy to more users the only drawback I can think of is the extra ivy jar file in the distribution. Is there any plans on the roadmap? Now that ivy is part of Ant, it makes sense to start thinking of bundling the two. However, it may tie the release cycle of the faster moving item (ivy) to that of the slower one. Do you think things have stabilised/slowed down enough for this? We can of course increase the release frequency of Ant... - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: ant 1.7. Finding undefined variables
Dominique Devienne wrote: On Wed, May 20, 2009 at 2:28 PM, Dave Pawson dave.paw...@gmail.com wrote: 2009/5/20 Dominique Devienne ddevie...@gmail.com: Yes, that's what I generate. Except I run through the properties file and the build file to ensure I get all the (used) properties! As apposed to what I remembered to put in (and didn't change). That's the problem I was addressing, those changes and the odd properties I'd forgotten to test using fail/ Maybe running in verbose or debug mode and grepping for all property related messages, especially those about not finding the property, and convert that into a build similarly to what you did? --DD A really ruthless trick would be to have a switch to say halt on an attempt to resolve an unresolved variable, giving you the trace of where things were when the situation was reached -or let you provide a list of unresolved variables to fail on. This would let you track down a problem without breaking the moment you hit the first echo statement with any undefined value in the printed message - 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
Peter Reilly wrote: 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. well, all the tools are one XSLT away from each other. TestNG has an extended format with for their non-compatible runs, with explicit skip flags, and I think every text can have a description - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Should I open a vote ? (Re: svn commit: r740252 - in /ant/ivy/updatesite/trunk/dist: ./ features/ plugins/)
Xavier Hanin wrote: On Sat, Feb 14, 2009 at 9:20 PM, Maarten Coene maarten_co...@yahoo.com wrote: Creating a 2.0.1 release is ok for me. I'm willing to create the release if no-one else volunteers... I've taken a quick look at the changes in JIRA, I think IVY-970 contains the biggest change, but I think we can include it in the new release (or is it too risky?) I agree, I've reviewed the changes too and I think they are all ok to be included in 2.0.1. IVY-970 is slightly bigger but only impact buildnumber, and after a quick code review I don't expect any major problem with it, so I'm fine to include it. And maybe we should also try to fix IVY-987 in the 2.0.1 release to improve our maven2 compatibility? Indeed, this bug is giving bad feeling about Ivy maven 2 compatibility. I should be able to find some time this week to investigate and hopefully find a fix. So if we all agree we could try to plan making a release in a week or so, if this match your planned availability Maarten. +1 for a release, there are things that have been fixed like handling the latest Xalan sha1; though that also implies a full beta test cycle just to make sure everything seems stable - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Anybody planning to attend ApacheCon in Amsterdam late March?
Stefan Bodewig wrote: On 2009-02-05, Jimmy Zhao junmingz...@gmail.com wrote: Personally, I think my talk is more like a workshop or tutorial, it might not so technical, but it would be interesting if people who want to know a new way to do testing -- via AntUnit. It may as well interesting to us who work on AntUnit to see hwo it is used outside of our little world of testing Ant tasks - and where you have found areas where AntUnit needs improverment for these other ideas. If possible, we would like to meet you there and hear your questions and ideas about how to make AntUnit better, and I will definitely like to contribute as best as I can. Looking forward to meething you and to your stronger involvement here. Stefan I will be there, one technical talk, one more, well, strategic. Not sorted out travel plans. If I make it to the hackathon I will probably be sitting on the hadoop table, though there are some needs there that I want to push back into ant, around junit work. when you are running jobs across a few hundred machines, your reporting needs change. -steve - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Integration of antunit in junit
Gilles Scokart wrote:
While testing ant tasks in my toy project (deco), I have used antunit.
It is very useful, but I found one limitation: I couldn't not run the
ant-unit tests in the junit runner of my ide.
ant-testutils.jar provides some support for that, but requires to
duplicate all antunit test target into java TestCase method. This is
a useless overhead now that we have most checks that can be done in
antunit.
An adaptation layer allow to see antunit test results directly with
the classical green/red bar of you junit runner. It also allow to
very easily plug a java debugger.
I already some code prepared to support this. The adaptation layer :
public class CompilePath extends TestCase {
public static TestSuite suite() {
File script = new
File(src/test/java/net/sourceforge/deco/ant/test-compilepath.xml);
return new AntUnitSuite(script);
}
}
When executed into a Junit Runner (for example in eclipse), we will
see a suite name test-compilepath that will have one test for each
testXXX target into my ant unit script.
+1.
I've done this before with other test systems, where you get the entire
list of tests from an XML file. Though some tools (like IDEs) get really
surprised when tests have spaces in their name
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: FileSet with copy fails with NPE..
Raja Nagendra Kumar wrote: Pl. find the fix for the same in ProjectComponent We are defining a GOBAL_DEFAULT_PROJECT which would be same as the first non null setProject call parameter. getProject() value on any tag if null, the non null GOBAL_DEFAULT_PROJECT value is assumed with debug log message saying about this assumption. No, this is lethal. This code encodes a static variable with the assumption that its ok to hold a long-lived project instance. Every IDE that uses Ant, everything else that embeds ant will come and tell us off. An NPE is a validity check to ensure that every task has an owning project. Not a friendly one, but one that certainly halts the app with a stack trace. Its something the developers get to see, usually the first time a task tries to log something. by the time the end users get to see it, it should have been fixed. That's the one nice thing about NPEs: they are hard to ignore. Tasks that create other tasks should bind them with bindToOwner(ProjectComponent). This ensures that not only is project picked up, the child task even picks up the same name in the logs. -steve - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] IvyDE 2.0.0.beta1 Release
Nicolas Lalevée wrote: I have built a release candidate for IvyDE 2.0.0.beta1 You can download the distribution from this URL: http://people.apache.org/~hibou/ivyde-2.0.0.beta1/ http://people.apache.org/%7E$LOGIN/ivyde-$VERSION/ And a staging update site has been setup there: http://people.apache.org/~hibou/staging/updatesite http://people.apache.org/%7E$LOGIN/staging-updatesite Do you vote for the release of these binaries? [ +1] Yes [ ] No - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: javac task problem in Java 6
Jesse Glick wrote: Jess Holle wrote: We've seen this before where A depends on B which /internally/ depends upon C and then suddenly one has to have C around to compile A. Although this is not forbidden by the JLS (as far as I know), it does seem undesirable. If you know of particular examples which can be expressed as minimal test cases, I would encourage you to file bug reports for the compiler. Not ever seen that. I have just been burned today by the fact that Java6 lets you do an @Overrides on any method that implements an interface; I'd been using that to indicate which methods were interface implementations. Java5 says @Overrides is only for non-abstract methods, hence breaks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Adopt Java 1.4 as a minimum requirement for core/trunk
Stefan Bodewig wrote: This is not that much based on features available (although I consider using NIO in StreamPumper) but more on where do we test. The vote is simple. If you vote +1 then we make 1.4 the minimum requirement, if you vote -1 it will stay at 1.3. This is a code change and thus subject to lazy consensus (i.e. no -1). +1 I'm ruthless, I'd vote for Java5 if you asked for that instead. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Where next: 1.7.2 or 1.8.0?
Stefan Bodewig wrote: Hi, the current trunk doesn't contain many big or risky changes, the biggest new things probably are the changed PropertyHelper[1], FileProvider and local properties. I seriously consider adding the changes made by the EasyAnt proposal. OTOH trunk contains a bunch of bug fixes that are not in 1.7.1, some of them serious. My personal query for open bugs outside of the SCM tasks currently contains about 170 bugzilla issues and I'd like to get that count down considerably before the next release. I guess I'm asking whether you feel it would be worth to make the extra effort of merging the bug fixes to te 1.7.x branch because we anticipate a 1.7.2. If so, I'd rather do it soon before the number of things to merge gets even bigger. Are there any defects so traumatic in Ant 1.7.1 that an urgent fix is needed? If not, then I'm -0 to a 1.7.2 release. Not just for the merge, but all the release overhead - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Compiling fails on JDK 1.3
Stefan Bodewig wrote: On Fri, 10 Oct 2008, Jan Materne [EMAIL PROTECTED] wrote: I tried a build on JDK 1.3/WinXP-SP2, but that failed. The constructor FileOutputStream(File, boolean) was added in JDK 1.4. Should be easy to fix, I'm just not sure whether it needs to be. http://ant.apache.org/faq.html#java-version only talks about Java 1.1 and 1.2. I think we decided to make 1.7 require Java 1.3 and trunk Java 1.4 or has 1.7 still been at 1.2 and we switched to Java 1.3 with trunk? Stefan Don't recall. Me, I'd go for Java 5+ on SVN_HEAD, because Java 5 has been out there so long that sun are going to remove support for some versions soon, and some of the language changes are pretty fundamental - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Ant @ CIServer TeamCity
[EMAIL PROTECTED] wrote: Nice integration. I like TeamCitys build agents. Has [EMAIL PROTECTED] some configured for different platforms (Linux, Windows)? Because of the integration with Jira: is that something for Ivy? Is there an integration with Bugzilla? We should move Ant over to Jira too, perhaps. It makes x-filing bugs between ivy and other projects better, and has a fairly good experience *Except over very slow networks*. 1. Yahoo! are working with infrastructure on some build farm. Hadoop is their line of business app and they care about it never failing a test. 2. We are bringing up hudson at work on a set of machines, real and virtual. I could get it to build ant too, but you wont get to see the results, just get the mail. So much mail. -OS/X only works if someone is logged on -some of the linux VMs experience clock drift; this really makes a mess of a release process. Amazon AWS Auth doesnt even want to talk to you if your clock is 8 hours out, so there goes some of our functional tests, for example. -- 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]
Re: Ant @ CIServer TeamCity
[EMAIL PROTECTED] wrote: Notifications by the CI server [1] are now send to [EMAIL PROTECTED] So you'll could get a little more traffic in the future. BTW - now I saw that Apache is hosting a Hudson [2] instance [3]. Jan [1] http://ant.apache.org/nightlies.html [2] https://hudson.dev.java.net/ [3] http://hudson.zones.apache.org/hudson/ Hudson is being used by Hadoop. Here is an example of it at work https://issues.apache.org/jira/browse/HADOOP-4325 when you submit a patch on jira, and mark it as patch available, hudson will check out and build the code, and reject it if -it doesnt build -it creates more findbugs or checkstyle warnings -any tests fail -it doesnt add or change existing tests so: no tests, no commit. Its a nice way of handling contribs from third parties; hudson rejects things until the patch is up to scratch, then the committers take over. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why is verifyjar undocumented?
Stefan Bodewig wrote: The task has been added in the 1.7 timeframe but I don't see it documented anywhere (some of our tests use it). Does anybody remember whether we didn't want people to know the task is there (see classloader) or just forgot to document it? Is that the task to check that a JAR is signed? if so, its because it doesnt work as advertised. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: DirectoryScanner performance
Kevin Jackson wrote: The tests are not through yet, but one thing was so surprising to me that I wanted to show it upfront: Running the matchall target (of sr/etc/performance/dirscanner.xml): Ant 1.6.5 1 min 30 s ~ 19 MB Ant 1.7.0 3 min 53 s ~ 24 MB Ant 1.7.1 10 s ~ 14 MB So 1.7.0 took more than twice as long as 1.6.5 to find all files in a big directory tree without any patterns and 1.7.1 is a whole lot faster than even 1.6.5. That's a huge difference - what are we doing now in 1.7.1 that is different from before? I think it tries to sort stuff less. This broke hadoop builds as their class structure was wrong https://issues.apache.org/jira/browse/HADOOP-3907 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ant and basedir
Dominique Devienne wrote:
On Fri, Aug 29, 2008 at 8:48 AM, Stefan Bodewig [EMAIL PROTECTED] wrote:
Now if only import would work the same ;-)
We disagree here.
Definitely. Just the fact that you documented the whole mess about
*ant*'s basedir nightmare is enough of a hint to me that not doing
the obvious is a mistake. Resolution relative to the current file, or
relative to what the current file explicitly says it should be, is
always tons better than via something you don't control. It's simply
more natural, the least surprising, etc... That's how HTML resolves
things, XSL, etc...
Writing ${basedir}/ in front of every location in
the imported file would be pretty tedious. IMHO it is far more common
that you want files resolved relative to basedir than relative to the
location of the imported file.
Builds always rely on tons a properties to this dir or that dir
anyway, and imported build files typically make assumptions about the
properties they depend on, to be set by the importer somehow.
But anyhow, I've lost this argument then, and sounds like I'm loosing
it now. It's too bad, as it's the simpler, least surprising behavior,
to always resolve relative to the current file. I'm 100% sure of that.
Saving a few keystrokes is a mistake if it goes away from the simple
choice. But 'nough said ;-)
One thing I think matters is that complex builds work under eclipse.
Right now if you build stuff with import it doesnt. I don't think this
is basedir related, but more the way import doesnt use it...
-steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release AntUnit 1.1 Beta 1
Stefan Bodewig wrote: On Wed, 27 Aug 2008, Stefan Bodewig [EMAIL PROTECTED] wrote: The vote runs for a week and needs 3 PMC member +1s to pass (and more +1s than -1s). Six days and two PMC member votes later. I'd appreciate it if any other PMC member could take a look at the proposed beta release. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] +1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Anybody familiar with ChoiceFormat? Issue 44659
Stefan Bodewig wrote: On Fri, 22 Aug 2008, Matt Benson [EMAIL PROTECTED] wrote: Looking back at this again, I think having the number formatted according to the US Locale would be more confusing than by the default Locale, speaking without the perspective of a person who typically uses e.g. . as a thousands separator and , as a decimal separator. I am one of those people and to me it is more confusing to have Ant use German number formatting but say minutes instead of Minuten. (well, would be since I haven't seen builds taking 1000 minutes myself). When copying files we don't use a number format at all and thus end up with a pure number without any separators at all. I wouldn't expect that too many builds take tens of thousands of minutes so a number with or without thousands separator may be as readable as the other in out case. AFAICT making the thousands separator go away takes the same amount of coding effort as making it use the US locale. I use a logger that tells me when the build finished; this is so that when I switch to different windows and back I can see if a build was recent or not. There's a good case for making the date/time info localised, if you want to do everything properly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: File Name wiht NLS Special Characters
Stefan Bodewig wrote: On Mon, 25 Aug 2008, [EMAIL PROTECTED] wrote: Folks, I'm trying to run the Jax-ws APT ant task on file with a NLS name: S_BASIC_ÃÑÑÖÏÑG_Bean.java I don't think you are asking on the correct list. There may be people on the user list who use the same task (I don't even know it) and can help. Since I don't know how the task is implemented, I can only guess. If you run Ant in verbose mode, does it give you any hint on how it invokes apt? Does it use a command line or does it invoke it via a Java API inside the Ant process? If the former is used, does the same command line work if you use it outside of Ant? The apt code in Ant uses javac style infocation; I don't know what the jax-ws APT task is, what it does, or who wrote it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Allowing antlibs to contribute diagnostics version info
Jeffrey E Care wrote: I haven't looked at the code in question, but I would think the hardest part of this whole effort would be providing the means for Ant to look up antlib version info. I'm actually fairly enthusiastic about using the combination of existing arguments, mostly just because of the number of requests I've seen for the proliferation of arguments to Ant. Surely one of the existing committers could hook that up if you don't want to tackle that part, Jeff... again, the rest is the tricky part IMHO! I'm using META-INF/services from the JAR spec, so the discovery is actually pretty easy so long as the Antlibs are available via the classloader that oata.launch.Launcher configures. Note that this approach does not need a project: it will discover anything that's available from the classloader. I already have a similar function working in the extensions we use to build WebSphere, so I've just been adapting that. I had to reverse engineer the ServiceLoader class from JDK 6, since I know that I can't depend on a JDK 6 runtime. I could have used sun.misc.Service, but I figured that would be problematic on opensource JDKs. You could also run through all antlibs defined in the root of the project, list which are there and diagnose them. Since they are the ones that matter if they are missing... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Trying (and failing) to build the nightly snapshot
EJ Ciramella wrote:
I think I misunderstood this particular bug. It appears to be a problem
with $${someprop} versus loading two property files and the first one
containing a ${property} that is set in the second one loaded.
To be explicit, if you have two property files, a.properties and
b.properties, in the first one loaded you have a ${property} that is set
in b.properties, ant leaves it as ${}.
a.properties:
foo=bar
coolprop=${foo}:${from.b.properties}
b.properties:
from.b.properties=awesome
build.xml:
project default=go
target name=go
property file=a.properties /
property file=b.properties /
echoThis is a problem: ${coolprop}/echo
/target
/project
You'll see this:
This is a problem: bar:${from.b.properties}
That's because property expansion takes place when the properties files
are loaded. If you want properties from b.properties, load it before
a.properties
--
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]
[Fwd: Ant 1.7.1 binary distribution seems to be corrupt.]
anyone seen this? I will try from the apache.org site Original Message Subject: Ant 1.7.1 binary distribution seems to be corrupt. Date: Fri, 1 Aug 2008 10:44:50 +0100 From: [EMAIL PROTECTED] Reply-To: Ant Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Tried downloading apache-ant-1.7.1-bin.zip and apache-ant-1.7.1-bin.tar.gz today, and extraction using jar xf and winzip failed. Checked the MD5, SHA1 and PGP signatures and they all failed. Tried a couple of mrirors (http://www.mirrorservice.org/sites/ftp.apache.org and http://mirrors.dedipower.com/ftp.apache.org) as well as the master distribution directory, and they all have the same problem. A colleague successfully installed these a couple of days ago, and another colleague confirmed the incorrect checksums I'm seeing on the current binaries. apache-ant-1.7.1-bin.zip: Apache MD5: f64c979dd593324fd1e58eea4d991522 I get (fsum): d03c4ad51b55a46f2a305beca5d586df Apache SH1: a7e8fa7bc2102a8d8df99c64db73c2eae3d8b483 I get (fsum): 73974e69c5dfddf5834a4bb03bb16c45ac9c When checking PGP sigs (using gnu-pg on windows): gpg: Signature made 06/27/08 07:50:34 using DSA key ID AA0077B0 gpg: BAD signature from Kev Jackson (apache key) [EMAIL PROTECTED] Not sure who else to inform about this... In the meantime, 1.7.0 is fine. Thanks, Dan Boswell ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___ -- 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]
Re: [Fwd: Ant 1.7.1 binary distribution seems to be corrupt.]
Steve Loughran wrote: anyone seen this? I will try from the apache.org site -everything is valid on the apache.or and eu.apache.org sites, so something is up at their end, not ours -- 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]
Re: Trying (and failing) to build the nightly snapshot
EJ Ciramella wrote:
I also tried to verify that bug 42277 was closed/fixed in the nightly
builds, but I see it's not.
String resources only have properties single expanded. If you relied on
string resources being expanded more than once, it no longer happens.
Bugzilla report 42277.
I havent tried to build the nightly for a few weeks. Normally gump would
warn of trouble, but it is held up with junit problems
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2008 9:48 AM
To: Ant Developers List
Subject: RE: Trying (and failing) to build the nightly snapshot
I'm not sure if I was supposed to do this or not, but I copied the
InterfaceMethodRefCPInfo.java file that comes in
/src/main/org/apache/tools/ant/taskdefs/optional/depend/constantpool to
ant/src/main/org/apache/tools/ant/taskdefs/optional/depend/constantpool
and it worked.
Is there any particular reason that ONE file is orphaned out there?
-Original Message-
From: EJ Ciramella [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2008 9:37 AM
To: dev@ant.apache.org
Subject: Trying (and failing) to build the nightly snapshot
Hey guys - I'm struggling to build the nightly snapshot and I'm sure
this is a /palmface type problem.
During compilation, I get this:
Compiling 296 source files to
E:\buildtools\ant-nightly\ant\build\classes
E:\buildtools\ant-nightly\ant\src\main\org\apache\tools\ant\taskdefs\opt
ional\depend\constantpool\ConstantPool.java:261: cannot find symbol
symbol : class InterfaceMethodRefCPInfo
location: class
org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPool
if (element instanceof InterfaceMethodRefCPInfo) {
^
E:\buildtools\ant-nightly\ant\src\main\org\apache\tools\ant\taskdefs\opt
ional\depend\constantpool\ConstantPool.java:262: cannot find symbol
symbol : class InterfaceMethodRefCPInfo
location: class
org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPool
InterfaceMethodRefCPInfo interfaceMethodRefEntry
^
E:\buildtools\ant-nightly\ant\src\main\org\apache\tools\ant\taskdefs\opt
ional\depend\constantpool\ConstantPool.java:263: cannot find symbol
symbol : class InterfaceMethodRefCPInfo
location: class
org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPool
= (InterfaceMethodRefCPInfo) element;
^
E:\buildtools\ant-nightly\ant\src\main\org\apache\tools\ant\taskdefs\opt
ional\depend\constantpool\ConstantPoolEntry.java:151: cannot find symbol
symbol : class InterfaceMethodRefCPInfo
location: class
org.apache.tools.ant.taskdefs.optional.depend.constantpool.ConstantPoolE
ntry
cpInfo = new InterfaceMethodRefCPInfo();
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
4 errors
From what I can tell, this class exists in the
optional.jar/ant-nodeps.jar (which doesn't exist because I haven't built
it yet). How do I get around this?
P.S. - the link to the nightly builds doesn't point to anything:
http://ant.apache.org/nightlies.html
http://people.apache.org/builds/ant/nightly/
-
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]
--
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]
Re: Maven Repo Stuff for ant 1.7.1
Stefan Bodewig wrote: Hi all, I followed our release instructions which say I need to copy the jars and poms generated by Ant's distribution target to /repo/m1-ibiblio-rsync-repository on people.a.o Does anybody who is more familiar than myself know whether this (1) still has the desired effect of getting the jars published (2) should be changed to a different way that included publishing to /repo/m2-ibiblio-rsync-repository instead? I think m1 stuff goes out; let's see what happens - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issue 45190 and Ant 1.7.1
Kevin Jackson wrote: Hi Stefan, I fixed https://issues.apache.org/bugzilla/show_bug.cgi?id=45190 with a rather trivial patch http://svn.apache.org/viewvc?view=revrevision=668624 and now the reporter asks whether this could go into 1.7.1. While I understand that he needs the bug fixed, I also wouldn't want to cause any delay of the 1.7.1 release. Kev, would you accept the patch into the 1.7 branch and go ahead with the release or would it slow you down if it got merged? If I accepted this, would I need to re-issue a beta and wait the required time for people to retest before starting the release process? I'm more ruthless here, I'd stick it out and say 1.7.2. Otherwise more bugs come in and get patched in late. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: get timeout patch
Joshua Moore wrote: Hi, For my work I needed to added a timeout option for the ant get task. So I modified the existing Get.java to add the timeout option. I wanted to share this with the ant community so I am including a patch that has my changes (made against the 1.7.0 source code). To use simply add the timeout=# to the get tag (# is the number of seconds before the get operation it timed out). I hope this is useful. Josh, I'm afraid the patch got pulled. Please can you go to issues.apache.org and file it under bugzilla Is the timeout a java1.5+ feature, or does it work on java1.4 and below? -- 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]
Re: Adding magic properties for targets?
Dominique Devienne wrote:
I'd add that those properties, if made available, should probably be
prefixed with ant., to make it clear they are built-in. Perhaps:
ant.default-target
ant.targets-invoked
I'm +0 on adding these static properties.
Since we're at it, we may also want to expose ant.current-target and
ant.invoked-target properties, but these are dynamic since changing
during the course of the build, so more problematic given the property
immutability rules. Exposing them via a PropertyHelper to made it
clear they are dynamic perhaps? ${dynamic:ant.current-target}...
That could be very good. I'm happier with that than using something that
looks like an existing property and could easily stamp on existing
properties
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Adding magic properties for targets?
James Fuller wrote: wouldn't it be great if property names were qnames and then we could do ant:default-target ant:targets-invoked though I do not think the default namespace e.g. antlib:org.apache.tools.ant is wholly appropriate as it concerns itself with ant libraries. I know ant doesn't fully subscribe to all things xml ... but there maybe benefits to not reinventing things. No, QNames are (a) evil (b) not part of XML; they ar part of the W3C XML Schema. I've just noticed the that Open Grid Forum's Open Grid Services Architecture mailing list has just discovered that very fact only weeks before their WS-ResourceFramework Basic Profile 1.0 was about to be announced (I'm on some very obscure mailing lists)...I think I pointed that out to them years back. Here's the basic problem, and it exists in XPath too: you cannot evaluate the prefix to namespace URI mapping without building and maintaining the entire context of namespace declarations. And you get a new error type -unknown prefix- that is not needed. That is, it would be better to pass around things like qnamehttp://example.org#enameqname Or even qnameurihttp://example.org/urilocalnameenamelocalnameqname than it would be to have qnameexample:ename/qname because you can only evaluate element within the context of the original scope. Now imagine the qname task takes a property and sets it to the expanded http://example.org#ename string, and use it in a presetdef target xmlns:example=http://ant.apache.org/ presetdef name=eval qnameexample:ename/qname /presetdef /target and then I run it here target xmlns:example=http://somethingelse; eval property=evaluated / /target What gets expanded? Or we run it here, where the namespace is entirely undefined: target eval property=evaluated / /target See? QNames are evil. I had lunch with the W3C TAG last week, primarily to give them a hard time over releasing WS-Addressing without a single test case(*). I guess I should have raised QNames at the same time. -Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tiny patch to enable Recursion in Ant
Stefan Bodewig wrote: sorry for the delay, a combination of a whole lot of work, a broken iBook, very nice weather and severe back pain (not necessarily in that order) have kept me offline. On Wed, 14 May 2008, Colm Smyth [EMAIL PROTECTED] wrote: Yes I used subant, but as I said, it can't recurse on the current target. Since recursion should be a core function of a hierarchical build system, I think this patch is worth adding to Ant. First of all your original mail didn't contain the patch itself. Second you said you used ant-contrib's for and I pointed out that subant should be enough. The only thing that's missing is a property that knows the current target, isn't it? I know we have rejected the idea of such a property in the past, but we may be at a different point today, so if you open an enhancement request for such a property (or find the old one and reopen it), that would e the right place to attach a patch to enable it. I could imagine a task to set a property to the current target location target=targetproperty buildfile=fileproperty / ...maybe even something for a complete stack trace/list of imports that is live -- 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]
Re: [Vote] 1.7.1beta2
Kevin Jackson wrote: Hi, I've been informed (on the q.t) that I never actually requested a vote before announcing that the ant 1.7.1 beta tarballs were available. So officially at the moment, the tarballs on people.apache.org that I announced are beta-in-potentia :( A retrospective vote on these tarballs has been proposed, so Available tarballs at http://people.apache.org/dist/ant/v1.7.1beta2/ are ready: yes [ x ] (+1) no [ ] (-1) my vote yes [ x ] (+1) no [ ] (-1) -- 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]
handling of malformed zip/tar/bzip files
There's now a test suite of fuzzed archive files to run past decompression tools, to see how they handle it https://www.cert.fi/haavoittuvuudet/joint-advisory-archive-formats.html We may not be vulnerable to buffer overflows, but we should still test for bad files and reject them. -- 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]
Re: Ivy Maven 2 Compatibility
Gilles Scokart wrote: Cool, I think we should share those errors with the maven team. They usually don't accept to patch meta-data, but when it is invalid XML I think they would accept. Posted to the repository mailing list already. Apparently the oslash; thing was a hack done to m2 to support someone's name...very very naughty; they must predefine the abbreviation before parsing. From Gilles Scokart's reply: See also http://markmail.org/message/qujfp3uo7rhokhrb And http://markmail.org/message/sbouq623fdlujmzt (quoted from Brett) - I switched to StAX in the process. This is likely going to introduce some small quirks we need to iron out (like the hack I added to parse Trygve's name - why did we ever allow that!) -- 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]
anyone seen ftp failing?
For some reason, I can't reliably ftp up to upload.sourceforge.net from a CentOS VM I've set up for builds. I can upload one file, but then it stops release.ftp-upload: [echo] FTP target is upload.sourceforge.net [ftp] Opening FTP connection to upload.sourceforge.net [ftp] connected [ftp] logging in to FTP server [ftp] login succeeded [ftp] disconnecting [ftp] Opening FTP connection to upload.sourceforge.net [ftp] connected [ftp] logging in to FTP server [ftp] login succeeded [ftp] changing the remote directory [ftp] sending files [ftp] transferring /home/smartfrog/Projects/SmartFrog/core/release/build/upload/smartfrog-3.12.026-source.zip [ftp] disconnecting == Exiting failing project release == BUILD FAILED - at 3/14/08 10:04 AM /home/smartfrog/Projects/SmartFrog/core/release/build.xml:929: could not put file: 425 Failed to establish connection. Anyone seen this? From my main machine's command line I can do it, and I get 1MB/s bandwidth so connectivity is fine. And as I'm late with the release I dont want to fiddle around with it right now -so I am doing the hand upload...but I dont want to repeat it. Maybe its the VMWare virtual adapters for CentOS; I will try with its predecessor xubuntu vm instead. Otherwise, we ought to think about better diagnostics for the FTP task. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Ant 1.7.1 beta
Kevin Jackson wrote: Hi all, I think it's time to go ahead and push out 1.7.1 for wider testing. I really *don't* want to add any changes to code at the moment, but if there are any documentation issues that someone notices I'm willing to let them in on a case by case basis Over to the vote: 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 dont know how to do the PGP signing, but I can learn with you Yes, go ahead but I won't help [ ] (+0) No, it's not ready [ ] (-1) Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: Hackathon in Amsterdam next months?
Stefan Bodewig wrote: Hi, this year I'll only attend the Hackathon but not be around during the actual ApacheCon in Amsterdam. Is anybody else going to be there Monday or Tuesday as well? I intend to take some time to finally look into Xaviers EasyAnt prototype. - yes, I'm going, probably arriving late monday. I think my family will be attending, which will get in the way of laptop time. -I'm not talking, though I was just trying to get a keynote. HP is a sponsor this year, but didnt ask for a keynote until I heard about it, by which time it was too late. So no cool demos of deploying things onto Amazon EC2 using google talk as the communications layer during the half-hour in the morning when everyone checks their email -- 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]
Re: Hackathon in Amsterdam next months?
Petar Tahchiev wrote: Hi guys, I will (probably) attend the whole conference, too. Steve,I would like to meet you - I will (probably) be around the HP booth. That would be cool; I will be manning the booth at some point in the week, no doubt. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [DISCUSS] Ivy 2.0.0-beta2 announcement
Xavier Hanin wrote: Here is the announcement I plan to post when Ivy 2 beta2 will be available publicly. Anything to change? ---8- Mar 4 2008 - The Apache Ivy project is please to announce its 2.0.0 beta 2 release, a new step on the road toward 2.0 final. Ivy is a tool for managing (recording, tracking, resolving and reporting) project dependencies, characterized by flexibility, configurability, and tight integration with Apache Ant. The status of this version is a beta, meaning that we encourage users to try it out. This version is already providing a good stability and robustness. API and features are still subject to change though. Change to This is a beta release, for wide testing with users. Problems found at this phase can be fixed in the final release, so now is a good time to download and use it. Although there may be some changes at the API level, it is already being in production builds in many large Java projects. As -you want to give people a big reason to test now (get your bugs fixed) -reassure it is in use. Certainly we use the alphas at work. -- 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]
Re: AW: Tasks in parallel
[EMAIL PROTECTED] wrote: Consider the scenario where the file transfer takes a long time: would it be a good idea to have the copy/scp/ftp tasks create different threads for each file? There is no built-in support for anything like this in Ant, no. I could imagine that we'd add a patch that enabled optional (on user-demand) parallel behavior for these tasks. Personally I see the point for the network transfer kind of tasks, but wouldn't want it on copy, but that may be my experience with a very slow disk in my notebook. At first step for improving performance I would think about skipping things. Why to try to upload a lot of files which havent changed and are already there? In that case: scpfilesetmodified exec rsync. rsync is a fantastic way of upload directory trees full of content. Its not enough to upload separate files in separate threads, or even upload changed files, you only want to upload the changed bits of the changed files. -- 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]
Re: Ivy settings ant error
Xavier Hanin wrote: Hi, In latest Ivy version we have changed the way to load settings, using a task instead of a datatype, but still using an id attribute. The code of the task is available here: https://svn.apache.org/repos/asf/ant/ivy/core/trunk/src/java/org/apache/ivy/ant/IvyAntSettings.java A user is complaining (see forwarded e-mail) about a warning message from Ant: Warning: Reference ivy.instance 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. Any idea what can be wrong? Is it related to our implementation of the settings task? Any help from Ant gurus would be welcome :-) It means they define the ivy.instance type or whatever in a target that has not been executed; it is not in the dependency graph. Ant finds the definition anyway, then tells you off for being naughty -- 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]
Re: 1.7.1 - Beta Vote
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. -- 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]
Re: 1.7.1 - Beta Vote
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.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.7.1 - Beta Vote
Peter Reilly wrote:
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.
the bug has been around since 1.7.alpha; 2007-04
in 1.7.0 the failure is as follows:
\\PC03\jclasses\lib\ant-1.7.0.jar
on the classpath.
Ant is failing while trying to create the URI of the file
java.lang.IllegalArgumentException: URI has an authority component
at java.io.File.init(Unknown Source)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown
Source)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at org.apache.tools.ant.launch.Locator.fromURI(Locator.java:165)
at
org.apache.tools.ant.launch.Locator.getResourceSource(Locator.java:119)
at
org.apache.tools.ant.launch.Locator.getClassSource(Locator.java:90)
at org.apache.tools.ant.Project.setAntLib(Project.java:313)
at org.apache.tools.ant.Project.initProperties(Project.java:309)
at org.apache.tools.ant.Project.init(Project.java:295)
at org.apache.tools.ant.Main.runBuild(Main.java:663)
at org.apache.tools.ant.Main.startAnt(Main.java:199)
at org.apache.tools.ant.Main.start(Main.java:161)
at org.apache.tools.ant.Main.main(Main.java:250)
We thought we'd fixed it, by switching to the java1.3 URI stuff
everywhere, indeed, 1.7.1 marks it as fixed
* Regression in Locator: running Ant off a network share does not work:
message URI has authority component appears
Bugzilla report 42275
but we just found a bug this one was hiding; we've moved the problem.
I have just fixed it incidentally, and added a new secret launch
diagnostics feature to ant that turns detailed logging in the launcher on:
C:\\\morzine\slo\Java\Apache\ant\bin\ant.bat --launchdiag
Launcher JAR= \\morzine\slo\Java\Apache\ant\lib\ant-launcher.jar
java.home= C:\Java\jre
Launcher JAR directory= \\morzine\slo\Java\Apache\ant\lib
setting ant.library.dir to \\morzine\slo\Java\Apache\ant\lib
Unable to locate tools.jar. Expected to find it in C:\Java\lib\tools.jar
tools.jar= null
setting java.class.path to
\\morzine\slo\Java\Apache\ant\bin\..\lib\ant-laun
her.jar;\\morzine\slo\Java\Apache\ant\lib\ant.jar;\\morzine\slo\Java\Apache\ant
lib\xml-apis.jar;\\morzine\slo\Java\Apache\ant\lib\log4j-1.2.13.jar;\\morzine\s
o\Java\Apache\ant\lib\commons-logging-1.0.4.jar;\\morzine\slo\Java\Apache\ant\l
b\commons-logging-1.1.jar;\\morzine\slo\Java\Apache\ant\lib\xercesImpl.jar;\\mo
zine\slo\Java\Apache\ant\lib\jython-2.1.jar;\\morzine\slo\Java\Apache\ant\lib\j
uby-0.8.3.jar;\\morzine\slo\Java\Apache\ant\lib\resolver.jar;\\morzine\slo\Java
Apache\ant\lib\cpptasks.jar;\\morzine\slo\Java\Apache\ant\lib\ant-commons-net.j
r;\\morzine\slo\Java\Apache\ant\lib\junit-3.8.2.jar;\\morzine\slo\Java\Apache\a
t\lib\activation-1.0.2.jar;\\morzine\slo\Java\Apache\ant\lib\ant-junit.jar;\\mo
zine\slo\Java\Apache\ant\lib\ant-testutil.jar;\\morzine\slo\Java\Apache\ant\lib
ant-apache-regexp.jar;\\morzine\slo\Java\Apache\ant\lib\jakarta-regexp-1.2.jar;
\morzine\slo\Java\Apache\ant\lib\commons-net-1.4.0.jar;\\morzine\slo\Java\Apach
\ant\lib\jsvn-0.9-dev.jar;\\morzine\slo\Java\Apache\ant\lib\logkit-1.0.1.jar;\\
orzine\slo\Java\Apache\ant\lib\ant-apache-bsf.jar;\\morzine\slo\Java\Apache\ant
lib\ant-antlr.jar;\\morzine\slo\Java\Apache\ant\lib\ant-swing.jar;\\morzine\slo
Java\Apache\ant\lib\xml-resolver-1.1.jar;\\morzine\slo\Java\Apache\ant\lib
Re: Set up folder permission in Windows with Ant
lawardy wrote: Hi, I'm a new user of ant. I am trying to set up a folder and need to set up certain permission on it (read, write and execute permission)Is it possible to do with ant? Any idea of how to do that. 1. this is the kind of question for the ant users list 2. Windows? it doesnt have that usable a permissions model. You need to edit ACLs, which you can do by exec-ing CACLS: cacls /? Displays or modifies access control lists (ACLs) of files CACLS filename [/T] [/E] [/C] [/G user:perm] [/R user [...]] [/P user:perm [...]] [/D user [...]] filename Displays ACLs. /TChanges ACLs of specified files in the current directory and all subdirectories. /EEdit ACL instead of replacing it. /CContinue on access denied errors. /G user:perm Grant specified user access rights. Perm can be: R Read W Write C Change (write) F Full control /R user Revoke specified user's access rights (only valid with /E). /P user:perm Replace specified user's access rights. Perm can be: N None R Read W Write C Change (write) F Full control /D user Deny specified user access. Wildcards can be used to specify more that one file in a command. You can specify more than one user in a command. Abbreviations: CI - Container Inherit. The ACE will be inherited by directories. OI - Object Inherit. The ACE will be inherited by files. IO - Inherit Only. The ACE does not apply to the current file/directory. I would advise you avoid it unless you know what you are going. To create zip/tar files with permissions, use zipfileset and tarfileset filesets with explicitly listed permssions. -- 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]
Re: The Cactus/JUnit-Task problem
Stefan Bodewig wrote: Hi all, [Petar, it would be good if you subscribed to [EMAIL PROTECTED], it is not that high traffic anyway] last night I chatted with Petar about the backwards incompatible change to the JUnit task we introduced in Ant 1.7.0 that broke Cactus. Cactus' Ant task extends the JUnit task (and if memory serves me right is one of the reasons that a bunch of methods in JUnitTask have protected access in the first place). It used to override execute() completely and invoke the execute variants that acceps tests or lists of tests (I don't recall which). This doesn't work any longer since execute() performs setup work on the delegate that decouples Ant from the junit library and the execute variants rely on this setup. On my way home I thought that maybe the easiest solution would be to have the execute variants check whether the setup has been performed and if not - simply do it themselves. The appended patch does just that and I'd like to get some feedback. The patch would make deleteClassloader protected so that subclasses can cleanup themselves, this may not strictly be necessary. With this patch in place, Cactus should be able to use Ant without any modifications, but could benefit from more control over resource cleanup if it wants to. BTW, I'd love to merge whatever solution we agree on to the 1.7 branch and have it go into 1.7.1. Right now Cactus users are forced to stick to 1.6.5 and we should change that. +1 Of course Petar should make sure that Gump can build Cactus so that he can hit us if we break it again. 8-) +2 -- 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]
Re: Cactus 1.8 / Ant 1.8 Integration
Petar Tahchiev wrote:
Sorry for the formating :-(.
Hi guys,
it's Petar Tahchiev from the Jakarta Cactus Team (again :-)).
I am trying to integrate the CactusTask with Ant 1.8-alpha.
The CactusTask does:
0) Extends the JUnitTask from Ant.
1) Gets all the tests from JUnitTask
2) Iterates over them and sets different properties to each one of them.
3) Calls the JUnitTask to executes the test-cases.
So, the basis is that we are no longer able to use
execute(org.apache.tools.ant.taskdefs.optional.junit.JUnitTest);
because the delegate field (Object of type JUnitTaskMirror) leaves
uninitialized and thus the CactusTask throws NLPE.
This way to execute the tests we are bound to use the execute() method of
the
JUnitTask (because in that method the delegate object gets initialized).
When calling
the execute() method we have to have our tests configured. But when I get
the tests and configure them with:
===
Enumeration tests = getIndividualTests();
while (tests.hasMoreElements())
{
JUnitTest test = (JUnitTest) tests.nextElement();
if (test.shouldRun(getProject())
!theWrapper.isExcluded(test.getName()))
{
test.setFork(true);
if (theWrapper.getToDir() != null)
{
test.setTodir(theWrapper.getToDir());
}
===
I am no longer able to set them in the JUnitTask. The field tests is
private:
private Vector tests = new Vector();
and there is no setter for an individual test, or a vector of tests.
Please, can you look serious to this and supply a setter method for this.
This way I can configure
the tests and set them in the JUnitTask, and after that just call execute().
So all you want is a setTests(Vector) method? or an addTest(JUnitTest)
method that adds a new test?
--
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]
Re: AW: ant java versions
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. -- 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]
Re: ClasspathUtils with or vs. JavaResource
jonathan doklovic wrote: Hey, I've been working on refactoring some code to make it easier to implement relative resources in things like the import task. After looking at BaseDef and AntLibDefinition, it seemed that it was a bit backwards and AntlibDefinition should actually extend a base class that provides basic classpath lookups. In trying to do this refactoring, I realized that all of this stuff was just using ClasspathUtils and not using JavaResource or ClasspathResource so I figured the refactoring should include this update as well. However, after digging in, it seems to get very complex... ClasspathUtils (and it's Delegate) does a lot of work to figure out the classloader and reuse one if it can. To do this, there's a bunch of delegate calls that get made and eventually the calling task takes the class loader returned by the delegate and loads the resource (unless it's a file, then it just loads it). With a ClasspathResource, you basically give it the path and the resource name, and it does it's own simpler checks to figure out and reuse the classloader and you can tell it to load the resource. However, you cannot get a reference to the classloader used. My question is, should these be used together? It seems a little overkill to do all the steps required in ClasspathUtils just to get the path for the resource to then in turn pass it to a ClasspathResource which is going to use it's own classloader anyway. There's got to be a cleaner way to do this, i'm just not sure if ClasspathUtils should be updated to return/use ClasspathResources, or if the ClasspathResource should get a little smarter to bypass the utils class alltogether. any thoughts? - Jonathan the two goals of ant's classpath work are (a) reuse stuff so that you can share data properly (b) not leak like a leaky-sieve, and so cause IDEs or app servers to run out of memory The classpath stuff does achieve both, but I'd have to look at all of this to see what is going on. You are clearly provoking us into a code review -- 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]
moving to Jira
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 -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]
ant java versions
this is a silly question, but I have forgotten the current values 1. What is the minimum version of Ant that 1.7.0 supports? 2. What is the minimum version of Ant that 1.8 is targeting? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: ant java versions
[EMAIL PROTECTED] wrote: this is a silly question, but I have forgotten the current values 1. What is the minimum version of Ant that 1.7.0 supports? In theory the answer is 1.2, but I doubt that anybody really still has an environment to try that. 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? -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: ant java versions
[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. But if I remember right without any success. What is the newest JDK version on our supported platforms? Java 6.0u4 on windows/linux, mac still trailing. The 6.04 release changed bits of the XML APIs, which was very unusual for a point release, to say the least. -- 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]
Re: svn commit: r612091 - /ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java
[EMAIL PROTECTED] wrote: Author: jhm Date: Tue Jan 15 04:06:19 2008 New Revision: 612091 URL: http://svn.apache.org/viewvc?rev=612091view=rev Log: - spelling - a sentence was incomplete (missing additional docs?) Modified: ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java Modified: ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java URL: http://svn.apache.org/viewvc/ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java?rev=612091r1=612090r2=612091view=diff == --- ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java (original) +++ ant/core/trunk/src/main/org/apache/tools/ant/types/resources/AbstractClasspathResource.java Tue Jan 15 04:06:19 2008 @@ -26,8 +26,8 @@ I mustnt have saved the copy open in jedit...thanks for catching this - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant Documentation
Matt Benson wrote: You can also read about the gendoc sandbox Antlib at http://ant.apache.org/antlibs/sandbox.html . For some reason this has been in the sandbox over 2.5 years. I don't know where the time has gone... we use this @work to generate docs for libraries other than Ant itself...it would be nice to be able to generate docs of ant tasks that work outside ant's own manual At work I'd be happy with java1.5+ annotations for this...for java1.4 and below we could use whatever testng does to get the tags from javadocs. Regarding docbook, I would be -1 to writing our docs themselves in docbook, +1 for some format that could be turned into docbook. Why? because docbook is pretty low level. You may have an emphasis section rather than i or b, but you would be better off with project-specific XML clauses/or at least div/span IDs, e,g span id=taskname /, div id=antxml /, so that you can choose better formatting from XML. For docbook I've used the xml toolchain that goes through LateX; printed output is very nice. -- 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]
Re: Linking to log files from generated JUnit reports
s p wrote: Hi, I'm am currently working on a patch for Ant 1.7 which would enable linking to logfiles from generated JUnit reports. The logfiles that are linked to would be logfiles generated by the application that is tested through JUnit supported Unit/Integration tests. To be able to do this I am adding a 'logdir' attribute to the junitreport task which specifies a root directory for logfiles. In the junit-frames.xsl, when generating the class.details, when a logfile matching the name of the classfile is found, a link will appear in the same way links will appear when there has been output to stdout or stderr when running the test. Will any of you be interested in this patch ? It would be great if this could be included in the Ant head branch. But if it won't we should consider not adapting the junitreport target but rather use our own stylesheet to override the one junitreport uses by default. Interesting thought. If you look at http://wiki.apache.org/ant/Proposals/EnhancedTestReports you can see what I'm thinking of in terms of improvements to the junit XML. I wouldnt want to see explicit support for logs, because there are so many other things to add to test runs as attachments/links. the output of a program should be something you can just get at. that said, logs are interesting as you may want a test run that grabs output at more detail than classic stdout/stderr, but instead use the full log4j/commons-logging/java.util.logging levels and have that handled in the main GUI, which means we could consider better logging inside the XML file itself -as long as that doesnt break other systems. I'd like more people involvved in this; add your name to the list and let's start making progress on it! -- 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]
Re: Updating information on current external task
Bytes Looser wrote: Hi, I am the maintainer of an external task, idldepend, useful for Corba projects. I published the task in 2002, and submitted it to this list using a mail address that I do not access anymore (and the address itself is lost now). This has not been a problem for the time being, as I included my new mail addresses in my homepage, at http://grasia.fdi.ucm.es/~luismi/idldepend However, this site has been down for a while, and I cannot control when it will be up and running again, so I have created a new website, at http://www.byteslooser.com/idldepend I would like, therefore, to update the information related to this task, to point to that web address and including my mail [EMAIL PROTECTED] I guess there will be some problem to update it like this, not being able to answer to the original mail address?? no, we trust you. Whoever keeps the source up to date gets the links. I've just checked in the changes...when the site is rebuilt the changes go out. -speaking of which, how do I rebuild the site? -- 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]
getting JVM version info from Ant
Here's a question. How do I distinguish a sun jvm from a jrockit jvm in a build file, as I dont see any reliable way of doing it in an ant condition (right now)? I'm thinking we ought to analyse the jvm and maybe set some properties, or add a new jvmversion condition to probe the world. -steve (I have some tests that fail on JRockit as it handles tail recursion differently; a test that would normally stack overflow spins until 4GB of heap runs out, which can take a long time. I'd rather detect jrockit and skip it, but the only test I have uses contains on the bootpath and hopes that jrockit is only installed in a path with that in it - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getting JVM version info from Ant
Peter Arrenbrecht wrote:
Maybe this helps:
target name=@check-jre1.5
condition property=is.jre15
and
equals arg1=Sun Microsystems Inc.
arg2=${java.vendor} /
contains substring=1.5.0
string=${java.runtime.version} /
/and
/condition
fail message=Distributions must be built with Sun JDK 1.5.0.
Aborting. unless=is.jre15 /
/target
I hadnt seen the java.runtime.version string; that's all we need. unless
we want specific isSun, isGPL tests
--
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]
Re: [VOTE] Release Ivy 2.0.0-beta1 (second attempt)
Xavier Hanin wrote: I have built a new release candidate for Ivy 2.0.0-beta1 You can download it from this URL: http://people.apache.org/~xavier/ivy/staging/2.0.0-beta1/ http://people.apache.org/%7Exavier/ivy/staging/2.0.0-beta1/ and the m2 repository is here: http://people.apache.org/~xavier/m2-staging-repo/http://people.apache.org/%7Exavier/m2-staging-repo/ Compared to the previous release attempt I've only the following changes (which can be tracked in svn in the 2.0.0-beta1 branch): - merged a fix on cache locking (disabled by default) - merged some changes in makepom task to address Gilles remark - fix a bug on a unit test of makepom not done on trunk (still need to be merged to trunk) - reflect change to makepomin build-release.xml - package readme with all ditribs (including crypto notice) - put maven 2 distrib in a m2 staging repo for ease of testing I haven't done much testing of these artifacts, I had some slight troubles getting in my way (but when it takes 10 min to make a full release build a slight error can make you loose a lot of time), and it's getting really late over here, but I don't expect to have any more time for a new release attempt until next week, so if ever this one doesn't pass, I hope someone will step up to replace me as release mgr for this release. So, do you vote for the release of these binaries? my vote: [+1 ] Yes [ ] No -- 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]
Re: ApacheCon Presentation
Xavier Hanin wrote:
Here's what we do in Ivy build to use emma (this is just an example):
ivy:cachepath organisation=emma module=emma revision=2.0.5312
inline=true conf=default pathid=emma.classpath
/
ivy:cachepath organisation=emma module=emma_ant revision=
2.0.5312
inline=true conf=default pathid=
emma.ant.classpath transitive=false /
taskdef resource=emma_ant.properties
classpath refid=emma.classpath /
classpath refid=emma.ant.classpath /
/taskdef
With cleaner metadata using only one ivy:cachepath would be enough. Without
Ivy, you can simply use a get task and build a path from the downloaded jar.
That's what we suggest to do to install Ivy itself if you want to use
clean Ant install (since using Ivy for that is obviously not an option :-)).
Right now we are half way to something that works. With an xml
namespace, you can autoload third party tasks. But those tasks need to
be in the classpath or specified with a lib argument.
I could imagine
-an ivy:typedef command that integrates retrieval/classpath setup with
type definitions.
Easy to do, no changes to Ant
-the ability to declare in a build file what the resolver setup is; a
component that is given the problem of resolving antlib URLs.
We'd need changes to Ant to delegate to any defined resolver, then have
a task like ivy:resolver ivyconf=${root.dir}/ivyconf.xml /; this
would plug in a new resolver, if none was already live (if it was, tough).
You could maybe define one on the command line too, one that could be
driven by ant properties:
ant -resolver org.eclipse.eclipseresolver
-Dorg.eclipse.eclipseresolver.osgiurl=http://eclipse.org
This is something we could think of for Ant1.8
however, before we do this, we also have to address the security issue.
All artifacts need to come with authenticated checksums. That is either
separate (signed) MD5 sums, or we serve all MD5 sums up from an apache
https server. without either of those, there is no way to detect
malicious artifacts sneaking in. In this respect, the java world is
actually behind, say the debian apt-get world.
-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]
Re: Update [was Re: weblogic rmic]
Kev Jackson wrote: Since this problem seems to have been around for 6+ years now, I vote that we switch off these unit tests and move on. [Vote] WebLogic Rmic tool sucks so: [X] enough already, we need ant 1.7.1 released regardless of crappy 3rd party tools that have never worked properly (update docs to point out weblogic rmic glaring incompatibilities with ant, switch off the unit test to get a clean build) [ ] no lets bang our heads against a brick wall for a few more years trying to fix this junk -- 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]
Re: J2ee Build
amalorpavadoss wrote: Hi, if I want to build a J2EE program what should be correct one to use, it is NAnt or Ant... please let me konw ant, and all further questions should be on the user mail list. -- 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]
Re: terminating running builds better
Darin Swanson wrote: Eclipse is pretty similar to #1. We have a progress monitor / build listener within which we check to see if the user has requested to cancel the build. If the monitor is cancelled we throw a OperationCancelledException which halts the execution of the build from the Eclipse entry point and reports the cancelled message to the user. Darins http://www.runnerwhocodes.blogspot.com/ well, I'll do the same thing. Now I know it works. Ant-wise, we could create an interruptable logger that lets you do this formally; the main reason for doing so would be to add tests for it. This is clearly an important use case. Jesse Glick [EMAIL PROTECTED] Sent by: news [EMAIL PROTECTED] 11/03/2007 01:19 PM Please respond to Ant Developers List dev@ant.apache.org To dev@ant.apache.org cc Subject Re: terminating running builds better Steve Loughran wrote: What do IDEs do to stop ant builds? just kill the thread/process? NB behaves as follows: 1. It sets a special flag. The next time any BuildListener/BuildLogger method is called on the IDE's listener, it will throw a BuildException, which usually stops the build. 2. If several seconds have elapsed with no listener method, or if the build did not stop for any other reason, Thread.stop is called. For example, if java fork=true is the active task, any output printed will cause #1 to be triggered. Otherwise, ThreadDeath is caught by the task, which stops the external process and then rethrows. Not perfect but seems to work reasonably well in practice. #2 could probably be improved to first try Thread.interrupt and only use Thread.stop as a last resort. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Optional target support?
Jeffrey E Care wrote: Peter Reilly [EMAIL PROTECTED] wrote on 11/02/2007 02:54:38 PM: The easy way is to have a common.xml that is included in by each subproject. The common.xml would have a foo target with an empty implementation. target name=foo/ Any sub project could then have there own foo target that would override the imported one. Thanks Peter. That occurred to me as well; unfortunately, I can't sell retrofitting hundreds of build.xml files in order to make this optional target stuff happen. Going forward you're absolutely right: all the subprojects should be using a common import we plan to do that in a future release; the main issue is that these subprojects predate import support the sheer volume of them means that a retrofitting effort will take too long and introduce too much risk to an effort that the bosses want done yesterday... you cant control common import files once you also include third party projects into your build tree and use ivy to choreograph it. For the new executor I'm doing for smartfrog, I looked at subant and decided to change it to make targets optional. 1. we could add this to subant skipmissingtargets 2. I'd also like to give subant the ability to set the basedir, the way ant does - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Update [was Re: weblogic rmic]
Kev Jackson wrote: Hi, We need to ship ant-weblogic.jar for ant 1.7.1. (Unless we vote to drop it from that release). We will not ship it in ant 1.8.0. That means that somehow I have to get the build to create the ant-weblogic.jar or we have a vote. One thing is clear: weblogic rmic was broken on ant1.7.0. nobody noticed. I can only assume that the test tests the behavior of an old version of weblogic rmic tool. Perhaps, but it behaves as if the classpath is messed up, not as if the weblogic tool is incorrect in some way Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: Rmic WebLogic failure more info
Kev Jackson wrote: Hi, Here's the -debug output of executing testWlrmic in isolation: org.apache.tools.ant.taskdefs.rmic.WLRmic.execute(WLRmic.java:76) ... 17 more Caused by: java.lang.IllegalArgumentException: Unrecognized option or flag, -vco mpat at weblogic.utils.Getopt2.grok(Getopt2.java:164) at weblogic.utils.compiler.Tool.run(Tool.java:117) at weblogic.utils.compiler.Tool.run(Tool.java:103) at weblogic.rmic.main(rmic.java:142) ... 22 more It's seems that this has been a problem for a while: http://mail-archives.apache.org/mod_mbox/ant-dev/200611.mbox/[EMAIL PROTECTED] This is the list of options supported by weblogic rmic: http://edocs.bea.com/wls/docs81/rmi/rmi_rmic.html#662053 -vcompat is absent - so can we prevent this being passed in this test? I added an override point in the base rmic adapter to handle mapping from version options in rmic to version options in the compiler; the wlrmic one warns if any option is set. Try running the tests now -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]
Re: terminating running builds better
Steve Loughran wrote: I'm midway through adding the smartfrog features to run ant builds remotely; buildexceptions will get wrapped and sent back over the wire to the caller via our friend RMI. as will, ultimately, the logs. you can use this to run build files as part of a big deployment, and be able to dynamically tweak the log levels as you go. one things I'm worrying about is how to stop long-running builds more cleanly. I'm thinking of an executor that polls some halt variable between targets, but that does nothing for tasks. Can/should we add something to project, so that you can actually interrupt project execution between tasks? We coudl through a BuildInterruptedException. What do IDEs do to stop ant builds? just kill the thread/process? of course, a more devious way would be to implement the check-for-halt logic in a build listener, so that you can retrofit the halting tests to an out the box ant1.7.0 release; throw a BuildInterruptedException (that extends BuildException). what bad things would happen if I threw a BuildException in a BuildListener.targetstarted() call? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rmic WebLogic failure more info
Kev Jackson wrote: Hi, Here's the -debug output of executing testWlrmic in isolation: Caused by: java.lang.IllegalArgumentException: Unrecognized option or flag, -vco mpat at weblogic.utils.Getopt2.grok(Getopt2.java:164) at weblogic.utils.compiler.Tool.run(Tool.java:117) at weblogic.utils.compiler.Tool.run(Tool.java:103) at weblogic.rmic.main(rmic.java:142) ... 22 more It's seems that this has been a problem for a while: http://mail-archives.apache.org/mod_mbox/ant-dev/200611.mbox/[EMAIL PROTECTED] This is the list of options supported by weblogic rmic: http://edocs.bea.com/wls/docs81/rmi/rmi_rmic.html#662053 -vcompat is absent - so can we prevent this being passed in this test? we should filter it out from being passed down I'll file a bug and take a look at it now. -- 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]
Re: Ant SVN Trunk - errors in LocatorTest RmicAdvancedTest
Kev Jackson wrote: Hi, After Steve's work yesterday, I was going to pull in the changes to the release to try and get a clean build...but: (these errors occur with the svn trunk code) LocatorTest testNetworkURI Failure Expected file:\\PC03\jclasses\lib\ant-1.7.0.jar to resolve to \\PC03\jclasses\lib\ant-1.7.0.jar but got D:\\PC03\jclasses\lib\ant-1.7.0.jar expected:[]\\PC03\jclasses\lib\... but was:[D:]\\PC03\jclasses\lib\... I'm not sure what this should be - \\ is a unc path right, and windows should support that, so I'm not sure where the D: comes from (except that's the local disk that I'm running the ant tests from) LocatorTest testUnixNetworkPath Failure Expected file://cluster/home/ant/lib to resolve to \\cluster\home\ant\lib but got D:\\cluster\home\ant\lib expected:[]\\cluster\home\ant\l... but was:[D:]\\cluster\home\ant\l... Should this execute at all on a windows machine? I hadnt decided what the right outcome here was...the code has the option of us providing a separate windows expected string, but we need to know what to expect If I type, in ie7, file://morzine/slo I get a new windows explorer window opening up to the share \\morzine\slo If I type, in ie6, file://morzine/slo the IE6 window turns into an windows explorer window showing the share \\morzine\slo in icon vew RmicAdvancedTest testWlrmic Error Error starting WebLogic rmic: D:\eclipse\workspace2\ant-core-trunk\src\etc\testcases\taskdefs\rmic\rmic.xml:174: Error starting WebLogic rmic: at org.apache.tools.ant.taskdefs.rmic.WLRmic.execute(WLRmic.java:84) I have the weblogic* jars and the ant- stubs so there shouldn't be an issue finding classes RmicAdvancedTest testWlrmicJArg Error Error starting WebLogic rmic: D:\eclipse\workspace2\ant-core-trunk\src\etc\testcases\taskdefs\rmic\rmic.xml:180: Error starting WebLogic rmic: at org.apache.tools.ant.taskdefs.rmic.WLRmic.execute(WLRmic.java:84) ahh. I bet that test doesnt run on my box, as I dont have the rmi tests When we can resolve these last couple of things I'll pull the changes into the branch - re-test (on java6+win, java5+win and java4+win, java6+*nix, java5+*nix and java4+*nix), finally if everything looks ok I'll post a vote for alpha release of 1.7.1 ok? Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
Re: Bugs in release branch
Jesse Glick wrote: Stefan Bodewig wrote: file://cluster/home/ant/lib This is probably illegal too; AFAIK the host field is meaningless for a file-protocol URL. I think it is not (SMB or NFS), something like ls //nfserver/homes/mine translates into a file URI with host. Not on Unix; NFS mounts still look like regular FS paths, e.g. /net/some.server/home/bob - file:/net/some.server/home/bob/ which has an empty and elided host field. Apollo workstations had a filesystem with the //hostname prefix; its where windows grabbed it form Windows has \\server\path UNC paths for which the JRE has AFAIK never gotten URIs quite right. You can search bugs.sun.com for UNC URI or something like that and get the story. Anyway, it seems that the test is attempting to manipulate file: URLs for file path syntaxes which cannot exist on the host OS. This is a mistake, I think. A Unix system cannot be expected to interpret \\workserver\Documents and Folders\ as a real file path during a unit test, and a Windows system cannot be expected to treat /home/bob as a file path independent of any drive letter. -J. I'll look at it after the rmic tests - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugs in release branch -rmic
Kevin Jackson wrote: Hi, On Windows with JDK6, the following tests fail: I see the rmi tests on linux+the latest jdk6 too. RmicAdvancedTest.testXnew rmic.testXnew: [base-rmic] RMI Compiling 1 class to /home/slo/Java/Apache/ant/src/etc/testcases/taskdefs/rmic/build [base-rmic] rmic: error - Doclet class sun.rmi.rmic.newrmic.Main does not contain a start method [base-rmic] 1 error Well, there's our problem. Actually, this whole area was trouble, look at this bug. that the XNewRmic compiler points to http://issues.apache.org/bugzilla/show_bug.cgi?id=38732 and, from the command line, xnewForked works == Entering project In /home/slo/Java/Apache/ant/src/etc/testcases/taskdefs/rmic == rmic.testXnewForked: [base-rmic] RMI Compiling 1 class to /home/slo/Java/Apache/ant/src/etc/testcases/taskdefs/rmic/build 1. the testXnew should be skipped for Java6; don't know about successors. But ignore this particular failure as it is something going in rmic that we can't handle. RmicAdvancedTest.testXnewForked Error org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration Now, this is fun. This routine works from the command line. But under junit, [junit] org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration [junit] java.lang.ClassCastException: org.apache.xerces.parsers.XIncludeAwareParserConfiguration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration [junit] at org.apache.xerces.parsers.SAXParser.init(Unknown Source) [junit] at org.apache.xerces.parsers.SAXParser.init(Unknown Source) [junit] at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.init(Unknown Source) [junit] at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) [junit] at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) [junit] at org.apache.tools.ant.util.JAXPUtils.newSAXParser(JAXPUtils.java:215) [junit] at org.apache.tools.ant.util.JAXPUtils.getNamespaceXMLReader(JAXPUtils.java:172) [junit] at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:182) [junit] at org.apache.tools.ant.helper.ProjectHelper2.parse(ProjectHelper2.java:138) [junit] at org.apache.tools.ant.ProjectHelper.configureProject(ProjectHelper.java:93) [junit] at org.apache.tools.ant.BuildFileTest.configureProject(BuildFileTest.java:289) [junit] at org.apache.tools.ant.BuildFileTest.configureProject(BuildFileTest.java:272) [junit] at org.apache.tools.ant.taskdefs.RmicAdvancedTest.setUp(RmicAdvancedTest.java:44) Except, what happens if I coment out testXnew()? apache-ant.junit-single-test-only: [mkdir] Created dir: /home/slo/Java/Apache/ant/build/failingTests [mkdir] Created dir: /home/slo/Java/Apache/ant/build/testcases/xml [junit] Testsuite: org.apache.tools.ant.taskdefs.RmicAdvancedTest [junit] Tests run: 23, Failures: 0, Errors: 0, Time elapsed: 9.004 sec [junit] Testcase: testDefault took 0.597 sec [junit] Testcase: testEmpty took 0.29 sec [junit] Testcase: testRmic took 0.282 sec [junit] Testcase: testRmicJArg took 0.284 sec [junit] Testcase: testKaffe took 0.2 sec [junit] Testcase: testWlrmic took 0.248 sec [junit] Testcase: testWlrmicJArg took 0.171 sec [junit] Testcase: testForkingAntClasspath took 0.745 sec [junit] Testcase: testAntClasspath took 0.443 sec [junit] Testcase: testBadName took 0.164 sec [junit] Testcase: testExplicitClass took 0.289 sec [junit] Testcase: testWrongClass took 0.196 sec [junit] Testcase: testDefaultBadClass took 0.216 sec [junit] Testcase: testMagicProperty took 0.185 sec [junit] Testcase: testMagicPropertyOverridesEmptyString took 0.155 sec [junit] Testcase: testMagicPropertyIsEmptyString took 0.227 sec [junit] Testcase: testVersion11 took 0.216 sec [junit] Testcase: testVersion12 took 0.262 sec [junit] Testcase: testVersionCompat took 0.29 sec [junit] Testcase: testXnewForked took 1.146 sec [junit] Testcase: testXnewCompiler took 1.214 sec [junit] Testcase: testIDL took 0.793 sec [junit] Testcase: testIIOP took 0.348 sec Hypothesis: running -Xnew compiler in Java6 unforked screws up Ant for the rest of the life of the process, by fiddling with the XML factories. Whoever wrote that code made some assumptions about running in a self contained process that doesnt hold. Here's some options 1. Turn off testXNew -stops rmic failing, stops the followon tests failing. hides any problems with rmic on java 2 patch SunRmic to see the -Xnew parameter, and fail the build, tell the user they need to fork the jvm -changes test
Re: Bugs in release branch
Kevin Jackson wrote: LocatorTest.testNetworkURI Failure Expected file:\\PC03\jclasses\lib\ant-1.7.0.jar to resolve to \\PC03\jclasses\lib\ant-1.7.0.jar but got D:\\PC03\jclasses\lib\ant-1.7.0.jar expected:[]\\PC03\jclasses\lib\... but was:[D:]\\PC03\jclasses\lib\... I dont think this is correct. C:\dir \\morzine\slo\projects.tar Volume in drive \\morzine\slo is slo Volume Serial Number is 10BB-0117 Directory of \\morzine\slo 2006-03-24 10:14 6,451,200 projects.tar 1 File(s) 6,451,200 bytes 0 Dir(s) 401,221,718,016 bytes free (a) its a valid path (b) SATA disk drives are very big LocatorTest.testUnixNetworkPath Failure Expected file://cluster/home/ant/lib to resolve to //cluster/home/ant/lib but got D:\\cluster\home\ant\lib expected:[//cluster/home/ant/]lib but was:[D:\\cluster\home\ant\]lib should maybe go to \\cluster\home\ant\lib LocatorTest.testUnixNetworkPath13 Failure Expected file://cluster/home/ant/lib to resolve to //cluster/home/ant/lib but got D:\\cluster\home\ant\lib expected:[//cluster/home/ant/]lib but was:[D:\\cluster\home\ant\]lib same LocatorTest.testUnixPath Failure Expected file:/home/ant/lib to resolve to /home/ant/lib but got D:\home\ant\lib expected:[/home/ant/]lib but was:[D:\home\ant\]lib looks correct LocatorTest.testInternationalURI Failure Expected file:/D:/L/u00f6wenbrau/aus/M/u00fcnchen to resolve to /L\u00f6wenbrau/aus/M\u00fcnchen but got D:\L\u00f6wenbrau\aus\M\u00fcnchen expected:[/L\u00f6wenbrau/aus/]M\u00fcnchen but was:[D:\L\u00f6wenbrau\aus\]M\u00fcnchen again, the results look correct. LocatorTest.testOddLowAsciiURI Failure Expected file:/D:/hash%23/%20and%20/percent%25 to resolve to /hash#/ and /percent% but got D:\hash#\ and \percent% expected:[/hash#/ and /]percent% but was:[D:\hash#\ and \]percent% looks ok Does anyone else have these errors from the current 1.7.1 branch? No, because I'm not running windows right now :) Looking at the locator code, we used to choose between java.net.URI on Java1.4+, and our own uri mapping logic on java =1.3, but switched to only using our own code as we got tired of URI mapping issues in the java classes. It looks like (1) -all the tests are unix-centric (2) -//hostname/file is a legitimate path in windows; should map to \\hostname\file with no drive prefix We can fix (1) by declaring the expected string for windows too. (2) this is a bug to fix -- 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]
Re: Bugs in release branch
I've tweaked the locator tests to take a string of expected values for
both windows and unix systems, so we can hard code what we expect for both
Steve Loughran wrote:
LocatorTest.testInternationalURI
FailureExpected file:/D:/L/u00f6wenbrau/aus/M/u00fcnchen to resolve
to /L\u00f6wenbrau/aus/M\u00fcnchen but got
D:\L\u00f6wenbrau\aus\M\u00fcnchen
expected:[/L\u00f6wenbrau/aus/]M\u00fcnchen but
was:[D:\L\u00f6wenbrau\aus\]M\u00fcnchen
again, the results look correct.
actuall
[junit] Testcase: testInternationalURI took 0.003 sec
[junit] FAILED
[junit] expected 0xf6 (\u00f6), but got 5c '\' expected:246 but
was:92
[junit] junit.framework.AssertionFailedError: expected 0xf6
(\u00f6), but got 5c '\' expected:246 but was:92
There was a bug in the tests here, we were double escaping the \u
symbol. I've fixed that and got the string being returned, so we now
test for the explicit unicode char coming back. Oh, and I handle the
current directory being stuck in ahead of the path by moving to relative
paths and prefixing the cwd in the comparison.
here's the new test, that passes on unix
public void testInternationalURI() throws Exception {
String result=assertResolves(L\u00f6wenbrau.aus.M\u00fcnchen);
char umlauted = result.charAt(1);
assertEquals(expected 0xf6 (\u00f6), but got
+Integer.toHexString(umlauted)+ '+umlauted+',
0xf6, umlauted);
}
The windows tests will still be failing with bad paths, but now we can
decide what the correct strings are and add them to the tests, then fix
any locator bugs that exist.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugs in release branch
Kev Jackson wrote: The windows tests will still be failing with bad paths, but now we can decide what the correct strings are and add them to the tests, then fix any locator bugs that exist. I guess they always passed on gump as it was running on linux/bsd, which is why we didn't see any problems until now. And yes most of the tests looked fine to me before which was why I couldn't believe no-one else was having a problem - now I know, I'm the only one using windows! I hope to set up a vmware image of win2k03 server running hudson or bamboo soonish; I could set it to do ant head too. It will stop me doing windows proof work. Last week I added the file sshexec.sf to the repository, alongside an existing file sshExec. Everything works for me, but someone else got wierd errors from SVN about being unable to copy a file because it existed. Even clean checkouts didnt work. of course, the reason is simple, windows doesnt like two files of the same name in the same directory; I'd broken the build. Which is why I need a CI server on windows, because the linux ones catch different problems. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
terminating running builds better
I'm midway through adding the smartfrog features to run ant builds remotely; buildexceptions will get wrapped and sent back over the wire to the caller via our friend RMI. as will, ultimately, the logs. you can use this to run build files as part of a big deployment, and be able to dynamically tweak the log levels as you go. one things I'm worrying about is how to stop long-running builds more cleanly. I'm thinking of an executor that polls some halt variable between targets, but that does nothing for tasks. Can/should we add something to project, so that you can actually interrupt project execution between tasks? We coudl through a BuildInterruptedException. What do IDEs do to stop ant builds? just kill the thread/process? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bugs in release branch
Jesse Glick wrote: Kevin Jackson wrote: LocatorTest.testNetworkURI file:\\PC03\jclasses\lib\ant-1.7.0.jar This is not a syntactically valid URI, I think. LocatorTest.testUnixNetworkPath file://cluster/home/ant/lib This is probably illegal too; AFAIK the host field is meaningless for a file-protocol URL. I wrote these tests. I seem to recall the whole area being a big source of trouble. hostnames are valid in some URLs (think nfs), but the uri handler in the JVM made a mess of them. This was stopping people running ant off a fileshare LocatorTest.testUnixPath Expected file:/home/ant/lib to resolve to /home/ant/lib but got D:\home\ant\lib expected:[/home/ant/]lib but was:[D:\home\ant\]lib Doesn't look like a bug to me, looks correct, assuming you are running on a Windows machine. Same for the subsequent failures. -J. -- 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]
Re: Problem with Cactus and Ant
= createMirror(this, mirrorLoader); How does cactus override execute()? Does it call super.execute(), or does it do something else? If you point us at the SVN copy of the task, we can look for ourselves and see. It may be that you are calling some internal execution stuff before a delegate is set up -- 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]
adding a waitfor to a sequence
How do I go (new Sequential).addTask(new WaitFor())? Because WaitFor is not a task, just a project component with an execute method. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: adding a waitfor to a sequence
[EMAIL PROTECTED] wrote: Not tried TaskAdapter ta = new TaskAdapter(); ta.setProxy( new WaitFor() ); (new Sequential).addTask(ta); that's it. FWIW, I'm doing a functional test task for Ant, based on my experience with the SmartFrog one, but not using any of the existing code. This one will be cleaner, as I can edit WaitFor and the like to simplify the code. -- 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]
getting const strings into antunit tests
Now, one more feature for someone to add, which is a variant of what we
added to smartfrog last week.
1. In junit tests, you can reference the Java string in the java code,
so your tests dont break if the message changes.
2. If you test in a higher level framework (antunit, sf test compounds),
you cant do that, so you copy and paste the string in.
3. which is very brittle.
Our solution was to add a new reference, so we can extract text from a
java static member
testBadHost extends SSHTestExpectsFailure {
action:host=missing.example.org;
expectedText CONSTANT
org.smartfrog.services.ssh.sshExec.ERROR_NO_HOST;
}
you end up being immune to string changes, only to moved constants and
people moving to fancy formatted strings.
seems to me, we could do the same with an ant resource, one that returns
the toString value of a resource as its contents. then we enhance
antunit to have a resourceeuqals assertion that compares two resources
(we have something like this, right?), and we can just search for the
specific resource in text, error logs,etc.
--
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]
Re: adding a waitfor to a sequence
Matt Benson wrote: Sorry, guys--multitasking and responded to Steve's query without updating my inbox first. Then had a race condition with Jan to add the convenience constructor. ;) no problem, thank you both :) you will soon have a task to test with. Actually, the task itself isnt that easy to rewrite; I've found and fixed various timeout bugs in the setup/teardown stages. Its the testing of the test task, that's the hard thing. -- 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]
Re: svn commit: r585108 - /ant/core/trunk/src/main/org/apache/tools/ant/taskdefs/XSLTProcess.java
Stefan Bodewig wrote: On Tue, 16 Oct 2007, [EMAIL PROTECTED] wrote: URL: http://svn.apache.org/viewvc?rev=585108view=rev Log: Bug ID 43635 xslt task can't be used more than once with a file stylesheet Do you intend to merge it into the 1.7 branch? Tell me how to merge stuff in SVN and I will try! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Correct Task Behaviour
Matthew Haynes wrote: That's great, I had made the mistake of assuming that the setSomething methods needed a String. Does resolve other common types, DateFomat, int, etc ? Try them and see. The general rule is -anything that takes a string constructor will be constructed before being added -there is special support for various common Java or ant types: file, path, reference -you can add your own types if you give them a string constructor -if you overload a setter with a complex type and a string, the complex one gets picked -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]
Re: Correct Task Behaviour
Matthew Haynes wrote:
Hello,
I am the developer of a small ant task
http://code.google.com/p/jsmin-ant-task/.
The task takes file paths as attributes and a recent bug / feature request
has posed a question. When using a build file located outside of the current
working directory how should relative paths be handled?
For example if i execute ant like this: ant -file webstuff/build.xml
Should relative paths specified in the build file now become relative to the
current working directory? Or should they stay relative to the build file?
Depending on how I handle the paths in the source code both options are
available.
What is the usual expected behaviour here?
1. If your task takes anything like a File as an attribute, by the time
you see it it has already been resolved relative to the basedir
2. this is the convention that nearly everything in Ant supports
3. the sole exception is import, which was designed to let you do
relative, chained import operations. Each import is relative to the
current build file, unless you go import file=${basedir}/something.xml /
4. the fact that import works this way causes lots of fun under Eclipse,
if it copies the build.xml file to its workspace while leaving the rest
of the project elsewhere in the filesystem.
So, accept File, Path and Fileset datatypes and Ant will do all the work
for you, and leave your task consistent with everything else.
-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]
Re: Ivy task to import common build tasks
Gilles Scokart wrote:
I have also seen something similar in the plan for ant 1.8 [1]:
- import improvements (url support, searchpath support)
I don't know if it includes also searching build file into a jar. But I
think that if you combine this futur demand with the ressources of 1.7, it
should.
[1] http://wiki.apache.org/ant/Ant18/Planning
the main thing I'd thought of there was resource enabling import, so
it would pull in a file from any resource, rather than just the filesystem.
import
zipentry archive=build/lib/something.zip name=myproject/build.xml /
/import
or
import
url url=http://example.org/build.xml; /
/import
with the obvious security risks in the latter. (maybe I should extend
url with an md5sum option)
One change we'd have to make to the resources is to allow resources to
implement a relative-resource-source interface, so that when I import a
URL, I can then do a relative resolution on its nested import
statements to pull down other artifacts. zipentries would get at other
zips, etc. We'd have to extend every ant project to track the resource
it came from, instead of just its base dir.
I like the idea of pulling down specific versions of a library via ivy.
If we made the resource enhancements to Ant, Ivy would have to match
this with a resource that let you declare group/artifact/ entry
import
ivyentry org=org.apache name=example
version=${example.version} name=org/apache/example/build.xml /
/import
or, to load in files from a set of JARs:
import
ivyentry ivyconf=main conf=test
name=org/apache/example/build.xml /
/import
--
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]
printStackTrace in org.apache.tools.ant.taskdefs.XSLTProcess,
The IDE is complaining that there's a printStackTrace in the XSLT code.
should we keep this or cut it?
protected XSLTLiaison getLiaison() {
// if processor wasn't specified, see if TraX is available. If
not,
// default it to xalan, depending on which is in the classpath
if (liaison == null) {
if (processor != null) {
try {
resolveProcessor(processor);
} catch (Exception e) {
throw new BuildException(e);
}
} else {
try {
resolveProcessor(PROCESSOR_TRAX);
} catch (Throwable e1) {
e1.printStackTrace();
throw new BuildException(e1);
}
}
}
return liaison;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Correct Task Behaviour
Matthew Haynes wrote:
Thanks for the responses.
I think my problem came from accepting the file attribute as a String and
then converting it to a file in my code. I guess if I do something like the
below I shall get the correct behaviour.
public void setSrcFile(File srcFile) {
..
}
that's right. Ant will do the resolution for you. Otherwise you have to
make some call on your project instance to do the resolution
--
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]
Re: propose 1.7.1 bug fix release
Kevin Jackson wrote: Hi, I'd like to propose a timetable for the release of 1.7.1. We know that the users are waiting for several important fixes that are already in trunk, and I think we should try to release as soon as we can. Following the release instructions :), I suggest that we start to cut a beta the week beginning 22nd October (2 weeks today). OK. Does anyone have a large contribution outstanding that would need much more time? Is there still a race condition on multi-core machines? seems fixed, and it was on 1.8.x anyway. Is there anything we've added to the 1.8.x branch that should be moved over? The big project logger is the main thing I've added; I love this for big ivy-managed builds where lots of things get run -it prints the project name of every target -it prints when you enter/exit projects -it doesnt print anything for a target with no output here's a bit of a trace: ant test Buildfile: build.xml == Entering project In /home/slo/Projects/SmartFrog/Forge/core/components/jetty == jetty.maybe-ivy-init: [ivy:configure] :: Ivy 2.0.0-alpha2-incubating - 20070712142751 :: http://incubator.apache.org/ivy/ :: [ivy:configure] ivy:configure is deprecated, please use the data type ivy:settings instead jetty.maybe-ivy-resolve: so, I'm in the jetty project -- 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]
