Your Forge version is okay ...
What about your maven version ?
Seb
On Tue, Feb 26, 2013 at 9:07 PM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
Hi Seb
Same error on Fedora with jdk1.7.0_09.
Running with forge 1.2.0.Final
Could it be the forge version?
++
Corinne
On 26 February 2013 10:48, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
>
>
> On Tue, Feb 26, 2013 at 10:40 AM, Richard Kennard <
> richard(a)kennardconsulting.com> wrote:
>
>> Seb,
>>
>> It sounds like there may be some convergence here. Your 'macros' library
>> may end up looking very similar to Metawidget's existing HTML5
>> WidgetBuilder. And
>> your 'composition plugins' may end up similar to Metawidget's
>> LayoutDecorators and Layouts.
>>
>> I'd like to make sure you're not re-inventing the wheel here? Is your
>> main driver that you prefer writing templates in Freemarker to Java code?
>>
>
> Absolutely :) ! A user should be able to read and understand a template /
> overload them and not forced to write a Java class, a mid-term vision is to
> be more and more polyglot.
> Seb
>
>
>> Regards.
>>
>> Richard.
>>
>> On 26/02/2013 8:31 PM, Sebastien Blanc wrote:
>> > Hi Richard,
>> > Thanks for your remarks and questions, see my comments inline.
>> >
>> > On Tue, Feb 26, 2013 at 10:06 AM, Richard Kennard <
>> richard(a)kennardconsulting.com <mailto:richard@kennardconsulting.com>>
>> wrote:
>> >
>> > Hi Vineet,
>> >
>> > Thanks for your detailed response.
>> >
>> > I'm not opposed to the idea of a FreemarkerWidget (or
>> VelocityWidget, or StringTemplateWidget). Indeed, the early versions of
>> Metawidget looked much like
>> > you describe: a separate, pluggable inspection layer, then a
>> Metawidget to render it.
>> >
>> > However, we subsequently got a lot of feedback and did many
>> interviews, adoption studies and case studies. This ultimately led to the
>> architecture of
>> > pluggable WidgetBuilders, WidgetProcessors and Layouts. Let me
>> give you 3 examples of the feedback we got:
>> >
>> > 1. Widget choice needs to be orthogonal to layout. If you look at
>> your 'master.html.ftl' and 'detail.html.ftl' you have a lot of
duplicated
>> code between
>> > them. Both templates contain <#if... #else to choose between a
>> 'select' box and a 'text' box. This code is going to inflate
rapidly once
>> you add your
>> > date
>> > pickers, telephone numbers, URLs etc. to the mix. Worse, such code
>> will need to be duplicated across both templates.
>> >
>> >
>> > Vineet is currently factorizing all the duplicated code into
>> Freemarker's Macros, this Macros library will be shared along the different
>> plugins.
>> >
>> >
>> > 2. Equally, layout needs to be orthogonal to the wider page. Say I
>> decide I want to use tables with rows and columns, instead of a div-based
>> layout.
>> > Or say
>> > I want to use different CSS classes to your 'control-group' and
>> 'controls'. I will have to do it in both templates. But what is
*actually*
>> different
>> > about
>> > the templates is the choice of search buttons/results versus
>> save/cancel buttons. So the 'middle bit' of each page needs to be
>> orthogonal. This will get
>> > worse as you add more templates, such as separate 'search',
'view'
>> and 'edit' templates (see the JSF scaffold).
>> >
>> > With Forge 2.0 in mind, where Plugins/addons will be able to be
>> dependent from each other, inherit from each other, we plan to end up with
>> some basic
>> > plugins which will offer a lot of flexibility to deliver "Composition
>> plugins". We are also going to introduce a lot of convention over
>> configuration but
>> > with keeping in mind that the user can always override the conventions.
>> >
>> >
>> > 3. Developers like to use third-party widget libraries, and also
>> in-house custom widget libraries. If I want to add RichFaces, or
>> PrimeFaces, or a
>> > mixture
>> > of both, I want to be able to do so in a way that is orthogonal to
>> all of the above
>> >
>> > So my concern would be that a FreemarkerWidget would tightly
>> couple widget choice (WidgetBuilders) and layout, and not allow widget
>> processing (which is
>> > important for other reasons I haven't touched upon). Freemarker
>> does, I agree, offer an attractive level of immedicay and ease-of-editing
>> templates.
>> > But I
>> > wonder what your thoughts are on how it scales for some of the
>> points above?
>> >
>> >
>> > "Scaling" will be partly solved by the new architecture explained
>> above. For sure, there will always be situations where the user wants to
>> introduce his
>> > supra cool custom widget that don't fits without a lot of hacking but
>> IMO that's beyond the scope of scaffolding. Scaffolding is just to
"boost
>> up" a new
>> > project, it's a one time action, for sure, we can offer entry points
>> for customization but we can't (or don't want to) cover all the specific
>> situations.
>> >
>> > Regards,
>> > Seb
>> >
>> >
>> > Regards,
>> >
>> > Richard.
>> >
>> > > On 22 February 2013 13:56, Vineet Reynolds Pereira <
>> vpereira(a)redhat.com <mailto:vpereira@redhat.com> <mailto:
>> vpereira(a)redhat.com
>> > <mailto:vpereira@redhat.com>>> wrote:
>> > >
>> > > Hi Richard,
>> > >
>> > > I'm glad you brought this up, since we've been
looking to
>> provide feedback once we've finalized on our usage of the Metawidget APIs.
>> By the way,
>> > > I'm the one responsible for the use (or abuse) of
Metawidget
>> in this manner.
>> > >
>> > > The rationale behind the use of Metawidget inspectors
>> alone, is mostly because we want to allow users to modify the generated
>> scaffold. One
>> > of the
>> > > examples thrown around was to enable users to generate
>> master-detail views instead of the plain CRUD forms generated by Forge.
>> Another driving
>> > factor
>> > > was the need to create or enable creation of scaffold
>> generators for several JS frameworks including but not restricted to
>> AngularJS, Backbone.js,
>> > > Aerogear etc. Furthermore, there is also a possibility of
>> users needing to bring in plugins and extensions to these frameworks, like
>> Angular-UI or
>> > > Backbone.Forms, since the base frameworks may not satisfy
>> all needs. From my understanding of the Metawidget pipeline and it's use in
>> the Forge
>> > Faces
>> > > and (the earlier) Aerogear scaffold plugins, this would have
>> been possible if a metawidget were created for every use case (one per
>> framework, per
>> > > widget-type). We attempted to bring in the use of templates
>> written in a familiar templating langu!
>> > > age (like Freemarker/Velocity/StringTemplate) into the
>> scaffold generation phase to make it easier for users to modify the
>> generated scaffold.
>> > This
>> > > is somewhat on the lines of what the Yeoman generators do.
>> > >
>> > > Thanks to the APIs you've made available for the
>> Metawidget pipeline, the inspection results could be processed before
>> feeding them to the
>> > > templates. Every scaffold plugin that could potentially be
>> written, would more or less use this approach, with the sole difference
>> being in the
>> > > contents of the templates themselves. I hope this explains
>> why I used the Inspectors alone, and not the InspectionResultProcessors and
>> the rest of
>> > > the pipeline. The inspectors just fit in naturally into the
>> Forge scaffold generation pipeline.
>> > >
>> > > Based on the above, I personally think that a
>> FreemarkerWidget (or VelocityWidget, or StringTemplateWidget) would be
>> something to investigate.
>> > > This is of course a raw idea of mine, and I would like to
>> see if it is possible to use such a metawidget in a type-safe manner with
>> the ability to
>> > > configure the templates that it would consume. I'm not
sure
>> if creating such a widget would deviate from the intention behind the
>> Metawidget
>> > project.
>> > >
>> > > As a side note, I'd also like to point out that there
has
>> been interest in supporting various additional HTML5 form input types
>> (telephone
>> > > numbers, URLs etc.) in the generated scaffold, and this
>> would require extending the JPA/Bean Validation Inspectors in Metawidget.
>> > >
>> > > Best regards,
>> > > Vineet
>> > >
>> > > PS: CC'ing the forge-dev list.
>> > >
>> > > ----- Original Message -----
>> > > > From: "Richard Kennard"
<richard(a)kennardconsulting.com<mailto:
>> richard(a)kennardconsulting.com> <mailto:richard@kennardconsulting.com
>> > <mailto:richard@kennardconsulting.com>>>
>> > > > To: aerogear-dev(a)lists.jboss.org <mailto:
>> aerogear-dev(a)lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
>> > <mailto:aerogear-dev@lists.jboss.org>>
>> > > > Sent: Thursday, February 21, 2013 5:17:29 AM
>> > > > Subject: Re: [aerogear-dev] Aerogear Forge Plugin
>> > > >
>> > > > Seb,
>> > > >
>> > > > This looks very cool. I see you have used parts of
>> Metawidget for
>> > > > some of the implementation? I'd love to hear your
thoughts
>> on how it
>> > > > went and/or any
>> > > > changes you'd like me to make to Metawidget. For
example:
>> > > >
>> > > > 1. You have some code in Html5Scaffold that processes the
>> inspection
>> > > > result returned by CompositeInspector. It does things
like
>> > > > 'Canonicalize all numerical
>> > > > types in Java to "number" for HTML5 form input
type
>> support' and
>> > > > 'Extract simple type name of the relationship
types'. Was
>> there a
>> > > > reason you didn't factor
>> > > > this into a Metawidget InspectionResultProcessor
>> > > > (
http://metawidget.org/doc/reference/en/html/ch02s03.html
>> )?
>> > > > Specifically BaseInspectionResultProcessor has
>> > > > some methods to help?
>> > > >
>> > > > 2. You appear to be using FreeMarker templates rather
than
>> > > > Metawidget's WidgetBuilders, WidgetProcessors and
Layouts
>> (see the
>> > > > existing Forge JSF scaffold,
>> > > > Forge GWT scaffold, and Forge Spring scaffold). Could I
>> ask what the
>> > > > reasons were behind this?
>> > > >
>> > > > 3. I have recently implemented a pure client-side, pure
>> run-time,
>> > > > AngularJS version of Metawidget. If you were interested
in
>> a
>> > > > non-static version of your
>> > > > scaffold, perhaps you could give it a try?
>> > > >
>>
http://blog.kennardconsulting.com/2013/01/metawidget-meets-jquery-ui-and-...
>> > > >
>> > > > Regards,
>> > > >
>> > > > Richard.
>> > > >
>> > > > On 20/02/2013 11:49 PM, Jay Balunas wrote:
>> > > > > Wow!!! Really awesome work guys!!!
>> > > > >
>> > > > > On Feb 15, 2013, at 11:15 AM, Sebastien Blanc wrote:
>> > > > >
>> > > > >> Hi all !
>> > > > >> I'm pleased to announce that the first
version of the
>> Aerogear
>> > > > >> Scaffold Plugin for forge is available !
>> > > > >> It's still an alpha but thanks to the
excellent work
>> and help from
>> > > > >> Vineet we have a working plugin :
>> > > > >>
>> > > > >> - CRUD Scaffolding based on your entities.
>> > > > >> - One-to-one , many-to-one relation supported.
>> > > > >> - AngularJS and bootstrap responsive based.
>> > > > >> - Aerogear Pipe and Store used.
>> > > > >>
>> > > > >> There is still a lot to do but you can already
play
>> with it, a
>> > > > >> quickstart is available here and you should be
able to
>> create
>> > > > >> your first Aerogear App in
>> > > > >> 5 minutes ;)
>>
https://gist.github.com/sebastienblanc/4961324
>> > > > >>
>> > > > >> An example of a generated application can also be
found
>> here :
>> > > > >>
https://github.com/sebastienblanc/scaffoldtester
,
>> please review
>> > > > >> the generated code (at
>> > > > >> least the JS and HTML) and report it to me and I
will
>> update the
>> > > > >> templates accordingly.
>> > > > >>
>> > > > >> Next steps are :
>> > > > >> - Integrate Search feature (using the DataStore
filter
>> facilities)
>> > > > >> - Integrate Aerogear Pagination (although
generic
>> pagination is
>> > > > >> present now)
>> > > > >> - Integrate jQueryMobile (will probably be
another
>> plugin)
>> > > > >>
>> > > > >> Enjoy !
>> > > > >>
>> > > > >> Seb
>> > > > >>
>> > > > >> _______________________________________________
>> > > > >> aerogear-dev mailing list
>> > > > >> aerogear-dev(a)lists.jboss.org <mailto:
>> aerogear-dev(a)lists.jboss.org> <mailto:aerogear-dev@lists.jboss.org
>> > <mailto:aerogear-dev@lists.jboss.org>> <mailto:
>> aerogear-dev(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
>> > <mailto:aerogear-dev@lists.jboss.org <mailto:
>> aerogear-dev(a)lists.jboss.org>>>
>> > > > >>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > > > >
>> > > > >
>> > > > >
>> > > > > _______________________________________________
>> > > > > aerogear-dev mailing list
>> > > > > aerogear-dev(a)lists.jboss.org <mailto:
>> aerogear-dev(a)lists.jboss.org>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>> aerogear-dev(a)lists.jboss.org>>
>> > > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > > >
>> > > > _______________________________________________
>> > > > aerogear-dev mailing list
>> > > > aerogear-dev(a)lists.jboss.org <mailto:
>> aerogear-dev(a)lists.jboss.org>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>> aerogear-dev(a)lists.jboss.org>>
>> > > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > > >
>> > >
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev(a)lists.jboss.org <mailto:
>> aerogear-dev(a)lists.jboss.org>
<mailto:aerogear-dev@lists.jboss.org<mailto:
>> aerogear-dev(a)lists.jboss.org>>
>> > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >
>> > >
>> > >
>> > >
>> > > _______________________________________________
>> > > aerogear-dev mailing list
>> > > aerogear-dev(a)lists.jboss.org <mailto:
>> aerogear-dev(a)lists.jboss.org>
>> > >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev(a)lists.jboss.org
<mailto:aerogear-dev@lists.jboss.org>
>> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev(a)lists.jboss.org
>> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev