Re: [POLL] Bug 48804
On 2010-04-23, Dominique Devienne ddevie...@gmail.com wrote: On Fri, Apr 23, 2010 at 4:29 AM, Stefan Bodewig bode...@apache.org wrote: [...] Personally I think the changed behavior isn't a bad thing, the old behavior isn't documented and we shouldn't even try to keep it. I agree. Fixing the primary use-case trumps this particular behavior. If we can't fix the bug without allow this ahead-of-time use of the extension point, it's no big deal to me. Technically we could also disallow it, but it would take some additional effort that I'm not sure is worth it, that's why I started this poll. Thanks Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: move-test fails on Windows7
On Apr 23, 2010, at 3:08 AM, Stefan Bodewig wrote:
On 2010-04-22, Stefan Bodewig bode...@apache.org wrote:
On 2010-04-21, Steve Loughran ste...@apache.org wrote:
So perhaps the check for windows (and special handling) is failing
I'll try to fix it.
There is no Windows specific code, I've reopened bug 41948 because its
fix doesn't seem to work reliably on Windows7 anymore.
The problem is this code in Move#renameFile
sourceFile = getFileUtils().normalize
(sourceFile.getAbsolutePath()).getCanonicalFile();
destFile = getFileUtils().normalize
(destFile.getAbsolutePath());
if (destFile.equals(sourceFile)) {
//no point in renaming a file to its own canonical
version...
log(Rename of + sourceFile + to + destFile
+ is a no-op., Project.MSG_VERBOSE);
return true;
}
Using Win7 destFile.equals(sourceFile) returns true so no attempt is
even made to rename abc to aBc. Using WinXP it must have returned
false (can't test it anymore).
I would understand why we wanted to skip the rename operation if
the old
and new absolute and normalized file names were the same, but I don't
understand how and why we are comparing one canonical file to a
non-canonical one and then decide we don't need a rename if they
are the
same.
Matt, Martijn or Antoine, you've been involved in fixing the bug many
moons ago - do you still remember why the condition has been written
that way?
IIRC the purpose is to detect the attempted rename of a file to its
own canonical name, e.g. when the original name case-insensitively
equals the target name on a case-insensitive filesystem.
-Matt
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] Bug 48804
On Apr 23, 2010, at 4:29 AM, Stefan Bodewig wrote: Hi all, currently extension-point and import don't play together like they are supposed to. You can't extend an imported extension point with a target from the importing build file (which is the primary use-case, really). Attached to this bug is a patch that fixes the problem (including an AntUnit test that fails in 1.8.0). The same patch breaks a different AntUnit test, namely testExtensionPointMustBeKnown in extension-point-test.xml. This test asserts that you can't extend an extension point from the same build file before that extension point has been defined. I.e. you can't do target name=bar extensionOf=foo/ extension-point name=foo/ Personally I think the changed behavior isn't a bad thing, the old behavior isn't documented and we shouldn't even try to keep it. What do you think? I don't see any harm in allowing an extensionOf foo to be declared in the same buildfile as extension-point foo. In contrast, I have been frustrated by the primary issue from the referenced bugrep. Which all translates to my being in general agreement with your opinion. -Matt Stefan PS: I'd love to see this fixed with Ant 1.8.1. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] Bug 48804
I think that since the code doesn't address the primary usecase, that trumps pretty-well all considerations. It is hard to imagine how someone would be relying on the order of the extension point/extension evaluation in order to avoid the extension point. Since the behaviour isn't documented anyway, doing so would have to be considered a hack. I'd say make it do what it is supposed to do. If it passes gump, then we can wait to see if any bug reports show up. If they do, we can deal with those on a case-by-case basis, perhaps arriving at a wholly different solution for them. Personally, I don't think any will show up. On 23/04/2010 2:29 AM, Stefan Bodewig wrote: Hi all, currently extension-point and import don't play together like they are supposed to. You can't extend an imported extension point with a target from the importing build file (which is the primary use-case, really). Attached to this bug is a patch that fixes the problem (including an AntUnit test that fails in 1.8.0). The same patch breaks a different AntUnit test, namely testExtensionPointMustBeKnown in extension-point-test.xml. This test asserts that you can't extend an extension point from the same build file before that extension point has been defined. I.e. you can't do target name=bar extensionOf=foo/ extension-point name=foo/ Personally I think the changed behavior isn't a bad thing, the old behavior isn't documented and we shouldn't even try to keep it. What do you think? Stefan PS: I'd love to see this fixed with Ant 1.8.1. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [POLL] Bug 48804
I agree, however it may be good to update the 1.8.0 manual with a warning that the behavior is currently not as intended and will change, published as soon as the solution is changed. br martijn On 23/04/2010 2:29 AM, Stefan Bodewig wrote: Hi all, currently extension-point and import don't play together like they are supposed to. You can't extend an imported extension point with a target from the importing build file (which is the primary use-case, really). Attached to this bug is a patch that fixes the problem (including an AntUnit test that fails in 1.8.0). The same patch breaks a different AntUnit test, namely testExtensionPointMustBeKnown in extension-point-test.xml. This test asserts that you can't extend an extension point from the same build file before that extension point has been defined. I.e. you can't do target name=bar extensionOf=foo/ extension-point name=foo/ Personally I think the changed behavior isn't a bad thing, the old behavior isn't documented and we shouldn't even try to keep it. What do you think? Stefan PS: I'd love to see this fixed with Ant 1.8.1. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
