We have in-house maven2 aggregator plugin that has similar functionality as maven-shade-plugin. It is used to produce maven artifacts that represent the product distribution archives. This plugin creates some submodules dynamicaly during the build and then executes install/deploy on this generated modules. When we run the build from console, it is OK, but when we use Hudson for build, than we obtain following error:

java.lang.AssertionError: reporters.get(platform:platform-dstr-consumer-api)==null. reporters=

{ues.platform:platform-dstr=[hudson.maven.reporters.MavenMailer@d4cd45, hudson.maven.reporters.BuildInfoRecorder@e53d23, hudson.maven.reporters.MavenSiteArchiver@f082fa, hudson.maven.reporters.MavenJavadocArchiver@27291d, hudson.maven.reporters.MavenArtifactArchiver@edbe7f, hudson.maven.reporters.SurefireArchiver@fc6b85, hudson.maven.reporters.MavenFingerprinter@13a2a44, hudson.plugins.cobertura.MavenCoberturaPublisher@1f6eb51]}

proxies=

{platform:platform-dstr=hudson.maven.MavenModuleSetBuild$Builder$FilterImpl@1d33ff5}

at hudson.maven.MavenModuleSetBuild$Builder.postModule(MavenModuleSetBuild.java:726)
at hudson.maven.MavenBuilder$Adapter.fireLeaveModule(MavenBuilder.java:310)
at hudson.maven.MavenBuilder$Adapter.postBuild(MavenBuilder.java:268)
at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:68)
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 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 hudson.maven.agent.Main.launch(Main.java:165)
at hudson.maven.MavenBuilder.call(MavenBuilder.java:165)
at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:696)
at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:640)
at hudson.remoting.UserRequest.perform(UserRequest.java:114)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:270)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

It is similar to:
http://issues.jenkins-ci.org/browse/JENKINS-4773
http://issues.jenkins-ci.org/browse/JENKINS-1454
http://issues.jenkins-ci.org/browse/JENKINS-2295

but we don´t use profiles. It will be nice, if the hudson could ignore any added module (from profile or by maven plugin) and don't throw this assert exception. This could solve the problems with profiles for other users too. In my opinion, we don't need exact overview about modules structure in hudson views, it is more important to have possibility to execute full build with maven as it is possible from console and be sure, that everything will be executed in the same stable way. The Hudson maven plugin should be a less invasive in access to maven reactor execution.

Thanks for your very good job, Hudson is the most powerful CI-tool that I know.