Re: [VOTE] add Nicolas Lalevée as committer

[Nicolas Lalevée]

Le mercredi 13 février 2008, Xavier Hanin a écrit :
> Hi All,
>
> Nicolas Lalevée has contributed a lot of patches to Ivy and IvyDE [1 to
> 10], and has been actively involved in several discussions, especially
> about IvyDE. He is always fair when giving his opinion, and often try to
> help other users.
>
> IvyDE is a subproject of Ivy considered as highly important by several
> users [11], and Nicolas is greatly helping to improve it.
>
> So I think he would make a good addition to our developer team, hence this
> is a vote to make him a new committer.
>
> Even though only votes cast by PMC members are binding [12], all votes are
> welcome and important to us.
>
> Here's my vote: +1
>
> Xavier
>
> [1] https://issues.apache.org/jira/browse/IVY-704
> [2] https://issues.apache.org/jira/browse/IVY-702
> [3] https://issues.apache.org/jira/browse/IVY-646
> [4] https://issues.apache.org/jira/browse/IVYDE-62
> [5] https://issues.apache.org/jira/browse/IVYDE-69
> [6] https://issues.apache.org/jira/browse/IVYDE-66
> [7] https://issues.apache.org/jira/browse/IVYDE-64
> [8] https://issues.apache.org/jira/browse/IVYDE-76
> [9] https://issues.apache.org/jira/browse/IVYDE-68
> [10] https://issues.apache.org/jira/browse/IVYDE-63
> [11] http://www.nabble.com/ivyde-again-td15352211.html#a15352211
> [12] http://ant.apache.org/bylaws.html#Decision%20Making


Thanks you all of you, and also for the incoming votes !
It would a be an honor to join the Apache community ! :)

cheers,
Nicolas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] release Ivy 2.0.0-beta2?

[Adrian Sandor]

On Mon, Feb 11, 2008 at 4:20 PM, Xavier Hanin wrote:

> > So, if I understand correctly, right now settings/defaultCache is the
> > default for both resolution and repository cache;
> > settings/resolutionCacheDir overrides it for resolution, caches/basedir
> > overrides it for repository, and cache/basedir overrides caches/basedir
> > (for repository).
>
> Exactly, and I agree this is confusing :-)
>
> > Perhaps we can move settings/resolutionCacheDir to
> > caches/resolutionCacheDir, rename caches/basedir to
> > caches/repositoryCacheDir, and either remove settings/defaultCache or
> move
> > it to caches/defaultCacheDir.
>
> It makes sense. For defaultCache, I think we need to keep and rename it,
> for
> Ivy 1.x users who where used to it (and it eases the way to define where
> all
> Ivy cache data goes, which is the most common use case.
>
> Do anybody else see any problem with these changes?
>

Obviously, I agree with the changes (and generally moving cache-related
attributes out of the settings element).
Nobody else seems to have any comments so far. Do you think we can see these
changes soon?
Would you like me to work on it? Or add a comment to IVY-399?

Adrian

Re: Store pom dependency Managment in extra data

[Xavier Hanin]

I think we need to distinguish two kind of extra metadata: those used to
identify the module, and those which are pure information. IMO extra
attributes on the info tag are good candidates for the first kind of extra
meta information:
- because it's how they work now
- because the info tag attributes are mainly identifying the module.

So I think it's better to distinguish the other kind of extra information,
and you seem to agree, so this is fine :-)

Now about how to define these extra information, how to name them, and how
they can be used. IMO, if we introduce something in the core for maven 2
compatibility, it's better to try to find a use case for users who use Ivy
files only. So I think we need at least to find a syntax in Ivy files to
support setting this additional extra information.

Now about calling them properties and making them available as properties in
the Ivy file. What I like about that is that:
- it uses an existing concept in Ivy, so we don't need to define a new one
- it answers to a use case that at least I've had before (so I guess other
users have too), where I need a property in an ivy file and don't want to
define it outside my ivy file

