Order of IndexCreator's passed to addIndexingContextForced affects whether MavenPluginArtifactInfoIndexCreator has any effect

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.