date:20140424

[exec] Execution fails with quoted arguments

2014-04-24 Thread Paulo Roberto Massa Cereda


Dear friends,

For some time, I was sure issue #54 
(https://issues.apache.org/jira/browse/EXEC-54) was the culprit of one 
my programs misbehaving. Today, I decided to devote some time in 
understanding what's been happening in my code and apparently issue #54 
does not appear to be culprit here!


Here's a sample code that might explain what's happening. Note that I 
use two programs here (pdflatex and bibtex, hopefully available from any 
recent TeX distribution), and similar expansions lead to different 
results. Apologies for the long code excerpt.


===
@Test
public void testCommonsExecExecution() throws IOException, 
InterruptedException {

String program = bibtex;
String argument = file with spaces.aux;
CommandLine line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [bibtex, \file with 
spaces.aux\]);


DefaultExecuteResultHandler resultHandler = new 
DefaultExecuteResultHandler();

ByteArrayOutputStream out = new ByteArrayOutputStream();
PumpStreamHandler streamHandler = new PumpStreamHandler(out, out);

DefaultExecutor executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// bibtex is executed with file with spaces.aux.aux,
// which is not what I expected
assertEquals(out.toString(), I couldn't open file name `\file 
with spaces.aux\.aux'\n);


program = pdflatex;
argument = file with spaces.tex;

line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [pdflatex, \file with 
spaces.tex\]);


resultHandler = new DefaultExecuteResultHandler();
out = new ByteArrayOutputStream();
streamHandler = new PumpStreamHandler(out, out);

executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// here, pdflatex works with file with spaces.tex
assertTrue(out.toString().contains(! I can't find file `\file 
with spaces.tex\'.));


}
===

Note that Exec has both

[ bibtex, file with spaces.aux ]
[ pdflatex, file with spaces.tex ]

parsed correctly, but only the latter execution is properly done. Now 
I'm not sure if it's even Exec's fault, but what strikes me is the fact 
that with pdflatex, the execution works.


Maybe I'm missing something obvious. Could you guys shed some light into 
this problem?


All the best,

Paulo

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [exec] Execution fails with quoted arguments

2014-04-24 Thread Siegfried Goeschl


Hi Paulo,

some stupid thought and it might not even be related to your problem

aux is under Windows a reserved and can't be used as file name - see 
http://en.wikipedia.org/wiki/Filename - are you running the stuff under 
WIndows?


Is it possible to rename the offending file to something different then 
.aux


Cheers,

Siegfried Goeschl

On 24.04.14 14:36, Paulo Roberto Massa Cereda wrote:

Dear friends,

For some time, I was sure issue #54 
(https://issues.apache.org/jira/browse/EXEC-54) was the culprit of one 
my programs misbehaving. Today, I decided to devote some time in 
understanding what's been happening in my code and apparently issue 
#54 does not appear to be culprit here!


Here's a sample code that might explain what's happening. Note that I 
use two programs here (pdflatex and bibtex, hopefully available from 
any recent TeX distribution), and similar expansions lead to different 
results. Apologies for the long code excerpt.


===
@Test
public void testCommonsExecExecution() throws IOException, 
InterruptedException {

String program = bibtex;
String argument = file with spaces.aux;
CommandLine line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [bibtex, \file with 
spaces.aux\]);


DefaultExecuteResultHandler resultHandler = new 
DefaultExecuteResultHandler();

ByteArrayOutputStream out = new ByteArrayOutputStream();
PumpStreamHandler streamHandler = new PumpStreamHandler(out, 
out);


DefaultExecutor executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// bibtex is executed with file with spaces.aux.aux,
// which is not what I expected
assertEquals(out.toString(), I couldn't open file name 
`\file with spaces.aux\.aux'\n);


program = pdflatex;
argument = file with spaces.tex;

line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [pdflatex, \file with 
spaces.tex\]);


resultHandler = new DefaultExecuteResultHandler();
out = new ByteArrayOutputStream();
streamHandler = new PumpStreamHandler(out, out);

executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// here, pdflatex works with file with spaces.tex
assertTrue(out.toString().contains(! I can't find file 
`\file with spaces.tex\'.));


}
===

Note that Exec has both

[ bibtex, file with spaces.aux ]
[ pdflatex, file with spaces.tex ]

parsed correctly, but only the latter execution is properly done. Now 
I'm not sure if it's even Exec's fault, but what strikes me is the 
fact that with pdflatex, the execution works.


Maybe I'm missing something obvious. Could you guys shed some light 
into this problem?


All the best,

Paulo

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org




-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [exec] Execution fails with quoted arguments

2014-04-24 Thread Paulo Roberto Massa Cereda


Hello Siegfried!

Wow, thanks for the fast response. :)

Deeply sorry, I forgot to mention the environment. I'm running my code 
under Linux (Fedora 20, Java 1.7.0) and MacOSX (Mavericks, 10.9.2). I 
was unaware of the .aux thing under Windows, it's good to know about it; 
TeX tools use .aux files all the time, so it might be interesting to 
investigate some side effects from it. :)


Apparently, the error persists with other tool named makeglossaries that 
also uses this .aux file. I'm starting to get scared. :)


All the best,

Paulo

Em 24-04-2014 09:50, Siegfried Goeschl escreveu:

Hi Paulo,

some stupid thought and it might not even be related to your problem

aux is under Windows a reserved and can't be used as file name - see
http://en.wikipedia.org/wiki/Filename - are you running the stuff under
WIndows?

Is it possible to rename the offending file to something different then
.aux

Cheers,

Siegfried Goeschl

On 24.04.14 14:36, Paulo Roberto Massa Cereda wrote:

Dear friends,

For some time, I was sure issue #54
(https://issues.apache.org/jira/browse/EXEC-54) was the culprit of one
my programs misbehaving. Today, I decided to devote some time in
understanding what's been happening in my code and apparently issue
#54 does not appear to be culprit here!

Here's a sample code that might explain what's happening. Note that I
use two programs here (pdflatex and bibtex, hopefully available from
any recent TeX distribution), and similar expansions lead to different
results. Apologies for the long code excerpt.

===
@Test
public void testCommonsExecExecution() throws IOException,
InterruptedException {
String program = bibtex;
String argument = file with spaces.aux;
CommandLine line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [bibtex, \file with
spaces.aux\]);

DefaultExecuteResultHandler resultHandler = new
DefaultExecuteResultHandler();
ByteArrayOutputStream out = new ByteArrayOutputStream();
PumpStreamHandler streamHandler = new PumpStreamHandler(out,
out);

DefaultExecutor executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// bibtex is executed with file with spaces.aux.aux,
// which is not what I expected
assertEquals(out.toString(), I couldn't open file name
`\file with spaces.aux\.aux'\n);

program = pdflatex;
argument = file with spaces.tex;

line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [pdflatex, \file with
spaces.tex\]);

resultHandler = new DefaultExecuteResultHandler();
out = new ByteArrayOutputStream();
streamHandler = new PumpStreamHandler(out, out);

executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// here, pdflatex works with file with spaces.tex
assertTrue(out.toString().contains(! I can't find file
`\file with spaces.tex\'.));

}
===

Note that Exec has both

[ bibtex, file with spaces.aux ]
[ pdflatex, file with spaces.tex ]

parsed correctly, but only the latter execution is properly done. Now
I'm not sure if it's even Exec's fault, but what strikes me is the
fact that with pdflatex, the execution works.

Maybe I'm missing something obvious. Could you guys shed some light
into this problem?

All the best,

Paulo

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org





-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [exec] Execution fails with quoted arguments

2014-04-24 Thread Siegfried Goeschl


Hi Pauolo,

sorry for the next dumb question (but I'm actually quite good at it)

* what is the result of the failed bibtex invocation?

* is bibtex a native binary or a shell script?

* depending on the error - can you replace the bibtex with a shell 
script to dump the current working directory - sometime the things are 
not executing where you expect them (just battled Java-native launchers 
where the current working directory can't be set


Cheers,

Siegfried Goeschl

On 24.04.14 15:07, Paulo Roberto Massa Cereda wrote:

Hello Siegfried!

Wow, thanks for the fast response. :)

Deeply sorry, I forgot to mention the environment. I'm running my code
under Linux (Fedora 20, Java 1.7.0) and MacOSX (Mavericks, 10.9.2). I
was unaware of the .aux thing under Windows, it's good to know about it;
TeX tools use .aux files all the time, so it might be interesting to
investigate some side effects from it. :)

Apparently, the error persists with other tool named makeglossaries that
also uses this .aux file. I'm starting to get scared. :)

All the best,

Paulo

Em 24-04-2014 09:50, Siegfried Goeschl escreveu:

Hi Paulo,

some stupid thought and it might not even be related to your problem

aux is under Windows a reserved and can't be used as file name - see
http://en.wikipedia.org/wiki/Filename - are you running the stuff under
WIndows?

Is it possible to rename the offending file to something different then
.aux

Cheers,

Siegfried Goeschl

On 24.04.14 14:36, Paulo Roberto Massa Cereda wrote:

Dear friends,

For some time, I was sure issue #54
(https://issues.apache.org/jira/browse/EXEC-54) was the culprit of one
my programs misbehaving. Today, I decided to devote some time in
understanding what's been happening in my code and apparently issue
#54 does not appear to be culprit here!

Here's a sample code that might explain what's happening. Note that I
use two programs here (pdflatex and bibtex, hopefully available from
any recent TeX distribution), and similar expansions lead to different
results. Apologies for the long code excerpt.

===
@Test
public void testCommonsExecExecution() throws IOException,
InterruptedException {
String program = bibtex;
String argument = file with spaces.aux;
CommandLine line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [bibtex, \file with
spaces.aux\]);

DefaultExecuteResultHandler resultHandler = new
DefaultExecuteResultHandler();
ByteArrayOutputStream out = new ByteArrayOutputStream();
PumpStreamHandler streamHandler = new PumpStreamHandler(out,
out);

DefaultExecutor executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// bibtex is executed with file with spaces.aux.aux,
// which is not what I expected
assertEquals(out.toString(), I couldn't open file name
`\file with spaces.aux\.aux'\n);

program = pdflatex;
argument = file with spaces.tex;

line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [pdflatex, \file with
spaces.tex\]);

resultHandler = new DefaultExecuteResultHandler();
out = new ByteArrayOutputStream();
streamHandler = new PumpStreamHandler(out, out);

executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// here, pdflatex works with file with spaces.tex
assertTrue(out.toString().contains(! I can't find file
`\file with spaces.tex\'.));

}
===

Note that Exec has both

[ bibtex, file with spaces.aux ]
[ pdflatex, file with spaces.tex ]

parsed correctly, but only the latter execution is properly done. Now
I'm not sure if it's even Exec's fault, but what strikes me is the
fact that with pdflatex, the execution works.

Maybe I'm missing something obvious. Could you guys shed some light
into this problem?

All the best,

Paulo

-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org






-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [exec] Execution fails with quoted arguments

2014-04-24 Thread Paulo Roberto Massa Cereda


Hello Siegfried,

 sorry for the next dumb question (but I'm actually quite good at it)

Don't say such thing, you are helping me a lot with these questions. :)

There we go:

 * what is the result of the failed bibtex invocation?

The message prompted is

-
I couldn't open file name `file with spaces.aux.aux'
-

And the program returns 1 as exit value.

If I copy file with spaces.aux and rename it to 
filewithnospaces.aux, I get


-
This is BibTeX, Version 0.99d (TeX Live 2013)
The top-level auxiliary file: filewithnospaces.aux
The style file: plain.bst
Database file #1: master.bib
Warning--I didn't find a database entry for with:1977
(There was 1 warning)
-

And the program returns 0 as exit value.

 * is bibtex a native binary or a shell script?

Native binary.

paulo@alexandria ~$ file `which bibtex`
/opt/texbin/bibtex: ELF 32-bit LSB executable, Intel 80386, version 1 
(SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped


 * depending on the error - can you replace the bibtex with a shell
 script to dump the current working directory - sometime the things
 are not executing where you expect them (just battled Java-native
 launchers where the current working directory can't be set

I replaced bibtex with a script that prints $PWD and the provided 
arguments. I got


Current directory ($PWD):
/home/paulo/Projetos/commons-exec-report

Arguments:
file with spaces.aux
Done.

with 0 as exit value.

Quite odd, isn't it? :) It's driving me crazy. Well, crazier. :P

All the best,

Paulo

Em 24-04-2014 10:14, Siegfried Goeschl escreveu:

Hi Pauolo,

sorry for the next dumb question (but I'm actually quite good at it)

* what is the result of the failed bibtex invocation?

* is bibtex a native binary or a shell script?

* depending on the error - can you replace the bibtex with a shell
script to dump the current working directory - sometime the things are
not executing where you expect them (just battled Java-native launchers
where the current working directory can't be set

Cheers,

Siegfried Goeschl

On 24.04.14 15:07, Paulo Roberto Massa Cereda wrote:

Hello Siegfried!

Wow, thanks for the fast response. :)

Deeply sorry, I forgot to mention the environment. I'm running my code
under Linux (Fedora 20, Java 1.7.0) and MacOSX (Mavericks, 10.9.2). I
was unaware of the .aux thing under Windows, it's good to know about it;
TeX tools use .aux files all the time, so it might be interesting to
investigate some side effects from it. :)

Apparently, the error persists with other tool named makeglossaries that
also uses this .aux file. I'm starting to get scared. :)

All the best,

Paulo

Em 24-04-2014 09:50, Siegfried Goeschl escreveu:

Hi Paulo,

some stupid thought and it might not even be related to your problem

aux is under Windows a reserved and can't be used as file name - see
http://en.wikipedia.org/wiki/Filename - are you running the stuff under
WIndows?

Is it possible to rename the offending file to something different then
.aux

Cheers,

Siegfried Goeschl

On 24.04.14 14:36, Paulo Roberto Massa Cereda wrote:

Dear friends,

For some time, I was sure issue #54
(https://issues.apache.org/jira/browse/EXEC-54) was the culprit of one
my programs misbehaving. Today, I decided to devote some time in
understanding what's been happening in my code and apparently issue
#54 does not appear to be culprit here!

Here's a sample code that might explain what's happening. Note that I
use two programs here (pdflatex and bibtex, hopefully available from
any recent TeX distribution), and similar expansions lead to different
results. Apologies for the long code excerpt.

===
@Test
public void testCommonsExecExecution() throws IOException,
InterruptedException {
String program = bibtex;
String argument = file with spaces.aux;
CommandLine line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [bibtex, \file with
spaces.aux\]);

DefaultExecuteResultHandler resultHandler = new
DefaultExecuteResultHandler();
ByteArrayOutputStream out = new ByteArrayOutputStream();
PumpStreamHandler streamHandler = new PumpStreamHandler(out,
out);

DefaultExecutor executor = new DefaultExecutor();
executor.setStreamHandler(streamHandler);
executor.execute(line, resultHandler);
resultHandler.waitFor();

// bibtex is executed with file with spaces.aux.aux,
// which is not what I expected
assertEquals(out.toString(), I couldn't open file name
`\file with spaces.aux\.aux'\n);

program = pdflatex;
argument = file with spaces.tex;

line = new CommandLine(program);
line.addArgument(argument);

// so far, everything ok
assertEquals(line.toString(), [pdflatex, \file with

Re: [collections] Problems compiling w/gentoo

2014-04-24 Thread Emmanuel Bourg

Commons Collections 3.x doesn't compile with Java 8, there is a conflict
with the new methods added to the Map interface. You may want to apply
this patch used in Debian or switch to the version 4.

http://sources.debian.net/src/libcommons-collections3-java/3.2.1-7/debian/patches/java8-compatibility.patch

Emmanuel Bourg


Le 18/04/2014 23:45, tenspd137 . a écrit :
 Hi all -
 
 I am using gentoo to install common-collections-3.2.1.  I keep getting
 errors like:
 
 Buildfile:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build.xml
 
 init:
  [echo]  commons-collections 3.2.1 
 
 prepare:
 [mkdir] Created dir:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build
 
 compile:
 [mkdir] Created dir:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build/classes
 [javac] Compiling 273 source files to
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build/classes
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/MultiHashMap.java:334:
 error: remove(Object,Object) in MultiHashMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key, Object item) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/MultiMap.java:69:
 error: remove(Object,Object) in MultiMap clashes with remove(Object,Object)
 in Map
 [javac] public Object remove(Object key, Object item);
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:200:
 error: remove(Object,Object) in MultiKeyMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key1, Object key2) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:156:
 error: remove(Object,Object) in MultiValueMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key, Object value) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac] 4 errors
 
 Any thoughts why this might be occurring?
 
 Thanks!
 
 -Collin
 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [collections] Problems compiling w/gentoo

2014-04-24 Thread Gary Gregory

Should we fix 3.x for Java 8 and release?

Gary

div Original message /divdivFrom: Emmanuel Bourg 
ebo...@apache.org /divdivDate:04/24/2014  13:45  (GMT-05:00) 
/divdivTo: Commons Users List user@commons.apache.org /divdivSubject: 
Re: [collections] Problems compiling w/gentoo /divdiv
/divCommons Collections 3.x doesn't compile with Java 8, there is a conflict
with the new methods added to the Map interface. You may want to apply
this patch used in Debian or switch to the version 4.

http://sources.debian.net/src/libcommons-collections3-java/3.2.1-7/debian/patches/java8-compatibility.patch

Emmanuel Bourg


Le 18/04/2014 23:45, tenspd137 . a écrit :
 Hi all -
 
 I am using gentoo to install common-collections-3.2.1.  I keep getting
 errors like:
 
 Buildfile:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build.xml
 
 init:
  [echo]  commons-collections 3.2.1 
 
 prepare:
 [mkdir] Created dir:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build
 
 compile:
 [mkdir] Created dir:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build/classes
 [javac] Compiling 273 source files to
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build/classes
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/MultiHashMap.java:334:
 error: remove(Object,Object) in MultiHashMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key, Object item) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/MultiMap.java:69:
 error: remove(Object,Object) in MultiMap clashes with remove(Object,Object)
 in Map
 [javac] public Object remove(Object key, Object item);
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:200:
 error: remove(Object,Object) in MultiKeyMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key1, Object key2) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:156:
 error: remove(Object,Object) in MultiValueMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key, Object value) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac] 4 errors
 
 Any thoughts why this might be occurring?
 
 Thanks!
 
 -Collin
 


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

Re: [collections] Problems compiling w/gentoo

2014-04-24 Thread sebb

On 24 April 2014 19:29, Gary Gregory garydgreg...@gmail.com wrote:
 Should we fix 3.x for Java 8 and release?

The fix works by renaming a public method so IMO is not appropriate for 3.x.

It would break any existing code that used the remove method,
requiring the user to edit their source and rebuild.

AFAICT there is no nice solution here.

I think we will just have to accept that 3.x cannot be used on Java 8.
Seems to me that is better than breaking existing use of the library.

 Gary

 div Original message /divdivFrom: Emmanuel Bourg 
 ebo...@apache.org /divdivDate:04/24/2014  13:45  (GMT-05:00) 
 /divdivTo: Commons Users List user@commons.apache.org 
 /divdivSubject: Re: [collections] Problems compiling w/gentoo /divdiv
 /divCommons Collections 3.x doesn't compile with Java 8, there is a conflict
 with the new methods added to the Map interface. You may want to apply
 this patch used in Debian or switch to the version 4.

 http://sources.debian.net/src/libcommons-collections3-java/3.2.1-7/debian/patches/java8-compatibility.patch

 Emmanuel Bourg


 Le 18/04/2014 23:45, tenspd137 . a écrit :
 Hi all -

 I am using gentoo to install common-collections-3.2.1.  I keep getting
 errors like:

 Buildfile:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build.xml

 init:
  [echo]  commons-collections 3.2.1 

 prepare:
 [mkdir] Created dir:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build

 compile:
 [mkdir] Created dir:
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build/classes
 [javac] Compiling 273 source files to
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/build/classes
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/MultiHashMap.java:334:
 error: remove(Object,Object) in MultiHashMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key, Object item) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/MultiMap.java:69:
 error: remove(Object,Object) in MultiMap clashes with remove(Object,Object)
 in Map
 [javac] public Object remove(Object key, Object item);
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/map/MultiKeyMap.java:200:
 error: remove(Object,Object) in MultiKeyMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key1, Object key2) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac]
 /var/tmp/portage/dev-java/commons-collections-3.2.1/work/commons-collections-3.2.1-src/src/java/org/apache/commons/collections/map/MultiValueMap.java:156:
 error: remove(Object,Object) in MultiValueMap cannot implement
 remove(Object,Object) in Map
 [javac] public Object remove(Object key, Object value) {
 [javac]   ^
 [javac]   return type Object is not compatible with boolean
 [javac] 4 errors

 Any thoughts why this might be occurring?

 Thanks!

 -Collin



 -
 To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
 For additional commands, e-mail: user-h...@commons.apache.org


-
To unsubscribe, e-mail: user-unsubscr...@commons.apache.org
For additional commands, e-mail: user-h...@commons.apache.org

[exec] DefaultExecutor PumpStreamHandler and windows command prompt

2014-04-24 Thread Alexander Prishchepov

Hello, All.

I am starting new process with DefaultExecutor like that:
--
    DefaultExecutor executor = new DefaultExecutor();
    executor.setStreamHandler(new PumpStreamHandler(System.out, 
System.err, System.in));
    executor.execute(some command line);
--

Everything works great, but somehow in windows command prompt input is not 
visible right away - only after Enter is pressed.
Any idea, why that might happen?

Tested it on unix (Solaris), and it does not happen - input is visible as I 
type.

Regards,
   AlexP

[exec] Execution fails with quoted arguments

Re: [exec] Execution fails with quoted arguments

Re: [exec] Execution fails with quoted arguments

Re: [exec] Execution fails with quoted arguments

Re: [exec] Execution fails with quoted arguments

Re: [collections] Problems compiling w/gentoo

Re: [collections] Problems compiling w/gentoo

Re: [collections] Problems compiling w/gentoo

[exec] DefaultExecutor PumpStreamHandler and windows command prompt

9 matches

Site Navigation

Mail list logo

Footer information