Yes, this would also be a good solution. At this point, I think MetaWidget
has a solid position and shoould be in the Forge Scaffold API.
Others' thoughts on this?
On Tue, Dec 4, 2012 at 5:48 PM, Richard Kennard <
richard(a)kennardconsulting.com> wrote:
Luca,
I would suggest:
1. Take a look at
https://github.com/forge/plugin-spring-mvc by Ryan
Bradley. It used a similar approach, and I believe he got it working?
2. Consider refactoring Metawidget out of forge-scaffold-faces and into
forge-scaffold-api. I think this is justified, now that it is reused by
Faces,
Spring, AeroGear and Errai. I believe most classes, like
ForgePropertyStyle and ForgeConfigReader, are duplicated anyway. This may
avoid classloading problems?
3. Implement a better ResourceResolver. I believe this is the approach
taken by AeroGear? See
org.jboss.forge.scaffold.aerogear.metawidget.config.ForgeConfigReader
Regards,
Richard.
On 5/12/2012 1:12 AM, Luca Masini wrote:
> After the resources I have the same problem with the classes that are
needed from MetaWidget.
>
> The fact is that from the configuration it must load a class inside my
module/plugin, but to lookup the class it uses the
> org.jboss.forge.forge-scaffold... module, which of course know nothing
about my custom classes.
>
> Now the solution is to override the lookupClasses, but am I doing
something wrong ?? There is a way to let "system" modules see my custom
classes ??
>
> Thank you
>
> --
> ****************************************
>
http://www.lucamasini.net
>
http://twitter.com/lmasini
>
http://www.linkedin.com/pub/luca-masini/7/10/2b9
> ****************************************
>
>
> _______________________________________________
> 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