I just had a thought. Are you sure that you really need the MVEL library?
Is it possible that you are directly referencing MVEL classes when you
should instead be referencing Seam Render classes?
"TemplateCompiler" comes to mind.
Just a thought?
Could you post your plugin code on github so that I can try to reproduce
this issue?
~Lincoln
On Tue, Feb 14, 2012 at 5:01 PM, Thomas Frühbeck <fruehbeck(a)aon.at> wrote:
Thank you for clarifying the issue, the build-repair-reload cycles
have
become tedious :-)
> AFAICT, depending on seam-render and adjusting seam-render module
definition to export the MVEL classes should take care of this (
If I understood correctly the proposed solution would be to change
forge/modules/org/jboss/seam/render/main/module.xml to
<module xmlns="urn:jboss:module:1.0"
name="org.jboss.seam.render">
<resources>
<resource-root path="seam-render-1.0.0.Alpha6.jar"/>
</resources>
<dependencies>
<module name="javax.enterprise.api" />
<module name="org.jboss.forge" />
<module name="org.jboss.solder" />
<module name="org.mvel" export="true"/>
<module name="javax.api" />
</dependencies>
</module>
I did that and it works!
> if it's ever acceptable from a visibility perspective to depend on MVEL
directly).
Honestly, this sounds as if the old days of classloading problems come
back :-/
My two cents: if there is a clean solution keeping the classes hidden from
the plugins it's OK.
But if it is difficult to do I would prefer to accept visibility of such
libraries of common utility - we are talking of _plugins_, there should be
some initimacy allowed, isn't it?
Regards,
Thomas
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"