It was hardcoded to 0600 in Scp.java before I made this change. To keep it BC,
I defaulted it to the same value. As far as I could see, the umask wasn't used.
Since this attribute is only used for publishing modules, not for module
retrieval, I think we should at least keep "publish" in the attr
On Fri, Apr 4, 2008 at 9:19 AM, Maarten Coene <[EMAIL PROTECTED]>
wrote:
> It was hardcoded to 0600 in Scp.java before I made this change. To keep it
> BC, I defaulted it to the same value.
OK, I didn't see that, I thought it was using umask according to the
discussions on the issue. Sorry about
Btw, in the manual for chmod, they use the "mode" terminology for this kind of
information.
Maarten
- Original Message
From: Maarten Coene <[EMAIL PROTECTED]>
To: Ant Developers List
Sent: Friday, April 4, 2008 9:19:57 AM
Subject: Re: svn commit: r644541 - in /ant/ivy/core/trunk: CHANG
On Fri, Apr 4, 2008 at 9:24 AM, Maarten Coene <[EMAIL PROTECTED]>
wrote:
> Btw, in the manual for chmod, they use the "mode" terminology for this
> kind of information.
Maybe it's only me then, but I think mode is too generic in this situation.
Moreover we have resolveMode option on the resolve t
publishPermissions is fine for me, we can use the "chmod mode" terminology in
the documentation of this attribute.
Maarten
- Original Message
From: Xavier Hanin <[EMAIL PROTECTED]>
To: Ant Developers List
Sent: Friday, April 4, 2008 9:45:57 AM
Subject: Re: svn commit: r644541 - in /ant
On Fri, 04 Apr 2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> The strange thing is that even the oldest version of
> JUnit4TestCaseFacade[3] I can find contains such a constructor.
http://junit.cvs.sourceforge.net/junit/junit/junit/framework/JUnit4TestCaseFacade.java?hideattic=0&revision=1.2&v
Hi all,
we can finally see[1] why the tests fail in Gump (and this is the only
remaining failure on vmgump, BTW)
[junit] nested build's System.err:
/srv/gump/public/workspace/ant/src/etc/testcases/taskdefs/optional/out/FailedTests.java:9:
cannot find symbol
[junit] symbol : constructor
On Fri, 04 Apr 2008, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> The root of the problem probably is that FailureRecorder expects the
> Test instance passed into addFailure to be an instance of the class
> under test - something that isn't true for JUnit4 wrapped tests in
> Ant.
it also assumes t
On Thu, Apr 3, 2008 at 8:39 AM, Archie Cobbs <[EMAIL PROTECTED]> wrote:
> I think I have enough information to go and work on a new resolver based
> on these ideas... will report back later...
>
Here's a very rough first cut at a new "builder" resolver.
Here's the basic idea: it works like URLRe