About the added complexity, I think we need to distinguish two kind of
complexity: complexity in Ivy code, and complexity for users. IMO, it's
something pretty easy to understand by users, because we reuse an existing
and well known concept. In Ivy code, I don't think it make it really more
complex, if we allow to use a property only after it is declared (so if the
property definition comes after the info tag in the xsd, we won't be able to
use locally defined properties in the info tag). We already do this kind of
substitution for globally defined properties, and it can be easily factored
at the beginning of the startElement method, so I don't see much added
complexity here.

So I'm still in favor of this properties support in Ivy files. Did I manage
to change your mind ? :-)

Xavier

On Thu, Feb 14, 2008 at 8:51 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:

> I think that storing some extra free values is nice, but I'm not convinced
> that using real properties is a good thing.  It add some complexity to the
> parsing of the ivy files (where can you use property, can use it inside
> proerty declaration for instance).  If I look at maven pom, it is one of
> the
> thing that make it more complexe, with making it more powerfull.
>
> I think the extra value should just be values.  For instance, if someone
> want to store a bug tracking url, an organisation specific code, or
> anything
> else in its ivy file, he could store it there.
>
> I thought the extra data  could be used for that.  In the doc [1], it is
> not
> clear that when you use extra data in the info tag, you MUST use it also
> in
> the dependency tag of the module that use it.  I think that should be
> enhanced.
>
> Anyway, I will add an extraInfo field to the module descriptor.  Maybe, we
> can even retrofit all the content of info into it.
>
>
> [1] http://ant.apache.org/ivy/history/latest-milestone/concept.html#extra
>
> Gilles
>
>
> 2008/2/13, Xavier Hanin <[EMAIL PROTECTED]>:
> >
> > On Feb 13, 2008 9:10 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> >
> > > In the rewrite of the pom parser, I would like to store the maven
> > > dependency
> > > managment (and maybe also the properties) into the extra data of the
> > > moduleRevisionId.
> > >
> > > That way, the corresponding ivy module descriptor would contains all
> the
> > > info coming from the pom.  I think it might be usefull when it is
> > > serialized
> > > are reused from the cache (thought I'm not sure if it's the original
> pom
> > > or
> > > the serialized ivy.xml that is used in that case).
> > >
> > > However, I have noticed that the extra attributes are used to compare
> > > moduleRevisionId, and I fear that might bring some problem.  Does it?
> >
> >
> > Probably.
> >
> >
> >
> > >  And
> > > is it normal to use the extra attributes in this comparison?
> >
> >
> > I think so, many time people use extra attributes in the info tag to add
> > extra identification attributes. I don't really think putty meta
> > information
> > such as the dependency management information in extra attributes is a
> > good
> > fit. But I like the idea of keeping data from dependency management
> > section.
> > Maybe a good way to do it would be to add a Map of properties to the
> > module
> > descriptor. This would be another area of flexibility for Ivy users, and
> > I'd
> > even see usage for Ivy files, if we actually make them usable as
> > properties
> > in the Ivy file. Something like:
> > 
> >   
> >   
> >   
> > 
> > 
> > 
> >   
> > 
> >
> > WDYT?
> >
> > Xavier
> >
> > >
> > >
> > > --
> > > Gilles Scokart
> > >
> >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
>
>
>
> --
> Gilles Scokart
>



-- 
Xavi

Re: [VOTE] add Nicolas Lalevée as committer

[Xavier Hanin]

On Thu, Feb 14, 2008 at 9:23 AM, Nicolas Lalevée <
[EMAIL PROTECTED]> wrote:

