It is both intuitive and automatic.
you take build/build.xml and call the target dist-all. That's it.
Anyways, it would be great if someone starts introducing Maven - then
we can compare and finally decide which one is better. The thing is
that none of us has too much experience with Maven so
@Jan:
automate JSF compatibility tests: I severly doubt this will be
automatable. You don't know how complicated this thing is to be run
even manually ;)
regards,
Martin
On 10/23/05, ir. ing. Jan Dockx [EMAIL PROTECTED] wrote:
On 23 Oct 2005, at 3:58, John Fallows wrote:
On 10/22/05, ir.
The thing is that the resource bundle (the f:loadBundle tag) is not
processed on an AJAX postback. The f:loadBundle is pure JSP and is
only processed in the rendering phase - the rendering phase is not
executed but for the ajax-enabled data table.
So what you need to do is to have a managed bean
Ok, done!
http://wiki.apache.org/myfaces/Companies_Using_MyFaces
Everybody, put your company/institution if you are using MyFaces!
Let's make this list grow!
Bruno
2005/10/22, Martin Marinschek [EMAIL PROTECTED]:
Yes to your first suggestion!
let's create something like this.
For the
[
http://issues.apache.org/jira/browse/MYFACES-543?page=comments#action_12355607
]
Marcus Schiesser commented on MYFACES-543:
--
thank you for your answer mathias.
i see that reusing the component tree is a problem, if they don't clean up
their
Hi all
I got a question.
Can one explain me, why the binding option from the tag
NavigationMenuItem is not supported in the NavigationMenuItem class.
Is there any reason to not support it?
As we do not have the option to set a listener for the class NavigationMenuItem
it is
Javascript conflict between x:tree2 and x:inputCalendar
---
Key: MYFACES-743
URL: http://issues.apache.org/jira/browse/MYFACES-743
Project: MyFaces
Type: Bug
Components: Tomahawk
Versions: 1.1.1
[
http://issues.apache.org/jira/browse/MYFACES-743?page=comments#action_12355619
]
Luciano Medina commented on MYFACES-743:
I was using the nightly build 20051019, and I've just found that the bug is not
present at the last release (1.1.1RC3).
However, since there is duplication, then upgrading either of these
(Runtime / Tomahawk) in a deployed environment independently would
cause the shared classes to be upgraded as well, for both of the
projects. This assumes the classpath is setup to place the newest JAR
last, which might not
[
http://issues.apache.org/jira/browse/MYFACES-737?page=comments#action_12355621
]
Neal Haggard commented on MYFACES-737:
--
I pulled from Branches/1_1_1. Should I be using Trunk instead?
JSCookMenu can't be used as a child of a form, and
Ok, so maybe this is the thread for these comments I have sitting on
for some time.
_Please_ don't be offended, we _do_ appreciate the work and the results
of the MyFaces contributors and the whole community.
But you definitely have a release problem.
3 anecdotal examples: the ages it took
[ http://issues.apache.org/jira/browse/MYFACES-709?page=all ]
sean schofield closed MYFACES-709:
--
Resolution: Cannot Reproduce
You must be configuring your extension filter incorrectly. There are no known
issues with this aspect of tree2.
[ http://issues.apache.org/jira/browse/MYFACES-722?page=all ]
sean schofield closed MYFACES-722:
--
Resolution: Won't Fix
Definitely would violate the spec for the implementation components. It might
be nice to have for the Tomahawk components but
Hi all,
This thread is a little bit overloaded with issues and suggestions in
the meantime. So I do not want to make thinks worse and only pick out
the (IMO) most important point, that really has a major impact on
future releases: the shared classes repackage issue.
Regarding shared classes: One
[ http://issues.apache.org/jira/browse/MYFACES-737?page=all ]
Neal Haggard updated MYFACES-737:
-
Attachment: jscookFormPatchV5.txt
Version 5 makes the changes to the Trunk, instead of branch 1_1_1. Note that I
still had to add the name of the theme
PRETTY_HTML option is not being universally honored
---
Key: MYFACES-744
URL: http://issues.apache.org/jira/browse/MYFACES-744
Project: MyFaces
Type: Improvement
Components: Tomahawk
Versions: 1.1.1
[
http://issues.apache.org/jira/browse/MYFACES-737?page=comments#action_12355632
]
Neal Haggard commented on MYFACES-737:
--
Also, adding the themeName to the javascript location for the theme specific
resources allows us to mirror the MyFaces setup
Manfred,
I agree the shared classes is the most important issue to focus on. I
also agree -1 on repackaging them. We would live to regret that
decision.
I agree that changing what's in the endorsed lib dir would fix the
problem and ultimately when users have a problem with JBoss, etc. they
go
[
http://issues.apache.org/jira/browse/MYFACES-711?page=comments#action_12355634
]
Kevin Hutson commented on MYFACES-711:
--
Hi,
I was going to join in on reporting this problem. I had recently downloaded a
build from 10/17/2005 in order to fix a
[
http://issues.apache.org/jira/browse/MYFACES-742?page=comments#action_12355635
]
Mike Kienenberger commented on MYFACES-742:
---
Dennis, this is great stuff! I'm patching my copy of myfaces with it now.
However, the first thing I noticed was
Are we satisified that there are no major issues in RC3? Again, I
have not had time to test so I am relying on the my fellow committers
and the rest of the developer community.
Any true show stopper bugs that affect the basic implementation? jar
files? Everything else should be dealt with on
[
http://issues.apache.org/jira/browse/MYFACES-742?page=comments#action_12355639
]
Dennis Byrne commented on MYFACES-742:
--
thank you for the kind words Mike.
yeah, encode64 will need to go back, as well as
HtmlResponseStateManager.decode64 .
HtmlResponseStateManager.decode64 is a private method. It can be
deleted now that you removed references to it.
On 10/24/05, Dennis Byrne (JIRA) dev@myfaces.apache.org wrote:
[
http://issues.apache.org/jira/browse/MYFACES-742?page=comments#action_12355639
]
Dennis Byrne commented on
[
http://issues.apache.org/jira/browse/MYFACES-742?page=comments#action_12355640
]
Mike Kienenberger commented on MYFACES-742:
---
HtmlResponseStateManager.decode64 is a private method. It can be
deleted now that you removed all references to it.
[
http://issues.apache.org/jira/browse/MYFACES-742?page=comments#action_12355641
]
Mike Kienenberger commented on MYFACES-742:
---
Unsurprisingly, everything is working as advertised.
One thing that is going to need more attention is documentation
[
http://issues.apache.org/jira/browse/MYFACES-742?page=comments#action_12355643
]
Dennis Byrne commented on MYFACES-742:
--
yeah, if nobody objects, I can put a main() in StateUtils so that developers
could do command line encoding, or random password
I wonder if we should change this to use DOM updating rather than the
innerHTML so we don't have to hack around IE's limitations and can
probably have more flexibility like only updating a particular column.
TravisOn 10/24/05, Martin Marinschek [EMAIL PROTECTED] wrote:
The thing is that the
I update the sources on the 20th of october (last week). The build
process went ok, the mentioned problem appears in runtime. I'll try to
update and re-build anyway.
-Original Message-
From: Volker Weber [mailto:[EMAIL PROTECTED]
Sent: Saturday, 22 October 2005 12:16 a.m.
To: MyFaces
[
http://issues.apache.org/jira/browse/MYFACES-602?page=comments#action_12355649
]
Henrik Bentel commented on MYFACES-602:
---
Just a FYI.
The latest weblogic version, Weblogic 9.0 includes web-app_2_3.dtd file on the
server classpath.
It is included
Unfortunately that is not so easy either. I cannot go into details
about the testing process due to a Nondisclosure Agreement that was
signed. So you will not be able to look at it and we can discuss the
contents of the test.
Sorry but ASF does not control the TCK, Sun does, and so we need to
@Martin
When was this resolved? I had a patch for this but now I can't
remember if I applied it or someone else did. Please help a confused
old man ... :-)
sean
On 10/21/05, Martin Marinschek [EMAIL PROTECTED] wrote:
Do you use client-side or server-side state saving?
Try switching to
Sean Schofield wrote:
Are we satisified that there are no major issues in RC3? Again, I
have not had time to test so I am relying on the my fellow committers
and the rest of the developer community.
Any true show stopper bugs that affect the basic implementation? jar
files? Everything else
IMO that is NOT a blocker for the 1.1.1 release. There are lots of
little issues with Tomahawk components. If we waited to get every
last one done we would never release. The main thing is to get this
out so we can fix the problem with myfaces-all.jar in 1.1.0 (a
legitimate blocker.)
Once this
[
http://issues.apache.org/jira/browse/MYFACES-744?page=comments#action_12355656
]
Simon Kitching commented on MYFACES-744:
As people have mentioned on the email lists, updating every renderer to check
for this flag and render cleaner output if it
Can I nominate http://issues.apache.org/jira/browse/MYFACES-730?
While it's not _preventing_ anything, it certainly raises the pain
level to a certain height.On 10/24/05, Sean Schofield [EMAIL PROTECTED] wrote:
IMO that is NOT a blocker for the 1.1.1 release.There are lots oflittle issues with
Sean Schofield wrote:
IMO that is NOT a blocker for the 1.1.1 release. There are lots of
little issues with Tomahawk components. If we waited to get every
last one done we would never release. The main thing is to get this
out so we can fix the problem with myfaces-all.jar in 1.1.0 (a
I haven't investigated this issue very closely but I doubt that
changes in the 1.1.1 branch caused this bug. Its certainly possible
but we've been limiting the changes to must have fixes. Its hard to
imagine one of these changes impacting jsCookmenu.
Unfortunately I do not have time to track
[
http://issues.apache.org/jira/browse/MYFACES-744?page=comments#action_12355658
]
Brendan Conner commented on MYFACES-744:
Putting the fix in ExtensionsFilter sounds logical to me.
PRETTY_HTML option is not being universally honored
See comments inline...
Sean Schofield wrote:
I haven't investigated this issue very closely but I doubt that
changes in the 1.1.1 branch caused this bug. Its certainly possible
but we've been limiting the changes to must have fixes. Its hard to
imagine one of these changes impacting
Check your SVN again. r291865 was on the trunk not the branch. So
now you have proved my point. It was not introduced on the branch so
a fix in 1.1.1 is unecessary.
sean
On 10/24/05, Simon Kitching [EMAIL PROTECTED] wrote:
See comments inline...
Sean Schofield wrote:
I haven't
[
http://issues.apache.org/jira/browse/MYFACES-730?page=comments#action_12355660
]
Simon Kitching commented on MYFACES-730:
This report will be a whole lot of pain to deal with :-(.
Firstly, I presume it only happens on Windows. Such file-locking
Sean Schofield wrote:
Check your SVN again. r291865 was on the trunk not the branch. So
now you have proved my point. It was not introduced on the branch so
a fix in 1.1.1 is unecessary.
Well, yes the commit *was* done on TRUNK. But the 1_1_1 branch was
created in R291992, so the change is
[
http://issues.apache.org/jira/browse/MYFACES-744?page=comments#action_12355663
]
sean schofield commented on MYFACES-744:
Why not just put it in its own filter? Why does extension filter have to do
everything? Personally I am not a fan of this
[ http://issues.apache.org/jira/browse/MYFACES-434?page=all ]
Shinsuke SUGAYA updated MYFACES-434:
Attachment: headerresource_for_j2.tar.gz
Attached files for Jetspeed2.
You also need to add myfaces dependency to
[
http://issues.apache.org/jira/browse/MYFACES-737?page=comments#action_12355670
]
Simon Kitching commented on MYFACES-737:
I've had a look at the patch and it seems good to me. I would definitely like
to see this applied to TRUNK as it would
I'm just wondering how the other developers have their sandbox examples
setup in Intellij Idea. I find that sandbox needs some
things from tomahawk examples like head.inc, but there are some naming
issues like two examples-config.xml. It's been working fine for a
while, but I just ran into an
[
http://issues.apache.org/jira/browse/MYFACES-730?page=comments#action_12355674
]
Steve Peterson commented on MYFACES-730:
Is code review really the only way to get to this? I'd be willing to help but
don't know where to start.
I just tried to
Not so. The branch was created off of the 1.1.0 release point. Bill,
please correct me if I am wrong.
sean
On 10/24/05, Simon Kitching [EMAIL PROTECTED] wrote:
Sean Schofield wrote:
Check your SVN again. r291865 was on the trunk not the branch. So
now you have proved my point. It was
svn log --stop-on-copy --verbose .
r291992 | bdudney | 2005-09-28 05:33:25 +1200 (Wed, 28 Sep 2005) | 1 line
Changed paths:
A /myfaces/tomahawk/branches/1_1_1 (from /myfaces/tomahawk/trunk:291991)
Tagging the 1.1.1
Hey Sean,
On 10/24/05, Sean Schofield [EMAIL PROTECTED] wrote:
I agree the shared classes is the most important issue to focus on. I
also agree -1 on repackaging them. We would live to regret that
decision.
Your current position is clear, but not your rationale. Can you
please elabotate so
[ http://issues.apache.org/jira/browse/MYFACES-742?page=all ]
Dennis Byrne updated MYFACES-742:
-
Attachment: myfaces.share.oct.24.txt
added command line convenience for base 64 encoding, restored binary
compatibility per discussion w/ Mike.
Example:
51 matches
Mail list logo
