Hi
After doing component generation for myfaces 1.1 and tomahawk 1.1, one of
my objectives is tomahawk 1.2.
The idea for reach this objective is this:
1. Generate a myfaces-metadata.xml for myfaces 1.2 (my first attempt was use
annotations and generate it using myfaces-faces-plugin)
2. Create
Hi
I have applied component generation for tomahawk core and sandbox and tested
it exhaustively (with generated myfaces core 1.1), so I can say finally that
this feature is ready for apply the changes on myfaces core 1.1 trunk,
tomahawk trunk, and myfaces build tools trunk.
This issue was
On Fri, 2008-04-25 at 19:39 -0500, Leonardo Uribe wrote:
2008/4/25 Andrew Robinson [EMAIL PROTECTED]:
Forgot to ask, this uses annotations for JSF = 1.2 right?
Yes.
Well, actually it is user's choice, as both are supported. But I would
imagine that people would choose real
On Sat, Apr 26, 2008 at 2:03 PM, simon [EMAIL PROTECTED] wrote:
On Fri, 2008-04-25 at 19:39 -0500, Leonardo Uribe wrote:
2008/4/25 Andrew Robinson [EMAIL PROTECTED]:
Forgot to ask, this uses annotations for JSF = 1.2 right?
Yes.
Well, actually it is user's choice, as both are
Hi
Thanks to all people who voted.
We got 7 +1
Grant Smith
Bruno Aranda
Sochor Zdeněk
Werner Punz
Gerald Müllan
Simon Kitching
Leonardo Uribe
and one +0
Mario Ivankovits
So MyfacesBuilderPlugin will be moved to trunk:
https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/maven2
word.
Thanks,
Andrew
2008/4/25 Leonardo Uribe [EMAIL PROTECTED]:
Hi
Thanks to all people who voted.
We got 7 +1
Grant Smith
Bruno Aranda
Sochor Zdeněk
Werner Punz
Gerald Müllan
Simon Kitching
Leonardo Uribe
and one +0
Mario Ivankovits
So MyfacesBuilderPlugin will be moved
to all people who voted.
We got 7 +1
Grant Smith
Bruno Aranda
Sochor Zdeněk
Werner Punz
Gerald Müllan
Simon Kitching
Leonardo Uribe
and one +0
Mario Ivankovits
So MyfacesBuilderPlugin will be moved to trunk:
https://svn.apache.org/repos/asf/myfaces/myfaces-build
Leonardo Uribe schrieb:
MyfacesBuilderPlugin is now available for use on myfaces 1.1, so we
can officially vote about what plugin use on myfaces 1.1, 1.2 and
tomahawk for code generation
+1 for myfaces-core 1.1.x and tomahawk now!
(+1 for myfaces-core 1.2.x eventually, but there's no hurry..)
Hi,
great work!
So please vote if you want to see this feature included on myfaces 1.x and
tomahawk
+1
cheers,
Gerald
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Leonardo Uribe schrieb:
+0
... just due to the fact that I don't have time to review these bits,
but I trust you guys that *everything* ;-) works as expected.
+1 for the architecture and the general approach!
Great work!
Hi
MyfacesBuilderPlugin is now available for use on myfaces 1.1, so we
+1 definitely for jsf 1.1 we need something
working and well documented.
Leonardo Uribe schrieb:
+1
On Tue, Apr 22, 2008 at 11:12 PM, Leonardo Uribe [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi
MyfacesBuilderPlugin is now available for use on myfaces 1.1, so we
can
in trinidad/core-1.2.x
(c) stay with the current solution.
Info about approach (a) can be found here:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
Background on the whole issue (including a description of the current
solution) can be found here:
http://wiki.apache.org/myfaces
/MyfacesBuilderPlugin
Background on the whole issue (including a description of the current
solution) can be found here:
http://wiki.apache.org/myfaces/Code_Generation
This vote is specifically about whether to choose (a) or not.
Choosing (a) means updating source in core-1.1 and tomahawk-1.1 trunk to
add
with the current solution.
Info about approach (a) can be found here:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
Background on the whole issue (including a description of the current
solution) can be found here:
http://wiki.apache.org/myfaces/Code_Generation
This vote
-faces-plugin (formerly called trinidad-faces-plugin)
as
currently used in trinidad/core-1.2.x
(c) stay with the current solution.
Info about approach (a) can be found here:
http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
Background on the whole issue (including
[EMAIL PROTECTED] schrieb:
Werner Punz schrieb:
+1 definitely for jsf 1.1 we need something
working and well documented.
Just to be clear: the options for the next core-1.1and tomahawk releases
are:
(a) the new myfaces-builder-plugin
I am voting for a in this case
the old trinidad plugin is
Before I vote, I am curious to know if there has been an audit of the
functionality compared to the maven-faces-plugin tool.
I am wondering about that I can think of right now:
1. component, facet and property meta data extensions that live in
faces-config.xml
2. importing of code from shared
There are my personal opinions and solutions about each point :
On Wed, Apr 23, 2008 at 12:48 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
Before I vote, I am curious to know if there has been an audit of the
functionality compared to the maven-faces-plugin tool.
I am wondering about that I
thanks for all the work!
On Tue, Apr 22, 2008 at 5:38 AM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
MyfacesBuilderPlugin is almost complete. Actually works for 1.1 and all
interested people could see the example here:
https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches
Hi!
MyfacesBuilderPlugin is almost complete. Actually works for 1.1 and
all interested people could see the example here:
Cool work guys. Great job!
Thanks for all the hard work!
Ciao,
Mario
Hi
MyfacesBuilderPlugin is now available for use on myfaces 1.1, so we can
officially vote about what plugin use on myfaces 1.1, 1.2 and tomahawk for
code generation
Please note that this work is based on the discussion about code generation
long time ago.
A vote is necessary since
+1
On Tue, Apr 22, 2008 at 11:12 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
MyfacesBuilderPlugin is now available for use on myfaces 1.1, so we can
officially vote about what plugin use on myfaces 1.1, 1.2 and tomahawk for
code generation
Please note that this work is based
Hi
MyfacesBuilderPlugin is almost complete. Actually works for 1.1 and all
interested people could see the example here:
https://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/branches/builder_plugin/bigtest/core_trunk_11/
Now I'm trying to apply this plugin to tomahawk, but I think we
On Wed, Apr 16, 2008 at 12:33 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
Another alternative to option 1 is to #parse($fileName) or
#include($fileName).
You can specify filename externally. This is probably the best
solution so long as the contents of the file included can be included
Leonardo Uribe schrieb:
On Wed, Apr 16, 2008 at 12:33 PM, Mike Kienenberger
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Another alternative to option 1 is to #parse($fileName) or
#include($fileName).
You can specify filename externally. This is probably the best
Another alternative to option 1 is to #parse($fileName) or #include($fileName).
You can specify filename externally. This is probably the best
solution so long as the contents of the file included can be included
as-is.
On 4/9/08, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
I have another
Hi
I have another design question. I have finished tag class generation using
velocity, and right now I'm working on generation of component classes, but
later I want to use this tool for generate faces-config.xml and taglib.tld
files too.
The problem is that in some point it is necessary to let
/MyfacesBuilderPlugin
As there was reasonable support for an alternative annotation-driven
approach, I created a prototype implementation. People seem reasonably
happy with the approach, and Leonardo is now doing some great work
extending the initial code (in particular, adding the back end part).
This new plugin
On Thu, Apr 3, 2008 at 6:56 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
On Thu, Apr 3, 2008 at 7:44 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
The drawback
is that creates a log file on the project folder (I'm not found how to
output the log on the screen yet!).
Have you looked at
Message-
From: simon [mailto:[EMAIL PROTECTED]
Sent: Friday, April 04, 2008 2:29 AM
To: 'MyFaces Development'
Cc: Kito D. Mann
Subject: RE: MyfacesBuilderPlugin
On Thu, 2008-04-03 at 20:29 -0400, Kito D. Mann wrote:
Thanks for the explanation, Leonardo. I’m guessing that the Trinidad
Leonardo Uribe schrieb:
Hi
I have a design question. I'm working on generate component tag
classes using velocity.
In this part it is common to found some situations when you need
utility methods. There are several methods
to do this:
1) Implementing this methods on a java class, and use
Is the MyfacesBuilderPlugin completely separate from the Trinidad Maven
Plugins?
~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com/ http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
I have not seen the specifics of this project, but if you're using
velocity, you should be able to have the code which initializes
velocity automatically populate something like $utils instead of doing
it in the velocity template language.
I also think you're better off NOT putting
On Thu, Apr 3, 2008 at 5:33 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
I have not seen the specifics of this project, but if you're using
velocity, you should be able to have the code which initializes
velocity automatically populate something like $utils instead of doing
it in the
On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann [EMAIL PROTECTED] wrote:
Is the MyfacesBuilderPlugin completely separate from the Trinidad Maven
Plugins?
Actually is a branch developed inside build-tools. There is no official vote
yet about if this plugin will be used on trinidad, since
On Thu, Apr 3, 2008 at 7:44 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
The drawback
is that creates a log file on the project folder (I'm not found how to
output the log on the screen yet!).
Have you looked at this page?
; [EMAIL PROTECTED]
Subject: Re: MyfacesBuilderPlugin
On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann [EMAIL PROTECTED] wrote:
Is the MyfacesBuilderPlugin completely separate from the Trinidad Maven
Plugins?
Actually is a branch developed inside build-tools. There is no official vote
yet
Leonardo Uribe schrieb:
Hi
The problem with xml files to make faces-plugin test work is now fixed.
Great.
I have a question about how myfaces-metadata works.
The idea is have one file per jar, and when the model is readed, it
should scan every artifact and merge it with the generated
On Wed, Apr 2, 2008 at 2:49 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
I'm not quite clear what your description above means. I think we are
talking about the same thing, but just to be clear this is how I would
see it working:
== for goal build-metadata:
start with an empty model
Hi
I have a design question. I'm working on generate component tag classes
using velocity.
In this part it is common to found some situations when you need utility
methods. There are several methods
to do this:
1) Implementing this methods on a java class, and use the following code
using a
Hi
The problem with xml files to make faces-plugin test work is now fixed.
I have a question about how myfaces-metadata works.
The idea is have one file per jar, and when the model is readed, it should
scan every artifact and merge it with the generated myfaces-metadata.xml.
I'm right or wrong
41 matches
Mail list logo