> Le mercredi 13 février 2008, Xavier Hanin a écrit :
> > Hi All,
> >
> > Nicolas Lalevée has contributed a lot of patches to Ivy and IvyDE [1 to
> > 10], and has been actively involved in several discussions, especially
> > about IvyDE. He is always fair when giving his opinion, and often try to
> > help other users.
> >
> > IvyDE is a subproject of Ivy considered as highly important by several
> > users [11], and Nicolas is greatly helping to improve it.
> >
> > So I think he would make a good addition to our developer team, hence
> this
> > is a vote to make him a new committer.
> >
> > Even though only votes cast by PMC members are binding [12], all votes
> are
> > welcome and important to us.
> >
> > Here's my vote: +1
> >
> > Xavier
> >
> > [1] https://issues.apache.org/jira/browse/IVY-704
> > [2] https://issues.apache.org/jira/browse/IVY-702
> > [3] https://issues.apache.org/jira/browse/IVY-646
> > [4] https://issues.apache.org/jira/browse/IVYDE-62
> > [5] https://issues.apache.org/jira/browse/IVYDE-69
> > [6] https://issues.apache.org/jira/browse/IVYDE-66
> > [7] https://issues.apache.org/jira/browse/IVYDE-64
> > [8] https://issues.apache.org/jira/browse/IVYDE-76
> > [9] https://issues.apache.org/jira/browse/IVYDE-68
> > [10] https://issues.apache.org/jira/browse/IVYDE-63
> > [11] http://www.nabble.com/ivyde-again-td15352211.html#a15352211
> > [12] http://ant.apache.org/bylaws.html#Decision%20Making
>
>
> Thanks you all of you, and also for the incoming votes !
> It would a be an honor to join the Apache community ! :)

We still need to wait for the end of the vote timeframe (one week), but it
seems that your committership is on very good way!

I guess you can already prepare your ICLA [1], I bet your employer already
know the process pretty well :-)

Xavier
[1] http://www.apache.org/licenses/icla.txt


>
> cheers,
> Nicolas
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Re: [DISCUSS] release Ivy 2.0.0-beta2?

[Xavier Hanin]

On Thu, Feb 14, 2008 at 9:40 AM, Adrian Sandor <[EMAIL PROTECTED]> wrote:

> On Mon, Feb 11, 2008 at 4:20 PM, Xavier Hanin wrote:
>
> > > So, if I understand correctly, right now settings/defaultCache is the
> > > default for both resolution and repository cache;
> > > settings/resolutionCacheDir overrides it for resolution,
> caches/basedir
> > > overrides it for repository, and cache/basedir overrides
> caches/basedir
> > > (for repository).
> >
> > Exactly, and I agree this is confusing :-)
> >
> > > Perhaps we can move settings/resolutionCacheDir to
> > > caches/resolutionCacheDir, rename caches/basedir to
> > > caches/repositoryCacheDir, and either remove settings/defaultCache or
> > move
> > > it to caches/defaultCacheDir.
> >
> > It makes sense. For defaultCache, I think we need to keep and rename it,
> > for
> > Ivy 1.x users who where used to it (and it eases the way to define where
> > all
> > Ivy cache data goes, which is the most common use case.
> >
> > Do anybody else see any problem with these changes?
> >
>
> Obviously, I agree with the changes (and generally moving cache-related
> attributes out of the settings element).
> Nobody else seems to have any comments so far. Do you think we can see
> these
> changes soon?

I think we can agree to move on, it's not that a big change anyway.


> Would you like me to work on it? Or add a comment to IVY-399?

I think we have a little less than a week before we cut the beta2. If you
can do the job (code, reference doc and junit changes) in this timeframe,
it's more than welcome! Otherwise a comment on IVY-399 summing up the
changes would help, and I'll try to find some time to do the change,
probably early next week during my next trip to visit a customer.

Xavier


>
> Adrian
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

RE: Store pom dependency Managment in extra data

[Gilles Scokart]

> -Original Message-
> From: Xavier Hanin [mailto:[EMAIL PROTECTED]
> Sent: jeudi 14 février 2008 9:44
> To: Ant Developers List
> Subject: Re: Store pom dependency Managment in extra data
> 
> I think we need to distinguish two kind of extra metadata: those used to
> identify the module, and those which are pure information. IMO extra
> attributes on the info tag are good candidates for the first kind of extra
> meta information:
> - because it's how they work now
> - because the info tag attributes are mainly identifying the module.
> 
> So I think it's better to distinguish the other kind of extra information,
> and you seem to agree, so this is fine :-)
> 
> Now about how to define these extra information, how to name them, and how
> they can be used. IMO, if we introduce something in the core for maven 2
> compatibility, it's better to try to find a use case for users who use Ivy
> files only. So I think we need at least to find a syntax in Ivy files to
> support setting this additional extra information.

My idea was to use the attribute of the info tag as identifier, like it is now. 
 And put to other values under the info
tag, like you have now the license, the repository and so on.

We could put all those info into an extraInfo.

> 
> Now about calling them properties and making them available as properties in
> the Ivy file. What I like about that is that:
> - it uses an existing concept in Ivy, so we don't need to define a new one
> - it answers to a use case that at least I've had before (so I guess other
> users have too), where I need a property in an ivy file and don't want to
> define it outside my ivy file
> 
> About the added complexity, I think we need to distinguish two kind of
> complexity: complexity in Ivy code, and complexity for users. IMO, it's
> something pretty easy to understand by users, because we reuse an existing
> and well known concept. In Ivy code, I don't think it make it really more
> complex, if we allow to use a property only after it is declared (so if the
> property definition comes after the info tag in the xsd, we won't be able to
> use locally defined properties in the info tag). We already do this kind of
> substitution for globally defined properties, and it can be easily factored
> at the beginning of the startElement method, so I don't see much added
> complexity here.
> 
> So I'm still in favor of this properties support in Ivy files. Did I manage
> to change your mind ? :-)

Well, I'm now -0.1 for this.  I understand the use case, and I already faced it 
as well, but I still found the concept
of properties already quiet loaded (ant properties, settings properties, each 
with potentially different overwrite rules
and scoping).

Let see what the other things about it?

Gilles


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Store pom dependency Managment in extra data

[Xavier Hanin]

On Thu, Feb 14, 2008 at 10:49 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:

>
>
> > -Original Message-
> > From: Xavier Hanin [mailto:[EMAIL PROTECTED]
> > Sent: jeudi 14 février 2008 9:44
> > To: Ant Developers List
> > Subject: Re: Store pom dependency Managment in extra data
> >
> > I think we need to distinguish two kind of extra metadata: those used to
> > identify the module, and those which are pure information. IMO extra
> > attributes on the info tag are good candidates for the first kind of
> extra
> > meta information:
> > - because it's how they work now
> > - because the info tag attributes are mainly identifying the module.
> >
> > So I think it's better to distinguish the other kind of extra
> information,
> > and you seem to agree, so this is fine :-)
> >
> > Now about how to define these extra information, how to name them, and
> how
> > they can be used. IMO, if we introduce something in the core for maven 2
> > compatibility, it's better to try to find a use case for users who use
> Ivy
> > files only. So I think we need at least to find a syntax in Ivy files to
> > support setting this additional extra information.
>
> My idea was to use the attribute of the info tag as identifier, like it is
> now.  And put to other values under the info
> tag, like you have now the license, the repository and so on.
>
> We could put all those info into an extraInfo.

You can already put whatever you want in the description tag (which has
xs:any children in the xsd). So the difference would only be that this
information is parsed by Ivy, but how users could use them, if they aren't
properties? Only when using Ivy API?


>
> >
> > Now about calling them properties and making them available as
> properties in
> > the Ivy file. What I like about that is that:
> > - it uses an existing concept in Ivy, so we don't need to define a new
> one
> > - it answers to a use case that at least I've had before (so I guess
> other
> > users have too), where I need a property in an ivy file and don't want
> to
> > define it outside my ivy file
> >
> > About the added complexity, I think we need to distinguish two kind of
> > complexity: complexity in Ivy code, and complexity for users. IMO, it's
> > something pretty easy to understand by users, because we reuse an
> existing
> > and well known concept. In Ivy code, I don't think it make it really
> more
> > complex, if we allow to use a property only after it is declared (so if
> the
> > property definition comes after the info tag in the xsd, we won't be
> able to
> > use locally defined properties in the info tag). We already do this kind
> of
> > substitution for globally defined properties, and it can be easily
> factored
> > at the beginning of the startElement method, so I don't see much added
> > complexity here.
> >
> > So I'm still in favor of this properties support in Ivy files. Did I
> manage
> > to change your mind ? :-)
>
> Well, I'm now -0.1 for this.  I understand the use case, and I already
> faced it as well, but I still found the concept
> of properties already quiet loaded (ant properties, settings properties,
> each with potentially different overwrite rules
> and scoping).

