Hi
On Thu, Oct 18, 2012 at 10:35 AM, Suat Gonul <[email protected]> wrote:
> Thanks Rupert.
>
> I was thinking that "mvn clean" would delete the files. Manually
> removing that folder solved the problem.
>
No "mvn clean" intensionally does NOT delete those files to avoid
re-downloading them again and again. However this can be easily
changed by an according configuration.
best
RUpert
> Best,
> Suat
>
> On 10/18/2012 10:34 AM, Rupert Westenthaler wrote:
>> Hi Suat
>>
>> in the module of the dbpedia default dataset there should be a
>> download folder containing the file downloaded form the server.
>> Deleting that folder will trigger the re-download of that file.
>> This is also the best way to check if the file is actually corrupted.
>>
>> You can find the folder at
>>
>> {stanbol-trunk}/data/sites/dbpedia/download
>>
>> best
>> Rupert
>>
>> On Wed, Oct 17, 2012 at 6:19 PM, Suat Gonul <[email protected]> wrote:
>>> Hi Rupert,
>>>
>>> I have a similar problem but I am not sure it is related with the
>>> situation here. Here is the exception I get:
>>>
>>> 17.10.2012 18:51:59.930 *ERROR* [Thread-47]
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl
>>> IOException while activating Index 'default:dbpedia'!
>>> java.io.IOException: Unable to copy Data for index 'dbpedia' (server
>>> 'default')
>>> at
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.updateCore(ManagedSolrServerImpl.java:779)
>>> at
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl$IndexUpdateDaemon.run(ManagedSolrServerImpl.java:1162)
>>> Caused by: java.io.IOException: Truncated ZIP file
>>> at
>>> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.readDeflated(ZipArchiveInputStream.java:389)
>>> at
>>> org.apache.commons.compress.archivers.zip.ZipArchiveInputStream.read(ZipArchiveInputStream.java:322)
>>> at java.io.InputStream.read(InputStream.java:101)
>>> at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025)
>>> at org.apache.commons.io.IOUtils.copy(IOUtils.java:999)
>>> at
>>> org.apache.stanbol.commons.solr.utils.ConfigUtils.copyArchiveEntry(ConfigUtils.java:539)
>>> at
>>> org.apache.stanbol.commons.solr.utils.ConfigUtils.copyCore(ConfigUtils.java:497)
>>> at
>>> org.apache.stanbol.commons.solr.managed.impl.ManagedSolrServerImpl.updateCore(ManagedSolrServerImpl.java:777)
>>>
>>>
>>> I tried deleting the stanbol directory inside the .m2 and even the .m2
>>> itself, however I still get this exception. Do you have any idea why
>>> this happens?
>>>
>>> Best,
>>> Suat
>>>
>>> On 10/10/2012 3:49 PM, Rupert Westenthaler wrote:
>>>> Hi all,
>>>>
>>>> during the Apache Stanbol build process some files (DBpedia default
>>>> index, OpenNLP models) are downloaded from dev.iks-project.eu. Since
>>>> the last week it happens that those files are corrupted. We do not
>>>> know the reason for that as the Apache2 logs of the dev.iks-project.eu
>>>> do not point to any problems. This is also the reason for a lot of
>>>> unstable Jenkins build on the last week.
>>>>
>>>> Users that are affected by this should see "java.io.EOFException"s in
>>>> their logs. Affected files are located in the
>>>> "{stanbol-trunk}/data/{module-path}/download/resources" folders.
>>>> Deleted files will be re-downloaded on the next build. Because of that
>>>> deleting affected files and "mvm clean install" of the affected file
>>>> usually solves issues like that.
>>>>
>>>> best
>>>> Rupert
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Apache Jenkins Server <[email protected]>
>>>> Date: Wed, Oct 10, 2012 at 12:15 PM
>>>> Subject: Jenkins build became unstable: stanbol-trunk-1.6 #1068
>>>> To: [email protected], [email protected]
>>>>
>>>>
>>>> See <https://builds.apache.org/job/stanbol-trunk-1.6/1068/changes>
>>>>
>>>>
>>>>
>>
>>
>
--
| Rupert Westenthaler [email protected]
| Bodenlehenstraße 11 ++43-699-11108907
| A-5500 Bischofshofen
