On Mon, Apr 15, 2013 at 6:20 PM, [email protected] <[email protected]> wrote: > I'm trying to build a fresh instance of Stanbol from the latest code (to try > to resolve my issue) but I'm running into: > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.4:process (default) > on project org.apache.stanbol.enhancer.engines.metaxa: Error resolving > project artifact: Could not transfer artifact > org.semweb4j:rdf2go.api:pom:4.7.3 from/to aduna-opensource.releases > (http://repo.aduna-software.org/maven2/releases): repo.aduna-software.org for > project org.semweb4j:rdf2go.api:jar:4.7.3: Unknown host > repo.aduna-software.org -> [Help 1] > > Is anyone else having this problem with repo.aduna-software.org? >
The last few Jenkins builds had the exact same problem. I was thinking of waiting until tomorrow morning and if the maven server is still down I plan to exclude the metaxa engine from the default maven build. This is anyway an optional engine, as it is not included in any launcher configuration best Rupert > > --- > A. Soroka > The University of Virginia Library > > On Apr 14, 2013, at 7:02 AM, Rupert Westenthaler wrote: > >> Hi Soroka, >> >> I provided a fix to STANBOL-1023 with revision >> http://svn.apache.org/r1467763. While your problems seam not only to >> be caused by this you might want to test with the fix applied >> >> best >> Rupert >> >> On Fri, Apr 12, 2013 at 3:36 PM, [email protected] <[email protected]> >> wrote: >>> I tried restarting and waiting a good long while, as advised by Aaron >>> Coburn. Oddly, now all of the states appear correct in all of the tabs >>> (including under "Processed Resources - solrarchive"), but only one of the >>> indexes appears as a Referenced Site: Geonames, which is by _far_ the >>> larger index. >>> >>> I will start from a clean launch, turn the logging up to DEBUG, and run >>> through this process again. Then I will open the issue with the resulting >>> logs. >>> >>> Thanks for the help! >>> >>> --- >>> A. Soroka >>> The University of Virginia Library >>> >>> On Apr 12, 2013, at 9:11 AM, Rupert Westenthaler wrote: >>> >>>> On Fri, Apr 12, 2013 at 2:50 PM, [email protected] <[email protected]> >>>> wrote: >>>>> Indeed, under the "Processed Resources - solrarchive" header I find: >>>>> >>>>> LCSH.solrindex.properties >>>>> org.apache.stanbol.data.site.lcsh1365096986431/100 >>>>> bundleinstall:/LCSH.solrindex.ref IGNORED >>>>> >>>>> although also >>>>> >>>>> geonames.solrindex.properties >>>>> org.apache.stanbol.data.site.geonames1365097758733/100 >>>>> bundleinstall:/geonames.solrindex.ref INSTALLED >>>>> >>>>> and _neither_ of these indexes actually appear supporting EntityHub >>>>> endpoints. >>>>> >>>>> I will certainly reproduce this sequence (of installation) and open an >>>>> issue with attachments. Those would include the error.log and the running >>>>> log, but anything else? Should I try to turn up my logging level, or is >>>>> the default usually enough detail for a good error report? >>>>> >>>> >>>> A DEBUG level log file would be appreciated, but the actual error >>>> should be also present with the default log settings. >>>> >>>> best >>>> Rupert >>>> >>>>> Thank you! >>>>> >>>>> --- >>>>> A. Soroka >>>>> The University of Virginia Library >>>>> >>>>> On Apr 12, 2013, at 12:42 AM, Rupert Westenthaler wrote: >>>>> >>>>>> Hi >>>>>> >>>>>> On Thu, Apr 11, 2013 at 4:34 PM, [email protected] <[email protected]> >>>>>> wrote: >>>>>>> Thanks for the help so far! >>>>>>> >>>>>>> I don't see any lines of exactly the description you give-- that is, >>>>>>> one ending in "{name}.solrindex.ref". I do see several lines like the >>>>>>> following: >>>>>> >>>>>> They should be at the bottom of the page. blow the header "Processed >>>>>> Resources - solrarchive". If this section is missing it also indicated >>>>>> a problem (most likely that the o.a.s.commons.solr.install bundle is >>>>>> not active). >>>>>> >>>>>>> >>>>>>> bundleinstall:/org.apache.stanbol.entityhub.site.referencedSite-geonames.config >>>>>>> IGNORED >>>>>>> >>>>>> >>>>>> This would be indeed a problem, as it means that the service >>>>>> configuration of for the ReferencedSite got ignored. The reason for >>>>>> that should be in the error.log. >>>>>> >>>>>> I suggest that you open an issue and attach your log including the >>>>>> installation of the referenced sites. Without those information it is >>>>>> very hard to guess what is going wrong. >>>>>> >>>>>> best >>>>>> Rupert >>>>>> >>>>>> >>>>>>> Do you think that indicates the same problem? >>>>>>> >>>>>>> --- >>>>>>> A. Soroka >>>>>>> The University of Virginia Library >>>>>>> >>>>>>> On Apr 11, 2013, at 4:15 AM, Rupert Westenthaler wrote: >>>>>>> >>>>>>>> in that case most likely not ... >>>>>>>> >>>>>>>>>> Users can validate if they are affected by this by checking the "OSGI >>>>>>>>>> Installer" tab of the Felix Webconsole >>>>>>>>>> (http://{host}/system/console/osgi-installer). At the bottom you >>>>>>>>>> should see something like: >>>>>>>>>> >>>>>>>>>> bundleinstall:/{name}.solrindex.ref IGNORED >>>>>>>>>> >>>>>>>>>> If this line notes INSTALLED than you are not affected and the error >>>>>>>>>> is caused by something else. >>>>>>>>>> >>>>>>>> >>>>>>>> have you checked this? This is the best indication if your problem is >>>>>>>> related to STANBOL-1023 or not. >>>>>>>> >>>>>>>> If not it would be good if you could provide loggings from the >>>>>>>> installation process (staring from the moment when you installed the >>>>>>>> "o.a.s.data.sites.{name}" bundle to the OSGI environment. >>>>>>>> >>>>>>>> For testing it would be also good to have the index you created around >>>>>>>> - if you can share those. >>>>>>>> >>>>>>>> best >>>>>>>> Rupert >>>>>>>> >>>>>>>>>> As Workaround users need to stop/start the "o.a.s.data.sites.{name}" >>>>>>>>>> bundle as this will restart the installation process of the site. >>>>>>>>>> >>>>>>>>>> Note also that this only happens on the first startup after you >>>>>>>>>> copied >>>>>>>>>> the o.a.s.data.sites.{name} bundle to the fileinstall folder. Normal >>>>>>>>>> restarts of the server are not affected. Also installing a new site >>>>>>>>>> to >>>>>>>>>> a running server works as expected. >>>>>>>>>> >>>>>>>>>> In any other case you should see according Exceptions in the >>>>>>>>>> "stanbol/logs/error.logs" file. >>>>>>>>>> >>>>>>>>>> Note also that since STANBOL-996 ReferencedSites are only registered >>>>>>>>>> after that the SolrIndex with the data has been initialized. This >>>>>>>>>> means that - especially for larger indexes - it might take some time >>>>>>>>>> until the RESTful service becomes available. >>>>>>>>>> >>>>>>>>>> best >>>>>>>>>> Rupert >>>>>>>>>> >>>>>>>>>> On Tue, Apr 9, 2013 at 10:40 PM, [email protected] >>>>>>>>>> <[email protected]> >>>>>>>>>> wrote: >>>>>>>>>>> I've indexed a pair of RDF accretions for use with the Stanbol >>>>>>>>>>> EntityHub: >>>>>>>>>>> >>>>>>>>>>> 1) GeoNames, using the GeoNames indexer >>>>>>>>>>> 2) The Library of Congress Subject Heading system, using the >>>>>>>>>>> generic RDF >>>>>>>>>> indexer >>>>>>>>>>> >>>>>>>>>>> Everything went quite well. >>>>>>>>>>> >>>>>>>>>>> Now I've installed the data files in the appropriate directory in my >>>>>>>>>> Stanbol instance, and under the Data File Provider tab in the system >>>>>>>>>> console they appear with state ACTIVE. I've installed the >>>>>>>>>> corresponding >>>>>>>>>> bundles, and in the Bundles tab they appear with status Active. But >>>>>>>>>> they do >>>>>>>>>> not appear as available sites and the appropriate endpoints (e.g. >>>>>>>>>> /entityhub/site/geonames) don't respond (404). >>>>>>>>>>> >>>>>>>>>>> Any thoughts as to what I might be doing wrong? >>>>>>>>>>> >>>>>>>>>>> --- >>>>>>>>>>> A. Soroka >>>>>>>>>>> The University of Virginia Library >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> | Rupert Westenthaler [email protected] >>>>>>>>>> | Bodenlehenstraße 11 ++43-699-11108907 >>>>>>>>>> | A-5500 Bischofshofen >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> | Rupert Westenthaler [email protected] >>>>>>>> | Bodenlehenstraße 11 ++43-699-11108907 >>>>>>>> | A-5500 Bischofshofen >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> | Rupert Westenthaler [email protected] >>>>>> | Bodenlehenstraße 11 ++43-699-11108907 >>>>>> | A-5500 Bischofshofen >>>>> >>>> >>>> >>>> >>>> -- >>>> | Rupert Westenthaler [email protected] >>>> | Bodenlehenstraße 11 ++43-699-11108907 >>>> | A-5500 Bischofshofen >>> >> >> >> >> -- >> | Rupert Westenthaler [email protected] >> | Bodenlehenstraße 11 ++43-699-11108907 >> | A-5500 Bischofshofen > -- | Rupert Westenthaler [email protected] | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
