Well we can, but I think we have some legacy solutions out there that
are not easily changed. Does anyone besides Trinidad and (from what I'm
hearing) Tobago have JSF1.2 specific branches?
Scott
Gerhard Petracek wrote:
hello,
what's about an uniform layout for all myfaces-projects?
hello,
what's about an uniform layout for all myfaces-projects?
(currently it's also a blocking topic for me to
setup myfaces-extensions-validator.)
regards,
gerhard
2008/6/20 Scott O'Bryan [EMAIL PROTECTED]:
Mike, the problem with this approach is one of forward compatibility.
Let me
Hi,
2008/6/20 Scott O'Bryan [EMAIL PROTECTED]:
[...]
The old
code line gets bug fixes and nothing more and the active development is
always on the latest and greatest. Why can't we do something similar?
The active development is done where needed, which in my case is jsf1.1.
Regards,
On Fri, 2008-06-20 at 09:06 +0200, Volker Weber wrote:
Hi,
2008/6/20 Scott O'Bryan [EMAIL PROTECTED]:
[...]
The old
code line gets bug fixes and nothing more and the active development is
always on the latest and greatest. Why can't we do something similar?
The active development
simon schrieb:
In other words, keeping one line of code makes sense (less
maintenance) even if we lose some JSF1.2/JSF2.0-specific features or
performance boosts.
While I second the rest of your mail, I wont do so with the sentence above.
We are developers, and, at least in your younger years
JSR 252 (JSF 1.2) was finalized on 2006-05-11
Java 1.5 released 2004-09-30
I don't mind people maintaining JSF 1.1, but I do think that there is
very good cause to have 1.1 moved to branches and the latest JSF
specification as the trunk for each project. Over 2 years is plenty of
time to adopt
Hi all,
I have to agree with Andrew here. One year ago, JEE5 server were still
scarce or underused, thus supporting the maintained two branches argument,
but now is no longer the case and splitting efforts between two code bases
doesn't sound most efficient.
Regards
~ Simon
On Fri, Jun 20,
I am one who is using JSF 1.1 for some applications. This is because
the applications are running software/hardware environments which do not
support JSF 1.2. For applications in environment that will support JSF
1.2, I use JSF 1.2.
Future JSF version are inevitable, thus a solution must
Paul, why do the CF versions have to be different. This is no different
(IMO) then what I was talking about except that we could not FORCE
people to backport everything.
I don't see why libraries for older JSF's HAVE to be functionally
equivalent. That is not to say that API's started in
Partially ignore this.. :) Let me clairify now that I understand your
proposal..
I think projects need to be in charge of their own destiny based off of
need/usage.. :) Indeed Trinidad has a 1.0.8 branch and a 1.2.8 branch
which is (mostly) functionally equivalent. But I wouldn't say that
Let's not forget that working on open source software is quite
different than working on proprietary software. For open source, you
work on what you need and you share what you've done with others.
Some people need JSF 1.1 and will be working there. Some people need
JSF 1.2 and will be working
Scott O'Bryan wrote:
Partially ignore this.. :) Let me clairify now that I understand your
proposal..
I think projects need to be in charge of their own destiny based off of
need/usage.. :) Indeed Trinidad has a 1.0.8 branch and a 1.2.8 branch
which is (mostly) functionally equivalent.
Yeah, I would accept that... At least until there is basically NO
active development happening on a branch. Maybe when the corresponding
JSF branch goes End of Cycle?
Paul Spencer wrote:
Scott O'Bryan wrote:
Partially ignore this.. :) Let me clairify now that I understand
your proposal..
Mike, the problem with this approach is one of forward compatibility.
Let me explain. The ExternalContextUtils in the MyFaces commons, when
it existed in Trinidad, had api's for handling request input streams and
whatnot because the ExternalContext did not. If someone used that API
and then
Hi
After several discussions about how myfaces-commons should be, there are
strong reasons to believe that this project
should have some layout that allow myfaces 1.1 projects to use it.
There was a vote about had 1.1 stuff on a different branch and the trunk be
1.2. This vote should be
+1
On Thu, Jun 19, 2008 at 5:39 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
After several discussions about how myfaces-commons should be, there are
strong reasons to believe that this project
should have some layout that allow myfaces 1.1 projects to use it.
There was a vote about
I still think this is a bad idea. My question is this, now that JSF 2.0
is getting ready to come out, when is Tomahawk going to finally open a
JSF 1.2 or JSF 2.0 branch?
Further, Matthias has a commons 1.1 branch out there already in
branches. It's mainly for backports. Can we not do this
-1
Leonardo Uribe wrote:
+1
On Thu, Jun 19, 2008 at 5:39 PM, Leonardo Uribe [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi
After several discussions about how myfaces-commons should be,
there are strong reasons to believe that this project
should have some layout
Hi
Now I understand the philosophy behind the jsf 1.1 branch of myfaces
commons. The confusing thing is that on tomahawk core and core12 live
together on the same trunk (this does not happen on other projects) and
myfaces-commons has never been released. So this vote is useless, after
this.
I was about to give -1 too
On Thu, Jun 19, 2008 at 5:19 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
Now I understand the philosophy behind the jsf 1.1 branch of myfaces
commons. The confusing thing is that on tomahawk core and core12 live
together on the same trunk (this does not happen
20 matches
Mail list logo
