I don't see these as significant advantages to making it a separate
JAR. None of these should be marked as required dependencies for
standard tomahawk use - they should all be marked as provided
scope, which avoids the issue.
I agreee. Why not include the facelets config file in the META-INF
What if there is a need for a different JAR for different facelets versions? For example, if Jacob changed the tag handler API in Facelets 1.2, then the code would be different for Facelets 1.1 and 1.2. This is the big reason I see for having the Jars separate.
-AndrewOn 5/15/06, Sean Schofield
Andrew,
I don't see any changes coming in the tag handler API or XML format,
and just asked Jacob, who agrees.
-- Adam
On 5/15/06, Andrew Robinson [EMAIL PROTECTED] wrote:
What if there is a need for a different JAR for different facelets versions?
For example, if Jacob changed the tag
Part of the release notes will be what version of facelets that
particular tomahawk release is compatible with. We will probably just
try to keep in sync with the most current stable facelets release.
You could always rebuild from SVN and switch in a prior (or custom)
taglib xml file.
Plus if
I vote for option 2.
Option 3 might make sense if the compatibility-option is important.
The pointer to the download-packages can be held in myfaces-doc/-wiki,
together with a matrix for the compatible versions...
regards
Alexander
-Original Message-
From: Andrew Robinson
On 5/10/06, Adam Winer [EMAIL PROTECTED] wrote:
I think we'll want to make it a separate jar and project because
facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
JSP 2.1 as well. Those don't need to be dependencies for standard
tomahawk use.
FYI, it doesn't depend on
Option 1 and Option 2 are both good. The important thing is to keep facelets in sync with tomahawk. Either way with facelets taglib in the source tree developers will be able to do a better job of keeping them in sync.
Mike
On 5/10/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 5/10/06, Adam Winer [EMAIL PROTECTED] wrote:
I think we'll want to make it a separate jar and project because
facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
JSP 2.1 as well. Those don't need to be
I vote for option 1. A couple
small files/classes won't add much to the jar size and it will greatly
improve the experience for somebody just trying to get up and running.
Great idea.
Adam Brod
Product Development Team
Andrew Robinson
[EMAIL PROTECTED]
05/09/2006 04:05 PM
Please respond
I forgot one point, option (2) has one benefit over option (1): there could be separate jar files for different facelets versions if at anytime facelets broke compatibility.-Andrew
On 5/9/06, Adam Brod [EMAIL PROTECTED] wrote:
I vote for option 1. A couple
small files/classes won't add much to
Thomas and I have talked on and off about adding facelets support
natively to MyFaces Tomahawk.
http://issues.apache.org/jira/browse/TOMAHAWK-79
Things that were holding us up in the past were no code generator.
That's now available again, although I haven't had time to look into
using it.
On 5/9/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I think we'll want to make it a separate jar and project because
facelets depends on JSF 1.2 RI and the Glassfish EL jars. And maybe
JSP 2.1 as well. Those don't need to be dependencies for standard
tomahawk use.
In case it's not clear,
12 matches
Mail list logo
