On Dec 5, 2007 10:40 AM, Volker Weber [EMAIL PROTECTED] wrote:
Hi,
why should a jsf1.1 extension library require java1.4 support?
+1
tobago requires java1.5.
Trinidad is also requiring Java5.
like in Tobago land, we have a retro-weaver profile in the pom.
it is totally fine running jsf
Hi,
why should a jsf1.1 extension library require java1.4 support?
tobago requires java1.5.
it is totally fine running jsf 1.1 on a java 1.6 environment.
I don't know the details of jsf 1.2 spec, but it seems to me that the
api for javax.faces.convert.Converter is the same, so why must we
the impl is little different;
ConverterTag is deprecated;
good folks would use ConverterELTag
(same for validator)
which are generated classes (that depend on a JSF 1.1 TAG or a JSF 1.2 one).
Which means that can be done via param (which is now hard-coded in the POM).
-M
I guess the other option is to take a more segmented approach (like for
configurators) and rate the minimum requirements for each module
separately. But I kind of like the idea of not including a bunch of
different jars if we can help it.
Scott
Scott O'Bryan wrote:
Yeah I agree.
So to
That looks good.
On Dec 5, 2007 6:16 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Yeah I agree.
So to summarize here is what I'm understanding from people:
Common Converters
* JDK 1.5
* Should work on either JSF 1.1 JSF 1.2
Common Validators
* JDK 1.5
* Should work on
Sorry to be frank, but that wasn't an answer to the question.
Maintaining two code lines far outweighs the work to flip the plug-in
configuration, and that reason alone should be enough to discourage
any new 1.1 projects. The question still remains of why we need to
support 1.1.
On Dec 5, 2007
here we go;
my understanding is, that 1.1 is a must
Why? Is it really necessary for us to create new projects on legacy
specifications?
I'd vote +0 on supporting JSF 1.1
if that does answer your question.
(and in case some guys do need the converters/validators, they can
always fork it)
-m
On Dec 5, 2007 7:14 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
Sorry to be frank, but that wasn't an answer to the question.
Maintaining
On Dec 5, 2007 6:18 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
here we go;
my understanding is, that 1.1 is a must
Why? Is it really necessary for us to create new projects on legacy
specifications?
Well a must is a bit too much. I think I said that, having Tomahawk
1.1.x in mind...
yes, some APIs have changed;
my point was just, that for trivial things (like the validators/converters),
the API is same, the generated artifacts are *dependent* to the particular
Faces version.
-M
On Dec 5, 2007 5:34 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
I've also noticed that things
I've also noticed that things with the externalContext also do not work
properly because the ExternalContext api's have changed. I suspect
anything that relies on the new functionality in externalContext or any
of the other API's for that matter will have trouble porting back.
Scott
Scott,
My concern is when components, like Tomahawk, become dependent on JSF
Commons, then they will inherit the dependencies of JSF Commons. If a
component in JSF Commons is not intended to be used with JSF 1.1, or
none of JSF 1.1 components, like Tomahawk, require the commons
component,
Right, I totally agree. The point is that, currently, Tomahawk, Tobago,
and Trinidad 1.1 are NOT currently dependent on commons. And
introducing support for 1.1 in the commons now would mean that commons
would have to support Java 1.4 and JSF 1.1 pretty much forever.
My proposal is
+1 for me too. I think the current JSF commons is already set up for
1.1 though...
Scott
Mario Ivankovits wrote:
Hi!
+1 on JSF 1.2 only
+0.5 on 1.1 support with JDK 1.5 required on both.
-1 on 1.1 w/ 1.4
+1 on that view!
Ciao,
Mario
If you're going to support 1.1, support 1.4. Otherwise, just stick
with JSF 1.2.
I know where I do my primary JSF work, the major holdup has been JDK
1.5, which was only recently adopted, not JSF 1.2, per se.
I'm personally good with JSF 1.2 only, though, for this new project.
On Dec 3, 2007
The current state is not that it is done for JSF 1.1 only.
We just started the two classes with that :-)
The switch to JSF 1.2 is very cheap, since it is via config.
-M
On Dec 3, 2007 8:47 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
If you're going to support 1.1, support 1.4. Otherwise,
+1 on JSF 1.2 only
+1 on 1.1 support with JDK 1.5 required on both.
+1 on 1.1 w/ 1.4
I have projects I support on HP-UX that are currently running
JDK 1.4.
Paul Spencer
Andrew Robinson wrote:
I would go for:
+1 on JSF 1.2 only
This is open source, so no one is required to use it and
Cool, I was hoping we had one. :) Paul, you mind if I ask you some
questions about this?
I can totally understand the want/need for the converters and validators
to be ported to 1.1 (and thus need 1.4 support), but what about the
utilities? Currently Trinidad, Tomahawk, and Tobago support
Hey everyone,
I'm going to try to put together a proposal for some items it add to the
jsf commons fairly soon for your purusal. First off, however, I'd like
some technical information on this project as it may effect how the
project is set up.
1. Which version of JSF will be the minimum
On Nov 29, 2007 6:06 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Nov 29, 2007 5:57 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey everyone,
I'm going to try to put together a proposal for some items it add to the
jsf commons fairly soon for your purusal. First off, however, I'd
If 1.1 is a must then I don't see any way around having 2 trunks. The
API's between the two are not the same and when dealing with things like
decorators (which JSF makes extensive use of), you need to implement
every method on a class and ONLY those methods.
I know that for Trinidad,
to make it clear.
I am not saying, that JSF 1.1 API is the ONLY ONE.
Because this is a new project, a JSF 1.2 ONLY *would* make sense...
but... JSF 1.1 is still in use...
Perhaps a second trunk for 1.1-based JSF is a good thing (tm)
-Matthias
On Nov 29, 2007 6:16 PM, Scott O'Bryan [EMAIL
I certainly would be interested in contributing to a tomahawk-1.2 line, but not
particularly interested in a tomahawk-1.1 line.
It is necessary to test stuff that is added/modified, but compiling then
testing against both versions of JSF will be painful. And writing components
that work with
Scott O'Bryan escreveu:
If 1.1 is a must then I don't see any way around having 2 trunks.
WDYT about use different pakages for different versions (incompatible
stuff only) like Spring did for Hibernate version 2 and 3?
org.springframework.orm.hibernate = for Hibernate 2.x
and
We CAN... But the compile time requirements will be different. And the
real concern I have is that this commons project is a slave to another
project which means we are at the mercy of the JSF api's. If they
change, implementations need to change and it may not always be possible
to have
Hazza. It would also allow, possibly, a Tobago 1.2 line to move forward
a bit easier..
Scott
Simon Kitching wrote:
I certainly would be interested in contributing to a tomahawk-1.2 line, but not
particularly interested in a tomahawk-1.1 line.
It is necessary to test stuff that is
26 matches
Mail list logo
