Ok , could you try to run Maven with jdk 1.7 ?
On Tue, Feb 26, 2013 at 10:09 PM, Corinne Krych <corinnekrych(a)gmail.com>wrote:
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Java version: 1.6.0_37, vendor: Apple Inc.
On 26 February 2013 22:03, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
> And also openJDK or Oracle JDK ?
> Just asking because I'm out of ideas :)
> Seb
>
>
> On Tue, Feb 26, 2013 at 9:53 PM, Sebastien Blanc <scm.blanc(a)gmail.com>wrote:
>
>> 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(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
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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