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 either JSF 1.1 & JSF 1.2
Common Utilities
* JDK 1.5
* Should work on either JSF 1.1 & JSF 1.2
Common Utilities 1.2
* JDK 1.5
* JSF 1.2+
Is that basically what we're looking at?
Scott
Matthias Wessendorf wrote:
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 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
Matthias Wessendorf wrote:
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 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
differ between 1.1 and 1.2 in the commons-converter? Same for
API is same.
the "impl" is little different;
ConverterTag is deprecated;
good folks would use ConverterELTag
(same for validator)
commons-validator. Also many util classes should be able to work in
jsf1.1 and jsf1.2 without changes.
yes "common" helper method, will work
if the are not using things like invokeOnComponet(), for instance
-M
Note: I'm speaking about the application-developer part of commons,
not of the component/library-developer part.
Regards,
Volker
2007/12/5, Scott O'Bryan <[EMAIL PROTECTED]>:
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 basically that we leave the current 1.1 compatible
renderkits as they are, maybe allowing some common filters and
converters depending on what people think is needed. The other commons
could then be used as projects tackle 1.2 and the commons could be used
to ease and unify that development effort.
Scott
Paul Spencer wrote:
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, then I have no objection for a non-JSF 1.1. compliant
dependency.
Paul Spencer
Scott O'Bryan wrote:
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 JDK 1.1 and therefore their adoption of the common utilities
would be slow if not non-existant. I know that the logic I'm trying
to introduce, although it could be used in JSF 1.1 environments,
really becomes most useful when dealing with JSF 1.2 and the portlet
bridge. I also wouldn't think that things like unified multi-part
form processing would be likely to make it into current 1.1
renderkits since it would require a lot of code to be rewritten and
may not be backward compatible.
Scott
Paul Spencer wrote:
+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 embracing 1.2
is only going to help the development community move forward.
+0.5 on 1.1 support with JDK 1.5 required on both.
Just because the specification supports 1.4 does mean libraries have
to. JDK 1.5 has been out plenty long enough for companies to adopt it.
If they cannot adopt it, they should be willing to forgo new libraries
and functionality
-1 on 1.1 w/ 1.4
This is too much work and will really hold nicer features back (I also
would have no interest in developing and testing it personally).
Just my $.02
-Andrew
On Nov 29, 2007 10:06 AM, 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 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 for this project?
One of my
proposals involves needing an ExternalContextWrapper and the
version of
JSF does make a difference. I, personally, would like to see
this based
off 1.2 but if we need a 1.1 Faces Commons then I would recommend
both a
1.1 and a 1.2 branch.
here we go;
my understanding is, that 1.1 is a must
2. What is the minimum JDK we are going to use for this project. My
preference would be J2SE 5 for the build. I could even live with
making
sure that code can be compiled with J2SE 5 in 1.4 compatibility
mode but
I think we need to be able to support generics at the very
least. Of
course if we're basing the commons project off of JSF 1.2, J2SE5
is a
no-brainer. :)
JSF 1.1 => java1.4
JSF 1.2 => JDK5
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
