The workaround is to declare the maven-compiler-plugin as follows:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.2</version>
                <executions>
                    <execution>
                        <id>default-compile</id>
                        <configuration>
                            <source>1.6</source>
                            <target>1.6</target>
                        </configuration>
                    </execution>
                    <execution>
                        <id>default-testCompile</id>
                        <configuration>
                            <compilerArgument>-proc:none</compilerArgument>
                            <source>1.6</source>
                            <target>1.6</target>
                        </configuration>
                    </execution>
                </executions>
            </plugin>

But this is still not 100% correct, because what if the test sources do contain some
other processor that you *do* want to run?

Just discussed this with Dafe - Jesse is probably a better person to look into this and suggest how to fix:
- Make changes to our processor?
- Change how we generate the pom for NBM-Maven projects?
- Ask the maven-compiler-plugin maintainers to make some changes on their side and release a new version?
- ... ?

(In reply to comment #2)
> Ask the maven-compiler-plugin maintainers to make some changes on their side
> and release a new version?

Probably. The -processorpath needs to include the *transitive* dependencies of the module. Compare how the NB Ant build harness uses ${module.run.classpath} for the processor path.

How about introducing what Petr listed as a workaround into the project archetype in 6.9 as the quick fix?

<id>default-testCompile</id>
  <configuration>
    <compilerArgument>-proc:none</compilerArgument>
...

It would only limit hypothetical user's usage of annotation processors in tests, right? Not a usecase we would take as a priority I guess. Would people agree?

(In reply to comment #4)
> It would only limit hypothetical user's usage of annotation processors in
> tests, right?

Yes.

> Not a usecase we would take as a priority I guess. Would people
> agree?

Don't know; we use APs in tests fairly frequently, though as not as much as in primary source roots.

What makes it work for primary source roots? That fix should be extended to test source roots.

> What makes it work for primary source roots?
> That fix should be extended to test source roots.

Neither I nor Dafe are too familiar with the solution.

Milosi, could you please help us by pointing to the right place or how extending the existing solution could start working also for test source roots?

it's not clear to me why the test compilation fails. what is missing from CP and why?

there's one thing in the way we generate the repository content for nb.org artifacts that could be related. We for artifacts in org.netbeans.api group (those having api packages) we only generate dependencies to other public packages artifacts and omit dependencies into the org.netbeans.modules groupid space. Not entirely correct in terms of maven dependency mechanism, but allow to work with most api dependencies without downloading the internet and having teh internet on the classpath and completion..

Further observations:
- bug does exist only for SNAPSHOT nbm artifacts, beta and FCS will be OK, so I'm downgrading to P3

- here is stack trace (run with mvn --errors):
Trace
org.apache.maven.BuildFailureException: Compilation failure
error: Exception thrown while constructing Processor object: org/openide/filesystems/annotations/LayerGeneratingProcessor

        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
        at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
error: Exception thrown while constructing Processor object: org/openide/filesystems/annotations/LayerGeneratingProcessor

        at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656)
        at org.apache.maven.plugin.TestCompilerMojo.execute(TestCompilerMojo.java:160)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
        ... 17 more

I noticed there are some strange messages about failing downloads when using SNAPSHOT versions. Hmm, but I doubt that could cause exceptions...
--------
Downloading: http://bits.netbeans.org/maven2/org/netbeans/api/org-openide-util/20100514.063437-1/org-openide-util-20100514.063437-1.pom
Unable to find resource 'org.netbeans.api:org-openide-util:pom:20100514.063437-1' in repository netbeans (http://bits.netbeans.org/maven2)
Downloading: http://repo1.maven.org/maven2/org/netbeans/api/org-openide-util/20100514.063437-1/org-openide-util-20100514.063437-1.pom
Unable to find resource 'org.netbeans.api:org-openide-util:pom:20100514.063437-1' in repository central (http://repo1.maven.org/maven2)
---------
Sure such artifacts are not there, they are in snapshot repo, but why is Maven trying even when I specify that shapshots can't be in such repos...?

Could not reproduce in a dev build, using SNAPSHOT platform deps.

http://jira.codehaus.org/browse/MNBMODULE-100 might have fixed whatever was wrong, but not sure.