On 08.04.2012, at 09:37, Andreas Kuckartz wrote:
> Hi Rupert,
>
> a further bit of information:
>
> I just deleted my directory .m2/repository/org/apache/stanbol/ then
> executed svn up, mvn clean and mvn install and *still* get those errors:
>
> Tests in error:
>
> testInversePath(org.apache.stanbol.entityhub.ldpath.backend.BackendTest):
> Unable
> to query for resources with value
> 'http://dbpedia.org/resource/Category:Harvard_University_alumni' on
> property 'http://www.w3.org/2004/02/skos/core#broader'!
>
> testSingleRepresentationBackend(org.apache.stanbol.entityhub.ldpath.backend.BackendTest):
> Error while getting SolrDocument for idhttp://dbpedia.org/resource/Paris
> testSetup(org.apache.stanbol.entityhub.ldpath.backend.BackendTest):
> Error while getting SolrDocument for idhttp://dbpedia.org/resource/Paris
>
> Anything else I can do?
>
After looking the third or fourth time over the logs I think I finally found
now the reason four your problem!
There are two unit test
* EntityhubLDPathTest
* BackendTest
both extend "LDPathTestBase" and in the @AfterClass of this base class I set
the SolrYard used for the test to NULL because of the the JVM calls
18534 [Finalizer] INFO org.apache.stanbol.entityhub.yard.solr.impl.SolrYard
- ... deactivating SolrYard DBpedia.org default data (id=dbpedia)
in the middle of executing the second UnitTest what causes the SolrCore to be
closed. Because of that all later requests of the second unit test (BackendTest
in your case) fail with
Caused by: org.apache.solr.common.SolrException: No such core: dbpedia_43k
Adding an explicit
yard.close();
to the @AfterClass of "LDPathTestBase" should solve this. I added this in
http://svn.apache.org/viewvc?rev=1310966&view=rev
can you please check if this solves your issue.
best
Rupert
> Cheers,
> Andreas
>
> On 04.04.2012 04:21, Andreas Kuckartz wrote:
>> Hi Rupert
>>
>> A set of files is attached for a failed "mvn install" (after "mvn clean"
>> and "svn update").
>>
>> Cheers,
>> Andreas
>> --
>>
>>
>> On 03.04.2012 13:28, Rupert Westenthaler wrote:
>>> Hi Andreas
>>>
>>> I am not able to reproduce your error. While I am able to reproduce the
>>> different versions of the initialization part of the test data for the unit
>>> tests of the entityhub/ldpath module by calling "mvn clean install" and
>>> "mvn install" in my case both variants succeed.
>>>
>>> Can you please provide the files in
>>> "/home/andreas/workspace/stanbol/entityhub/ldpath/target/surefire-reports"
>>> for the failing tests.
>>>
>>> best
>>> Rupert
>>>
>>> On 03.04.2012, at 07:17, Andreas Kuckartz wrote:
>>>
>>>> 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>
>>>
