4:05 p.m.
I removed the dependency to core and added to some other addons that we
depend on. Attached is the new pom.xml.
The exception when I run the test still exists. I cleaned up the .forge
directory and installed the addon. And it is the only thing that goes in
the addons directory.
On Sat, Aug 15, 2015 at 11:34 PM, George Gastaldi <ggastald(a)redhat.com>
wrote:
It looks like your addon might be bundling classes that shouldn't
be
there. Try installing your addon in forge and see what goes in your
~/.forge/addons.
Also try removing the dependency to core (as it is not needed).
Em 15/08/2015 17:09, "Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com>
escreveu:
> Hi George,
>
> I am afraid this did not help. Here is the exception again:
>
> 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)
>
> Cheers,
> Ivan
>
> On Sat, Aug 15, 2015 at 10:42 PM, George Gastaldi <ggastald(a)redhat.com>
> wrote:
>
>> 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-shou...
>>
>> Best Regards,
>>
>> George Gastaldi
>> Em 15/08/2015 16:28, "Ivan St. Ivanov"
<ivan.st.ivanov(a)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
>>>
<https://github.com/forge/core/blob/master/javaee/tests/src/test/java/org/...
>>> :
>>>
>>> @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
>>> <https://github.com/bgjug/spring-boot-forge-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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>>
>>
>> _______________________________________________
>> forge-dev mailing list
>> forge-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/forge-dev
>>
>
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
>
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev