Indeed you were right:
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO]
------------------------------------------------------------------------
with
Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100)
Maven home: /usr/share/maven
Java version: 1.7.0_15, vendor: Oracle Corporation
++
Corinne
On 26 February 2013 22:15, Sebastien Blanc <scm.blanc(a)gmail.com> wrote:
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
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev