Hi Alessandra On 03.04.2012, at 08:31, Alessandra Donnini wrote:
> I don't know if the error is the same, but I tried to build stanbol from > scratch two times and I had the same attached error. the log also includes failures while executing the Entityhub Indexing tools. Those might be related to the error Andreas Kuckartz is experiencing. > It seems that build process went in a loop in: > ... > 1359474 [main] INFO > org.apache.stanbol.commons.testing.stanbol.StanbolTestBase - Got > HttpHostConnectException at http://localhost:8765/ - will retry > ... > > After a lot of retry I interrupted it with ctrl-C and it finished but id > doesn't work properly. Regarding the failure of the final Stanbol build contained in the log. Your log files notes: This is actually a tricky one. I think this is a combination of: * https://issues.apache.org/jira/browse/EXEC-54 * http://stackoverflow.com/questions/5569591/unable-to-access-jarfile-in-linux-land Workaround: ================== * rename the "text mining" directory to "text-mining" Details about this Error: ================== So basically the Apache Commons Exec quotes the parameter with the Jar file, but the executed java can not deal with the quoted file path. See this line in the log Unable to access jarfile "/Users/ale/Documents/text mining/stanbol/stanbol/stanbol/integration-tests/target/dependency/org.apache.stanbol.launchers.full-0.9.0-incubating-SNAPSHOT.jar" and compare it to the result of a call to java -jar doesnotexist.jar this prints Unable to access jarfile doesnotexist.jar showing that the logging of the JVM does not include the "{path}" When you try java -jar "doesnotexist withSpace.jar" the result is Unable to access jarfile doesnotexist withSpace.jar sill without spaces, because the bash pre-processes the command and replaces the quoted parameter with the escaped one. However if you call the same via the Apache Commons Exec there is no bash that does this job and the java process itself has also no support for it. How to reslove: ============ Not completely sure yet. * I think I should add this findings as comment to EXEC-54. * I could try to handle quoting myself and call CommandLine.addArgument(escape(jarToExecute.getAbsolutePath()),false) but I was not able to find a library that supports operating system specific escaping and implementing something myself feels worse as the current situation. any suggestions? best Rupert On 03.04.2012, at 08:31, Alessandra Donnini wrote: > I don't know if the error is the same, but I tried to build stanbol from > scratch two times and I had the same attached error. > It seems that build process went in a loop in: > ... > 1359474 [main] INFO > org.apache.stanbol.commons.testing.stanbol.StanbolTestBase - Got > HttpHostConnectException at http://localhost:8765/ - will retry > ... > > After a lot of retry I interrupted it with ctrl-C and it finished but id > doesn't work properly. > ciao > Alessandra > > <errorLog.txt.zip> > > > Il giorno 03/apr/2012, alle ore 07.17, Andreas Kuckartz ha scritto: > >> I could reproduce the build error and found out when it happens. >> >> The first "mvn install" failed and a second one immediately after that >> succeeded. >> >> I have appended logs. >> >> Cheers, >> Andreas >> --- >> >> On 01.04.2012 20:52, Andreas Kuckartz wrote: >>> On 01.04.2012 10:15, Rupert Westenthaler wrote: >>>> Can you please check the bundle (jar file) >>>> >>>> >>> data/sites/dbpedia/target/org.apache.stanbol.data.sites.dbpedia-1.0.3-incubating-SNAPSHOT.jar >>>> it should be about 46MByte in size. >>> That file exists and the same folder also contains a file named >>> >>> >>> org.apache.stanbol.data.sites.dbpedia-1.0.3-incubating-SNAPSHOT-sources.jar >>> >>> which is a little bit (about 5KB) smaller. >>> >>>> If this does not solve the problem It would be very helpful if you >>>> could provide the whole console log of the failing unit tests for the >>>> "/entityhub/ldpath". >>> I just executed the steps again and now all tests succeeded. >>> >>> Strange, maybe the error was a result of a network snafu? >>> >>>> In principle skipping clean should be no >>>> problem as long as you do not change the source. >>>> ... >>>> NOTE: that a "svn up" is also considered as a change if the source. >>> So even a change of one line of source code makes a complete rebuild >>> necessary. I would prefer to be able to do an incremental build. Would >>> that be possible with Maven with reasonable effort? >>> >>> (The answer seems to be no, but maybe someone has an idea. Seems to be >>> one reason why some people prefer Gradle. I used "make" in a distant >>> past and as far as I remember incremental builds never were a problem >>> with that old tool ;-) >>> >>> Cheers, >>> Andreas >>> >>> >>> >> <logs.zip> >
