Order of IndexCreator's passed to addIndexingContextForced affects whether
MavenPluginArtifactInfoIndexCreator has any effect
-----------------------------------------------------------------------------------------------------------------------------
Key: MINDEXER-34
URL: https://jira.codehaus.org/browse/MINDEXER-34
Project: Maven Indexer
Issue Type: Bug
Affects Versions: 4.1.0
Environment: JDK 6, Ubuntu, Maven 3.0.3; actually Indexer 4.1.1 but
that is not listed as an option here
Reporter: Jesse Glick
Priority: Critical
While working on a utility inside NetBeans to look up all plugins using a given
goal prefix, I found unreliable behavior. To investigate, I wrote a unit test
that used Maven Indexer (along with some NB helper classes) that:
1. Creates a fresh local repository.
2. Installs a trivial "plugin" ({{maven-plugin}} POM + JAR) with just a
{{META-INF/maven/plugin.xml}} containing
{{<plugin><goalPrefix>stuff</goalPrefix></plugin>}}.
3. Indexes the repository, using all available {{IndexCreator}} instances.
4. Runs a search like {{ArtifactInfo.PLUGIN_PREFIX="stuff"}} and checks that
there is one hit.
This test passed sometimes - including always when run from the debugger - but
usually failed. Eventually I found that the order of {{IndexCreator}} instances
returned from the Plexus container mattered: if {{min}} preceded
{{maven-plugin}} then the test passed, whereas if {{min}} followed
{{maven-plugin}} then the test failed. Furthermore, despite
{{META-INF/plexus/components.xml}} listing these implementations in a
particular order (seemingly arbitrary at build time), the actual order returned
by {{PlexusContainer.lookupList}} seemed to vary randomly from run to run.
The problem may have to do with
{{MinimalArtifactInfoIndexCreator.updateLegacyDocument}}, which does something
with {{PLUGIN_PREFIX}} and {{PLUGIN_GOALS}} for reasons unclear to me. When the
creators were in the "wrong" order, http://code.google.com/p/luke/ confirmed
that {{px}} and {{gx}} fields were just not present.
I can work around this issue in the NetBeans code which indexes the local
repository, using a hardcoded list of indexers (or rather, indexer IDs) as
{{AbstractIndexCreatorHelper}} in the Indexer test sources does. But that does
not help for downloaded remote indices, which might have been created by a
faulty version of Indexer - since {{NexusIndexerCli.getIndexers}} uses
{{lookupList}} when {{--type full}} is used. This means that any queries about
plugin prefixes or goals may return results only for plugins which happen to
have been downloaded locally. Indeed this is exactly what seems to happen when
I try it, i.e. the Central index I am getting (via a proxy in Nexus 1.9.1.1)
has no {{PLUGIN_*}} fields.
The less desirable workaround would be to run a search on
{{ArtifactInfo.PACKAGING="maven-plugin"}}, and for each hit, download the
actual JAR and parse {{plugin.xml}} myself.
I am not sure whether the position of
{{MavenArchetypeArtifactInfoIndexCreator}} also matters, but it seems
plausible, since it overrides a field normally stored in
{{MinimalArtifactInfoIndexCreator}}.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
