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/forge/shell/ModularWeld.java

~Lincoln

On Tue, Nov 29, 2011 at 10:50 PM, Marius Bogoevici <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@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



--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"


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