6:24 p.m.
On 11-12-12 5:34 PM, Lincoln Baxter, III wrote:
Darn, for some reason this got saved as a draft and never sent...
sorry.
NP, you just saved me a ping :)
There is already a seam-render module in Forge, and the duplicated
classloader resources is something that Weld should be able to
understand because classes from different classloaders are different
classes.
Ok, thanks for the update. I can see it in the snapshot build. I or Ryan
will try this tomorrow.
This appears to be a bug in weld.
What happens when you add a module dependency on:
"org.jboss.seam.render" ? If it works, I can fix this as a workaround
in forge for now, but it's not the right solution in the long run, and
we'll have to get weld fixed up. I'm working on creating a custom
WeldBootstrap application that adds each plugin as a
deployablearchive, but that's going to take some time unless I can get
help from the weld guys.
In what sense is this not the right solution? As a
standalone plugin
developer, I don't think that I should be *expected* to package a
version of seam-render inside my plugin. It would be much easier for
plugin writers if they could rely on accessing certain modules (in the
same sense as plugins which are packaged with forge can use them).
Of course, I should be *allowed* to use my own version of seam-render,
which is a different thing, but one particular problem right now is that
seam-render itself depends on Solder and other libraries. That wouldn't
be a problem in itself, but IIRC one of the issues of packaging Solder
was that extension loading became completely messed up - I would need to
try that again to remember what exactly was the cause, but classloader
issues were definitely involved. In the long run, this needs to be be
solved as well, I agree.
Pete, Ales, Josef - any tips on how to get this to work?
https://github.com/forge/core/blob/master/shell/src/main/java/org/jboss/f...
~Lincoln
On Tue, Nov 29, 2011 at 10:50 PM, Marius Bogoevici <mariusb(a)redhat.com
<mailto:mariusb@redhat.com>> wrote:
All,
The problem can be made to go away by adding a dependency on
'org.jboss.forge' in the plugin module (since this is where
seam-render.
That would be, however, a wrong thing to do, since it breaks
modularity
big time. On the other hand, adding seam-render to the module itself
causes other types of class loader errors (due to the duplication).
IMO the right way to deal with this would be to split out a separate
'seam-render' (or otherwise aptly named) module, that plugins can
depend
on (after all, it is conceivable that template-based code
generation is
a wider used pattern, and third party plugins will want to get
access to
Forge's template-based generation facilities - perhaps just at the API
level).
Thoughts?
On 11-11-28 10:54 AM, Ryan Bradley wrote:
> Hi all,
>
> I am trying to use seam-render in my plugin, for classes such as
> TemplateCompiler. However, when I include it in the project and
try to
> build the plugin in Forge, I get a strange ResourceLoadingException
> which suggests that the class is not being found. Can anyone
shed some
> light on this problem?
>
> Thanks,
> Ryan
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/forge-dev
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org <mailto:forge-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev