Yeah, that could possibly be an issue. Can you try setting the repository and the index paths to their absolute paths then try searching again?
Thanks, Deng On Mon, May 12, 2014 at 9:36 PM, Bryan Stenson <[email protected]>wrote: > ooh - getting closer to something! > > The repository index directory (according to the web UI) is: > ./repositories/internal/.indexer > > But on disk, that directory actually exists here: > > apache-archiva-2.0.1/repositories/repositories/internal/repositories/internal/.indexer > > The artifacts actually exist in: > apache-archiva-2.0.1/repositories/internal/ > > It looks like the current directory (".") is being evaluated differently by > the indexer and the process consuming the index... > > ----- > > I've uncommented the log4j entries and set them all to "debug", but am > still not seeing ANY concerning stack traces regarding indexing or > searching. > > ---- > > I've tried force re-indexing. While this appears to accurately re-index (I > can see all files in the .indexer get their timestamp updated), the index > itself remains unavailable to quickSearch (still getting an empty array > "[]" for all search results). > > Bryan > > > On Sun, May 11, 2014 at 10:57 PM, Deng Ching-Mallete <[email protected] > >wrote: > > > Hi Bryan, > > > > Hmm, some of the logging config for Archiva packages are commented out in > > the log config. You might need to uncomment them as well :) > > > > Index files for the repository should have been created. Can you check if > > they are present? The path to the indexer is set in the Index Directory > > field in repo config page. Please check if the path is resolvable as well > > :) > > > > Another thing you can do is to re-index the repository. Just select the > > 'Index Scanning' option in the Actions for the repo, then tick 'Process > All > > Artifacts'. > > > > > > -Deng > > > > > > > > On Mon, May 12, 2014 at 1:25 PM, Bryan Stenson <[email protected] > > >wrote: > > > > > Hi Deng - > > > > > > Thanks for the response. I can confirm that the "index-content" > consumer > > > IS enabled (appears to be by default, as I did not change anything > here). > > > I've scoured the logs, but can only find a single entry for when junit > > was > > > added to the repo in the archiva-audit.log: > > > > > > "2014-05-11 22:03:09 internal admin 0:0:0:0:0:0:0:1 > > > "junit/junit/3.8.1/junit-3.8.1.jar" "Created File (proxied)" > > > > > > With no other indication of failure, I remain stumped as to why is > > DOESN'T > > > work. :( > > > > > > I'm trying to gather more info, but setting log levels to "debug" in > > > 'apps/archiva/WEB-INF/classes/log4j2.xml' doesn't seem to have much > > affect. > > > :( > > > > > > Any other suggestions? > > > > > > BTW - here's my java details (I've not yet tried another java - seems > > crazy > > > that, without some dirty stacktrace, this is even a valid > suspicion...): > > > > > > java version "1.8.0_05" > > > Java(TM) SE Runtime Environment (build 1.8.0_05-b13) > > > Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) > > > > > > > > > Bryan > > > >
