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>
>>
>