Yes, but in this case it's actually just simpler: properties are defined in
the same file as where they are used. I agree that we still have to deal
with overwrite, but I don't think it's a major issue.

Xavier, trying to get at least a 0.1++ :-)


>
> Let see what the other things about it?
>
> Gilles
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Re: [DISCUSS] release Ivy 2.0.0-beta2?

[Adrian Sandor]

On Thu, Feb 14, 2008 at 4:56 PM, Xavier Hanin wrote:

> > Would you like me to work on it? Or add a comment to IVY-399?
>
> I think we have a little less than a week before we cut the beta2. If you
> can do the job (code, reference doc and junit changes) in this timeframe,
> it's more than welcome!


Well, I'm working on it. I plan to move *ALL* the cache-related attributes
to the "caches" element (but I'm still keeping the 1.x ones as deprecated),
let me know if there's any problem.
Anyway, I noticed that the "cache" element is wonderfully documented, but..
is completely missing from the code! If I'm wrong, could you show me where
it's getting parsed?

Thanks
Adrian

Re: [DISCUSS] release Ivy 2.0.0-beta2?

[Xavier Hanin]

On Thu, Feb 14, 2008 at 6:09 PM, Adrian Sandor <[EMAIL PROTECTED]> wrote:

> On Thu, Feb 14, 2008 at 4:56 PM, Xavier Hanin wrote:
>
> > > Would you like me to work on it? Or add a comment to IVY-399?
> >
> > I think we have a little less than a week before we cut the beta2. If
> you
> > can do the job (code, reference doc and junit changes) in this
> timeframe,
> > it's more than welcome!
>
>
> Well, I'm working on it. I plan to move *ALL* the cache-related attributes
> to the "caches" element (but I'm still keeping the 1.x ones as
> deprecated),
> let me know if there's any problem.
> Anyway, I noticed that the "cache" element is wonderfully documented,
> but..
> is completely missing from the code! If I'm wrong, could you show me where
> it's getting parsed?

The cache element under the caches element is parsed automatically using the
same logic as Ant tasks, using the Configurator class. At the beginning of
the XmlSettingsParser class you have an array of configuration elements,
including caches, which tells Ivy should auto configure the children. Then
there'sa typdef.properties making the mapping between the "cache" element
name and the DefaultRepositoryCacheManager class. But I suggest putting a
breakpoint in the setName of this class and run a unit test doing some
settings loading with cache related information, you'll better see what's
happening.

HTH,

Xavier

>
>
> Thanks
> Adrian
>



-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Re: import re-imports top-level build.xml

[Justin Vallon]

Peter Reilly wrote:

On Jan 28, 2008 10:55 PM, Vallon, Justin <[EMAIL PROTECTED]> wrote:
 >  if  is given a path to the original (top-level) 
build-file,

 > it does not consider it a duplicate import, and imports it (again) ...

That does sound like a bug!.

Please file a bugzilla report.


Filed as 44323.

I have attached a patch against ant_20080130114915.tar.gz.  It calls 
FileUtils.normalize on the buildFile in Main.


Who can commit this?

Test case:

build.xml:






'ant' should show "start test", "end test".  Without the patch it shows 
"start test"*2, "end test"*2.


-Justin
[EMAIL PROTECTED]
--- src/main/org/apache/tools/ant/Main.java.orig2007-05-25 
06:31:03.0 -0400
+++ src/main/org/apache/tools/ant/Main.java 2008-02-14 12:58:10.556245800 
-0500
@@ -418,10 +418,13 @@
 if (buildFile.isDirectory()) {
 System.out.println("What? Buildfile: " + buildFile + " is a dir!");
 throw new BuildException("Build failed");
 }
 
+// Normalize buildFile for re-import detection
+buildFile = 
FileUtils.getFileUtils().normalize(buildFile.getAbsolutePath());
+
 // Load the property files specified by -propertyfile
 loadPropertyFiles();
 
 if (msgOutputLevel >= Project.MSG_INFO) {
 System.out.println("Buildfile: " + buildFile);

***
Bear Stearns is not responsible for any recommendation, solicitation, 
offer or agreement or any information about any transaction, customer 
account or account activity contained in this communication.
***

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [DISCUSS] release Ivy 2.0.0-beta2?

[Adrian Sandor]

Xavier Hanin wrote:

> The cache element under the caches element is parsed automatically using
> the
> same logic as Ant tasks, using the Configurator class. At the beginning of
> the XmlSettingsParser class you have an array of configuration elements,
> including caches, which tells Ivy should auto configure the children. Then
> there'sa typdef.properties making the mapping between the "cache" element
> name and the DefaultRepositoryCacheManager class. But I suggest putting a
> breakpoint in the setName of this class and run a unit test doing some
> settings loading with cache related information, you'll better see what's
> happening.


Oh, I see now. It's a bit like Spring beans defined in xml.
I wonder why not all elements are parsed/configured in the same way. The
behavior is different too, e.g. undocumented attributes on the "caches"
element are ignored, but on the "cache" element they cause various errors.
 is particularly interesting.
Anyway, thanks and sorry for the confusion :)

Adrian

DO NOT REPLY [Bug 42275] - running ant off a network share can cause Ant to fail

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=42275


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2008-02-14 13:34 ---
doing \\somesystem\ant\bin\ant -version 
-using 2/14/08 nightly (1.8.0alpha)

java.lang.ClassNotFoundException: org.apache.tools.ant.Main
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at org.apache.tools.ant.launch.Launcher.run(Launcher.java:255)
at org.apache.tools.ant.launch.Launcher.main(Launcher.java:104)

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Bug 43234

[Stephen Wrathall]

Dear Sir/Madam,
 
I am experiencing the exact same problems as described in this bug
(43234: Get random failure after multiple sshexec calls: Remote command
failed with exit status -1).
This bug was submitted on 2007-08-29, so I was wondering if there is any
fix/workaround available?
 
I'm currently using ant 1.6.2, and jsch-0.1.36.jar. I've looked through
the release documents for jsch-0.1.37.jar, and ant 1.7.0 and haven't
been able to find anything related to the fixing of this problem. Any
help would be much appreciated because it's very frustrating when
sshexec calls only work intermittently.
 
Regards,
Stephen Wrathall.
 
 

NOTICE
This e-mail and any attachments are confidential and may contain copyright 
material of Macquarie Group Limited or third parties. If you are not the 
intended recipient of this email you should not read, print, re-transmit, store 
or act in reliance on this e-mail or any attachments, and should destroy all 
copies of them. Macquarie Group Limited does not guarantee the integrity of any 
emails or any attached files. The views or opinions expressed are the author's 
own and may not reflect the views or opinions of Macquarie Group Limited.

Re: Bug 43234

[Atsuhiko Yamanaka]

Hi,

2008/2/15, Stephen Wrathall <[EMAIL PROTECTED]>:
>  I am experiencing the exact same problems as described in this bug
>  (43234: Get random failure after multiple sshexec calls: Remote command
>  failed with exit status -1).
>  This bug was submitted on 2007-08-29, so I was wondering if there is any
>  fix/workaround available?
>

I think that it is the dup of Bug 43092.

Please refer to
  http://issues.apache.org/bugzilla/show_bug.cgi?id=43092

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]