Hi Alessandra This is expected if you use the stable launcher - you can safely ignore this (see also https://issues.apache.org/jira/browse/STANBOL-533)
BTW: I am currently fixing the other issue you experienced with the Indexing Tool (see https://issues.apache.org/jira/browse/STANBOL-568) thx for reporting best Rupert On 03.04.2012, at 11:45, Alessandra Donnini wrote: > Hi Rupert > I did what you said and the installation seems to work well. > But when I run, after install I have this error: > INFO: Initiating Jersey application, version 'Jersey: 1.12 02/15/2012 04:51 > PM' > ERROR: Bundle org.apache.stanbol.enhancer.engines.refactor [90]: Error > starting > slinginstall:org.apache.stanbol.enhancer.engines.refactor-0.9.0-incubating-SNAPSHOT.jar > (org.osgi.framework.BundleException: Unresolved constraint in bundle > org.apache.stanbol.enhancer.engines.refactor [90]: Unable to resolve 90.0: > missing requirement [90.0] package; > (package=org.apache.stanbol.ontologymanager.ontonet.api)) > org.osgi.framework.BundleException: Unresolved constraint in bundle > org.apache.stanbol.enhancer.engines.refactor [90]: Unable to resolve 90.0: > missing requirement [90.0] package; > (package=org.apache.stanbol.ontologymanager.ontonet.api) > at org.apache.felix.framework.Felix.resolveBundle(Felix.java:3443) > at org.apache.felix.framework.Felix.startBundle(Felix.java:1727) > at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1156) > at > org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:264) > at java.lang.Thread.run(Thread.java:680) > > and the system starts only with enhancer and entityhub components (for > instance content hub component is missing). > > Any suggestion? > thank > > Alessandra Donnini > Etcware s.r.l. via Etna 13 - 00141 Roma > [email protected] > mobile +39 333 8914865 > tel/fax 06 64495131 > > > > > > Il giorno 03/apr/2012, alle ore 10.39, Rupert Westenthaler ha scritto: > >> 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> >>> >> >
