Please replace MessageUtilsTest with the attached file or try to apply
the patch or change MockFacesContext to FacesContext in MessageUtilsTest
Bernd
Sean Schofield schrieb:
MessageUtilsTest fails b/c it cannot find MockFacesContext. I have
already renamed one of the files for you in svn. I
[
http://issues.apache.org/jira/browse/MYFACES-731?page=comments#action_12362522
]
Stijn Van Bael commented on MYFACES-731:
I'm experiencing a similiar problem using Tomcat 5.5.12, Hibernate 3.1 with
annotations and MyFaces 1.1.1 when submitting a
Hi!
I cant build the current svn head due to the class StateUtilsTestCase
defined in an file named
myfaces/commons/src/test/java/org/apache/myfaces/util/StateUtilsAbstractCase.java
After renaming the file to StateUtilsTestCase.java it worked.
Ciao,
Mario
Mathias Brökelmann wrote:
It´s fixed now. Thanks Mario.
resoved, verified!
Thanks!
Ciao,
Mario
We are not talking about an ICLA, but about a CCLA here, I guess.
regards,
Martin
On 1/12/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi Simon,
Obsidium has filled out a corporate CLA. It was mailed to Apache in
September last year. I have no idea about where I would look to confirm
We are not talking about an ICLA, but about a CCLA here, I guess.
yap, since companies can't file ICLA.
Anyway, there are not listed at the mentioned website.
so Manfred? or Ted? can help out on that issue?
(double checking the state of the paperwork)
-Matthias
regards,
Martin
On 1/12/06,
Welcome Bernd and Volker! and thanks for all your work!
Bruno
2006/1/12, Sean Schofield [EMAIL PROTECTED]:
Yes welcome to both of you! The MyFaces project is benefiting from
Bernd's hard work on Maven at this very moment. I am checking in his
last patch.
Sean
On 1/11/06, Simon Kitching
Actually that's a known problem. Bernd had me rename the file in SVN
(which I did) but then his patch didn't work so I didn't check in the
part that needs the new file name. I had to wait for him to send me a
revised patch this morning. So I'm going to revert mbr's change again
(but not until
I'm trying to run Bruno's patches which fix the unit tests (nice work
by the way!) Anyways, one of the tests in commons requires
MockFacesContext which is in api. The issue is that it can't find
MockFacesContext even with the commons-api dependency. This is
because the mock stuff is in the
Hi!
Are there plans in the future JSF spec to make the managed bean creation
factory configureable?
something like:
factory
managed-bean-factory
For some reason I would like to read a managed bean from a serialized
store or use a specialized factory to create the bean instead of
Where is the MockFacesContext used?
In MessageUtilTest MockFacesContext is not needed, have you received my
last patch for commons?
Bernd
Sean Schofield schrieb:
I'm trying to run Bruno's patches which fix the unit tests (nice work
by the way!) Anyways, one of the tests in commons requires
Temproarily I have fixed this by copying the MockFacesContext and
making it a inner class called MockFacesContext2. We should probably
come up with something better long term though.
Maybe we could use the Shale Test Framework. Its already got a lot of
mock objects for JSF. I haven't looked at
Yes but it was causing all sorts of issues because I already applied
your earlier patch. Do you have karma yet? Go ahead and update my
latest commits. If you don't have karma yet I can apply another
patch.
Also there are still a few errors (not failures) in the commons tests.
Maybe your
Hello Sean,
I commit one missing change.
The change was very easy you don't need a own MockObject for easymock :-)
Have a nice day
Bernd
Sean Schofield schrieb:
Yes but it was causing all sorts of issues because I already applied
your earlier patch. Do you have karma yet? Go ahead and
Great. Everything works now!
Sean
On 1/12/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
Hello Sean,
I commit one missing change.
The change was very easy you don't need a own MockObject for easymock :-)
Have a nice day
Bernd
Sean Schofield schrieb:
Yes but it was causing all sorts of
Since my understanding of the goal is to eventually merge Tobago in
with tomahawk, would it make more sense to move the servlet into
myfaces-commons, and have tobago depend on it? It'd be good if we
could do the same for any other tobago pieces that aren't directly
tied to the tobago
Unclear licensing of myfaces-jsf-api.jar
Key: MYFACES-1021
URL: http://issues.apache.org/jira/browse/MYFACES-1021
Project: MyFaces
Type: Wish
Components: JSR-127
Reporter: Ivan Kudibal
Does myfaces-jsf-api.jar apply
[ http://issues.apache.org/jira/browse/MYFACES-1021?page=all ]
Martin Marinschek closed MYFACES-1021:
--
Fix Version: Nightly
Resolution: Invalid
Assign To: Martin Marinschek
This is not something we should discuss on a jira-request.
On 1/12/06, Sean Schofield [EMAIL PROTECTED] wrote:
Temproarily I have fixed this by copying the MockFacesContext andmaking it a inner class called MockFacesContext2.We should probablycome up with something better long term though.Maybe we could use the Shale Test Framework.Its already got a lot
Can someone add the apache license info to the top of this file, as well as all
four of it's children? (I didn't want to open a ticket for this).
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 12, 2006 08:51 AM
To: 'MyFaces Development'
On 1/12/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Are there plans in the future JSF spec to make the managed bean creation
factory configureable?
http://wiki.apache.org/myfaces/FAQ:
=
I don't like something about the JSF specification. How can I
Also possible that Adam or Manfred are listining,
they can bring it up, more easily, I guess :-)
-Matthias
On 1/12/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
On 1/12/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Are there plans in the future JSF spec to make the managed bean
Bernd,
Do you want to do the honors?
Sean
On 1/12/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Can someone add the apache license info to the top of this file, as well as
all four of it's children? (I didn't want to open a ticket for this).
-Original Message-
From: Sean Schofield
Perhaps a custom variable resolver could be the solution?
Dennis Byrne
-Original Message-
From: Matthias Wessendorf [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 12, 2006 01:48 PM
To: 'MyFaces Development'
Subject: Re: managed bean creation factory
Also possible that Adam or Manfred
On 1/12/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Perhaps a custom variable resolver could be the solution?
mmm, I like more a custom variable resolver for usecases when you
don't *define* your beans in faces-cfg. For instance when you are
using Spring framework.
But if you like to change the
-Original Message-
From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
Subject: managed bean creation factory
Are there plans in the future JSF spec to make the managed
bean creation factory configureable?
For some reason I would like to read a managed bean from a
serialized store
On 1/12/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Perhaps a custom variable resolver could be the solution?
Feedback to the EG alias (mentioned earlier in the thread) would
definitely be a good way to bring the idea to the expert group's
attention.
In the mean time, I was faced with exactly the
(Maybe should be moved to the user list...)
My recipe (for better or worse) is to use Spring with JSF-Spring, which
offers the same functionality. The latest JSF-Spring, 3.0.0M3, has fixed
Yes, right. JSF-Spring has nice features, using faces scopes for
spring managed beans, using spring-aop
i think matze has already added the license.
Maybe a checkstyle report can check this in the future.
+1 for a checkstyle to check for license
I have one problem
the xmlns=http://java.sun.com/JSP/TagLibraryDescriptor; attribute in
the taglib node caused a problem with the tlddoc report.
No indenting for now
Sean Schofield schrieb:
i think matze has already added the license.
Maybe a checkstyle report can check this in the future.
+1 for a checkstyle to check for license
I have one problem
the xmlns=http://java.sun.com/JSP/TagLibraryDescriptor; attribute in
the taglib
Sorry, I have no possibility to check CCLAs myself, only the ICLAs.
I will post a proposal to the board to provide a list of all CCLAs as well.
Manfred
2006/1/12, Matthias Wessendorf [EMAIL PROTECTED]:
We are not talking about an ICLA, but about a CCLA here, I guess.
yap, since companies
OK, I figured out what Bernd was talking about with the parent POM in
the snapshot repository. Great idea! I am working on setting up the
snapshot repository now.
I am thinking the parent pom should be part of myfaces-tools. Bernd
had proposed a tools subproject where we put the archetype
Hello Sean,
Sean Schofield schrieb:
OK, I figured out what Bernd was talking about with the parent POM in
the snapshot repository. Great idea! I am working on setting up the
snapshot repository now.
Good idea, but why we don't use the apache snapshot repository?
I am thinking the parent
Good idea, but why we don't use the apache snapshot repository?
That's what I meant. I'm creating a myfaces dir in there for our use.
I would prefer to stay the master pom in api.
The place of the master pom is not real a problem but changing the
artifactId or groupid would cause more
Trust me the version number is not a problem.
If you want to inherit the version you are using ${version} and a parent
ref.
If you don't want to inherit the version you add a own version tag in
the pom.
Sean Schofield schrieb:
Good idea, but why we don't use the apache snapshot repository?
Manfred Geiler schrieb:
2006/1/12, Sean Schofield [EMAIL PROTECTED]:
i think matze has already added the license.
Maybe a checkstyle report can check this in the future.
+1 for a checkstyle to check for license
I have one problem
the xmlns=http://java.sun.com/JSP/TagLibraryDescriptor;
Craig McClanahan schrieb:
The Shale test framework depends only on the servlet, JSP, and JSF apis
... it has no dependencies on the rest of Shale. It is packaged in a
manner where the test framework could be released separately from an
overall Shale release, if that becomes appropriate.
done!
On 1/12/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Can someone add the apache license info to the top of this file, as well as
all four of it's children? (I didn't want to open a ticket for this).
-Original Message-
From: Sean Schofield [mailto:[EMAIL PROTECTED]
Sent:
As a starting point I think we should investigate what Shale has to
offer. I imagine there is a lot of overlap between our testing needs.
Sean
On 1/12/06, Bernd Bohmann [EMAIL PROTECTED] wrote:
Craig McClanahan schrieb:
The Shale test framework depends only on the servlet, JSP, and JSF
I'd like to get our continuum server setup in the zone. A few people
mentioned they would like to help. Since I am completely new to
continuum it would be much easier if someone could volunteer to help.
Sean
I am willing to help with this, although is quite late here in old
europe :-) I have a few minutes to spare now...
Bruno
2006/1/13, Sean Schofield [EMAIL PROTECTED]:
I'd like to get our continuum server setup in the zone. A few people
mentioned they would like to help. Since I am completely
Matthias Wessendorf wrote:
Yes, right. JSF-Spring has nice features, using faces scopes for
spring managed beans, using spring-aop inside of faces-cfg by defining
DefaultAdvisorAutoProxyCreator as an application scoped managed
bean.
and so on.
have in mind, that JSF-Spring is *not* part of the
On Thu, 2006-01-12 at 22:17 +0100, Manfred Geiler wrote:
2006/1/12, Sean Schofield [EMAIL PROTECTED]:
i think matze has already added the license.
Maybe a checkstyle report can check this in the future.
+1 for a checkstyle to check for license
I have one problem
the
On 1/12/06, Sean Schofield [EMAIL PROTECTED] wrote:
As a starting point I think we should investigate what Shale has tooffer.I imagine there is a lot of overlap between our testing needs.+1. We'd want to make sure that all the needs for both groups were met so we could skip any redundant
The Problem is the
taglib xmlns=http://java.sun.com/JSP/TagLibraryDescriptor;
in the generated tld.
The tlddoc generator doesn't allow
http://java.sun.com/JSP/TagLibraryDescriptor for the xmlns attribute.
One solution is
remove the
PUBLIC -//Sun Microsystems, Inc.//DTD JSP Tag Library
Hello Sean,
I don't think we need a master pom at this place.
As you described this pom would never released.
In future someone try to checkout an old tag from myfaces-impl to
compile the source, the pom is fetched from the maven/trunk/master-pom.
But the information of the pom is not
46 matches
Mail list logo
