I think the solution in your case is to remove the provided scope from your addons.

Here is where this is better explained : https://github.com/forge/core/blob/master/README.asciidoc#what-scope-should-my-addon-dependencies-be

Best Regards,

George Gastaldi

Em 15/08/2015 16:28, "Ivan St. Ivanov" <ivan.st.ivanov@gmail.com> escreveu:

Hi folks,

I am now working on a test of the Spring Boot addon setup command. I was really happy with the changes that you did in the Forge test infrastructure that allow avoiding listing all the addons that my command depends on in the @AddonDependencies annotation as well as repeating some of them in the deployment method body. I was finally able to write tests like that:

@Deployment
@AddonDependencies
public static AddonArchive getDeployment()
{
   return ShrinkWrap
            .create(AddonArchive.class)
            .addBeansXML()
            .addClass(ProjectHelper.class)
            .addClass(AbstractSecurityCommandTest.class);
}

So I tried the same thing with the Spring Boot addon that we started developing in our JUG. However the test failed. I have attached both the test and the whole log file. I will here just paste the exception that stands out:

Caused by: java.lang.LinkageError: loader constraint violation: when resolving overridden method "org.jboss.forge.addon.springboot.ui.SpringBootSetupCommand.getProjectFactory()Lorg/jboss/forge/addon/projects/ProjectFactory;" the class loader (instance of org/jboss/modules/ModuleClassLoader) of the current class, org/jboss/forge/addon/springboot/ui/SpringBootSetupCommand, and its superclass loader (instance of org/jboss/modules/ModuleClassLoader), have different Class objects for the type tupCommand.getProjectFactory()Lorg/jboss/forge/addon/projects/ProjectFactory; used in the signature

at java.lang.Class.getDeclaredMethods0(Native Method)

at java.lang.Class.privateGetDeclaredMethods(Class.java:2615)

at java.lang.Class.getDeclaredMethods(Class.java:1860)

at java.lang.Class.getEnclosingMethod(Class.java:937)

at org.jboss.weld.util.reflection.Reflections.isNonStaticInnerClass(Reflections.java:401)

at org.jboss.weld.util.Beans.isTypeManagedBeanOrDecoratorOrInterceptor(Beans.java:492)

at org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:213)

at org.jboss.weld.bootstrap.BeanDeployer.createClassBeans(BeanDeployer.java:191)

at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:262)

at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:373)

at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)

at org.jboss.weld.environment.se.Weld.initialize(Weld.java:134)

at org.jboss.forge.furnace.container.cdi.lifecycle.WeldAddonLifecycleProvider.start(WeldAddonLifecycleProvider.java:77)

at org.jboss.forge.furnace.impl.addons.AddonRunnable$2.call(AddonRunnable.java:92)

at org.jboss.forge.furnace.impl.addons.AddonRunnable$2.call(AddonRunnable.java:86)

at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)

at org.jboss.forge.furnace.impl.addons.AddonRunnable.run(AddonRunnable.java:85)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)

at java.util.concurrent.FutureTask.run(FutureTask.java:262)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)

at java.lang.Thread.run(Thread.java:745)

What I see different between the spring boot addon and the java ee addon, where the referenced test belongs to, is that our addon has its pom.xml dependencies in provided scope. 

Is that the possible cause? Would you please give us advise how to write tests outside the core addons?

Thanks and regards,

Ivan

_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev

_______________________________________________
forge-dev mailing list
forge-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev