Ivan,
Remove the addClass(ProjectFactory.class) from your test. This is provided
by the projects addon, so you can't do that.
Em 16/08/2015 03:41, "Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com>
escreveu:
Thanks, Gastaldi!
I added a new branch for the test:
https://github.com/bgjug/spring-boot-forge-addon/tree/BOOT-FORGE-9
Cheers,
Ivan
On Sun, Aug 16, 2015 at 12:49 AM, George Gastaldi <ggastald(a)redhat.com>
wrote:
> This is really odd. Can you push this changes to the addon github
> repository? I'll try to debug it during the week.
> Em 15/08/2015 18:05, "Ivan St. Ivanov" <ivan.st.ivanov(a)gmail.com>
> escreveu:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> 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