On Thu, Apr 3, 2008 at 10:20 PM, Archie Cobbs [EMAIL PROTECTED] wrote:
One last question what purpose does the organization attribute
really
serve anyway?
Is it only to allow for two different organizations to create modules with
the same name?
Yes, mainly.
If so, I wonder if that
On Fri, Apr 4, 2008 at 12:49 AM, [EMAIL PROTECTED] wrote:
Author: maartenc
Date: Thu Apr 3 15:49:49 2008
New Revision: 644541
URL: http://svn.apache.org/viewvc?rev=644541view=rev
Log:
IMPROVEMENT: make it possible to specify permissions of published files
for the SSH resolver (IVY-764) +
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
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 dev@ant.apache.org
Sent: Friday, April 4, 2008 9:19:57 AM
Subject: Re: svn commit: r644541 - in
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 task
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 dev@ant.apache.org
Sent: Friday, April 4, 2008 9:45:57 AM
Subject: Re: svn commit:
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.
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 :
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 the
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 URLResolver
11 matches
Mail list logo
