On 8/4/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
should we ask on the user list for some *testing* help?
Since it's summer/vacation time, I guess not much will happen here :)
It never hurts to ask. It's a public project, and I don't see why
the public wouldn't help.
+1
On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I have opened http://issues.apache.org/jira/browse/MYFACES-1377 on this.
However, I've marked it priority Minor since it only generates an
error message rather than breaking
sounds good. tonight I am out.
I'll do on saturday if nobody was doing it before.
-Matt
On 8/4/06, Sean Schofield [EMAIL PROTECTED] wrote:
+1
On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I have opened
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
As for the getScrolling issue, I could've sworn this worked in the
latest simple examples *before* I switched in the rc core api jars.
Maybe I'm wrong though ... I will try to investigate further.
with 1.1.5 yes; the getScrolling is now
So is there a new RC we should be testing against? I can update it
with the latest branch later today perhaps.
Sean
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
@Tomahawk_1_1_4 branch:
works, when you compile against the *patched* shared-203
On 8/2/06, Matthias Wessendorf
On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote:
Why not apply it to 1.1.4 branch and merge it down? Eventually we
need to merge everything down. My vote is to fix it once merge it the
second time. But I don't know the nature of the fix so maybe I'm way
off here.
It's already in trunk,
Tell me what revision the check in was so I can revert it. Then just
apply to the trunk ok?
Sean
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote:
Why not apply it to 1.1.4 branch and merge it down? Eventually we
need to merge
I agree with Mike here. Matthias, can you explain the problem in more
detail? We should fix this problem before releasing (if there's a
problem to fix.)
Sean
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
As for the
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
It's already in trunk,
And then on 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
Tell me what revision the check in was so I can revert it. Then just
apply to the trunk ok?
This is very hard to follow. Maybe I'm quoting out of
On 8/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
It's already in trunk,
And then on 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
Tell me what revision the check in was so I can revert it. Then just
apply to the trunk ok?
This is
RANT MODE
However, I think it's a backward approach to be making patches to a
branch, and then porting them over at some later time to trunk.
Branches should be static except when applying maintenance fixes, and
those fixes should be merged over from trunk after being tested, not
the other way
In an attempt to not add confusion to this thread, and hopefully to infuse some encouragement, I just copied all the new SNAPSHOT jars into my production system and tested the hell out of it. Other than having to add a form around a jsCookMenu, everything seems to work really well. I did not have
Yes,
Martin changed on head the name of the getScrolling() function to
org_apache_myfaces_getScrolling() (JS function). So, Tomahawk post
1.1.4 (means 1.1.5-SNAPSHOT and following) don't render that
getScrolling() but the myfaces pre 1.1.5 (like 1.1.4 snapshot) does.
That was the reason for
And what I fixed was MYFACES-1376 for the branch of shared_203 + core_114;
that was the blocker Sean opend, and I guess wendy reffered to.
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/3/06, Wendy Smoak [EMAIL PROTECTED] wrote:
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED]
Hi Sean,
wendy posted the *new* RC to this folder
http://people.apache.org/builds/myfaces/core-1.1.x/
that contains the fix for your blocker.
-Matthias
On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
So is there a new RC we should be testing against? I can update it
with the latest
Mike
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I understand why we want to clean up our namespaces, but is this
cleanup really important enough to warrant breaking compatibility in
the 1.1 releases?
I think not; Maybe it is. There was no announcement or something like that.
For
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Maybe we should remove the *renamed* JS function and add it the the 1.2 branch ?
My vote would be for reverting this renaming and going back to the old name.
It's too bad that Martin isn't around to comment, though.
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Maybe we should remove the *renamed* JS function and add it the the 1.2
branch ?
My vote would be for reverting this renaming and going back to the old name.
that said, we have the
On 8/3/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Maybe we should remove the *renamed* JS function and add it the the 1.2
branch ?
My vote would be for reverting this renaming and going back to the old name.
... and now we're
I patched the 1.1.4 branch; so now 1.1.4 core works with
tomahawk 1.1.5-Snap
and tomahawk 1.1.4-SNAP (after you compile it against the *patched* shared_203)
Great.
-Matthias
Sean
On 8/3/06, Sean Schofield [EMAIL PROTECTED] wrote:
I patched the 1.1.4 branch; so now 1.1.4 core works with
tomahawk 1.1.5-Snap
and tomahawk 1.1.4-SNAP (after you compile it against the *patched*
shared_203)
Great.
but ... tomahawk 1.1.3 won't work with 1.1.4-RC (and post this)
let's
I'm assuming you mean apply it to the branch.
Sorry. That's what I meant.
As for the revision,
http://issues.apache.org/jira/browse/TOMAHAWK-467?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel
states 428204
I'm more than happy to learn how to do this myself
Without knowing to much about the reason for this, I'd vote like you!
+1 for using getScrolling
+1 I think that we can live with the simple getScrolling for now,
and leave the rename for the next major release (1.2). If this is what
is blocking the release I would say go for it, and lets
I understand why we want to clean up our namespaces, but is this
cleanup really important enough to warrant breaking compatibility in
the 1.1 releases?
No.
getScrolling has been used for a long time, and it's not just going to
break between 1.1.3 and 1.1.4, it's going to break anyone who's
looks like all people here are
-1 on keeping (or +1 on putting it to the 1.2 branch)
I'll wait until tonight (US time) and do some stuff there;
Makes sense?
Yes. Thanks for helping (again.)
Matthias Wessendorf
Sean
Ok,
I think this dif can stay
dif
public static void appendAutoScrollAssignment(StringBuffer
onClickValue, String formName)
{
+onClickValue.append(if(window.+AUTO_SCROLL_FUNCTION+!=undefined));
+onClickValue.append({);
ok,
I tested that
dif_to_revert
-private static final String AUTO_SCROLL_PARAM = autoScroll;
-private static final String AUTO_SCROLL_FUNCTION = getScrolling();
+private static final String AUTO_SCROLL_PARAM =
org_apache_myfaces_autoScroll;
+private static final String
Folks,
should we ask on the user list for some *testing* help?
Since it's summer/vacation time, I guess not much will happen here :)
.Matthias
On 8/3/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
ok,
I tested that
dif_to_revert
-private static final String AUTO_SCROLL_PARAM =
We are majorly bogged down on the Core 1.1.4 release. We need
*everyone* to do what they can to help get this release out the door.
Please see the wiki[1] and test the release candidate there. A good
start is to build the simple examples in the tomahawk HEAD and replace
the myfaces core jars
On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote:
We are majorly bogged down on the Core 1.1.4 release. We need
*everyone* to do what they can to help get this release out the door.
Please see the wiki[1] and test the release candidate there. A good
start is to build the simple examples in
Given how the last few releases have been very embarassing we need to
thoroughly test this puppy - and more then two or three people need to
test it.
As for the getScrolling issue, I could've sworn this worked in the
latest simple examples *before* I switched in the rc core api jars.
Maybe I'm
I think this issue might also affect h:dataTable since it's in the
shared package:
http://issues.apache.org/jira/browse/TOMAHAWK-467
I'll try testing and seeing if this is true. If so, the patch there
needs to be applied, and I'll try to get to that tomorrow if no one
else takes care of it by
On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote:
I know everyone is busy (myself included) but a few people have been
doing most of the heavy lifting for a long time now. We've added a
bunch of new committers lately and we have lots of old ones who aren't
doing very much to help. Lets step
On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I think this issue might also affect h:dataTable since it's in the
shared package:
http://issues.apache.org/jira/browse/TOMAHAWK-467
I'll try testing and seeing if this is true. If so, the patch there
needs to be applied, and I'll try to
I have opened http://issues.apache.org/jira/browse/MYFACES-1377 on this.
However, I've marked it priority Minor since it only generates an
error message rather than breaking functionality.
Since the patch is committed to head, I'm not sure what the process is
for backporting it to 1.1.4 or even
Sounds good Mike!
On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I think this issue might also affect h:dataTable since it's in the
shared package:
http://issues.apache.org/jira/browse/TOMAHAWK-467
I'll try testing and seeing
On 8/2/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
I have opened http://issues.apache.org/jira/browse/MYFACES-1377 on this.
However, I've marked it priority Minor since it only generates an
error message rather than breaking functionality.
Since the patch is committed to head, I'm not sure
Why not apply it to 1.1.4 branch and merge it down? Eventually we
need to merge everything down. My vote is to fix it once merge it the
second time. But I don't know the nature of the fix so maybe I'm way
off here.
Sean
On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Sounds good
Ok,
I used the given 1.1.4-CORE RC JARS and tested it against Trinidad. It
works for me!
I also remember, that Craig tested them in the past (yes, 1.1.4-core
RC) against shale.
So, now next is tomahawk-head (1.1.5) and the 1.1.4-core RC
-Matthias
On 8/2/06, Sean Schofield [EMAIL PROTECTED]
On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
So, now next is tomahawk-head (1.1.5) and the 1.1.4-core RC
no link was clickable... for the example I clicked ...
checking more on that
-Matthias
On 8/2/06, Sean Schofield [EMAIL PROTECTED] wrote:
We are majorly bogged down on the
svn commit: r421297
that causes the troubles for the current *branch* I try to apply that
into branch
-Matt
On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
So, now next is tomahawk-head (1.1.5) and the 1.1.4-core RC
no link
Ok, I patched two files from:
-core branch
-shared branch
problem solvred (getScrolling ...)
-Matthias
On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
svn commit: r421297
that causes the troubles for the current *branch* I try to apply that
into branch
-Matt
On 8/2/06, Matthias
As for the getScrolling issue, I could've sworn this worked in the
latest simple examples *before* I switched in the rc core api jars.
Maybe I'm wrong though ... I will try to investigate further.
with 1.1.5 yes; the getScrolling is now named org_apache_myfaces_getScrolling
that was committed
@Tomahawk_1_1_4 branch:
works, when you compile against the *patched* shared-203
On 8/2/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
As for the getScrolling issue, I could've sworn this worked in the
latest simple examples *before* I switched in the rc core api jars.
Maybe I'm wrong
44 matches
Mail list logo
