:) Cool.
That said, if we really need a place for backports, as part of the main
trunk is not it IMO. Why? Simply put, I think the 1.1 branch needs to
be backports. This means it will likely release on a different
schedule. When MyFaces 2.0 is available, I would expect the active
development to happen on the 2.0 branch and backporting to 1.2..
So we have a few options here.
1. We can either split them off at the TRUNK level like we did with
Trinidad. So we would have a trunk_11 and a trunk (holding the 1.2
branch). This makes the structure look like this:
trunk_1.1
myfaces-commons-validators
myfaces-commons-converters
myfaces-commons-utils
trunk
myfaces-commons-validators
myfaces-commons-converters
myfaces-commons-utils
When the community decides to embrace 2.0 we could then split off a
trunk_1.2 folder.
2. We can put the backports in a branch and release off of that. This
is what we have now..
trunk
myfaces-commons-validators
myfaces-commons-converters
myfaces-commons-utils
branches/jsf_11
myfaces-commons-validators
myfaces-commons-converters
myfaces-commons-utils
So all backports go into the branch and then releases are done as needed
from this branch.. Then when we move to 2.0 in trunk, we could add a
branches/jsf_12.
3. We could do #2 for JSF_11 and then when JSF2.0 is added, we could
simply do backports and fixes on an as-needed basis by branching from
the tag, doing the fixes and backports, creating a new tag, and then
removing the branches.
IMO #3 is cleanest, but if we need a lot of backports (and considering
the feel of the community right now we'll need to) then perhaps #2 is
the best compromise.
As for the ExternalContextUtils, the Trinidad version had some other
functions that I removed because 1.2 added support for them. They were
instrumental in handling file uploads because the idea behind the class
was to prevent someone from having to cast. I can add them back in and
make a REALLY NICE 1.1 port if you want me to.. I've been meaning to
add some convenience methods anyway.
Scott
Leonardo Uribe wrote:
On Thu, Jun 19, 2008 at 5:56 PM, Scott O'Bryan <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Right. I know there has been some talk about creating a Tomahawk
JSF 1.2 branch. I don't imagine that Tomahawk would use the
commons before (and if) this happens anyway. Still, it would be
nice to make the migration as painless as possible. :)
There exists on tomahawk right now a modules called core12 and
sandbox/core12. I have made some work adding tomahawk converters and
validators to myfaces commons, to then reference
Scott
Leonardo Uribe wrote:
On Thu, Jun 19, 2008 at 5:05 PM, Scott O'Bryan
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
Hey Leonardo,
Let me take a look at this tonight. As you know, I hope to
have
the configurator package checked in soon into commons which
will
do this as well. Right now it fits Trinidad's requirements
pretty
well but I'd like to see how it stacks up to Tomahawk's. In
trinidad I plan to make their existing File object a
wrapper when
used with the commons configurator so that the fileupload
components can be interchangeable. If I can address all of
Tomahawk's requirements as well, then you guys can do the
same..
Ok thanks!. Long time ago, I take ExternalContextUtils
(because myfaces-commons-utils is for java 1.5) and correct
some stuff to make it compatible with java 1.4 (on tomahawk is
on org.apache.myfaces.tomahawk.util). Definitively it is
necessary to do something with utils, because trinidad 1.0.x
is java 1.4, so this cannot use myfaces-commons utils.
regards
Leonardo Uribe
Scott
Leonardo Uribe wrote:
Hi
I have made some changes (enabled multipart content support
for TomahawkFacesContextWrapper) on tomahawk.
The objective is have a solution of MYFACES-434 Myfaces
Portlet Enhancement.
I have tested this and works fine for me, but the last time
there was some problems doing this, so better advice
dev list
about the changes.
I'm enhancing the documentation and adding fileupload
support
for portlets.
Suggestions are welcome
regards
Leonardo Uribe
