Hi folks!
I'm not sure if I'm seeing ghosts or if we still are broken since a while now
Please try the patch provided in
https://issues.apache.org/jira/browse/MYFACES-3649 yourself and provide
feedback.
If I didn't miss anything then we leak in classes from the myfaces-core-2.1.1
release via
Hi
2012/11/16 Mark Struberg strub...@yahoo.de:
Hi folks!
I'm not sure if I'm seeing ghosts or if we still are broken since a while now
I tried it and trunk is working.
Please try the patch provided in
https://issues.apache.org/jira/browse/MYFACES-3649 yourself and provide
feedback.
Development dev@myfaces.apache.org; Mark Struberg
strub...@yahoo.de
Cc:
Sent: Friday, November 16, 2012 4:30 PM
Subject: Re: trunk broken?
Hi
2012/11/16 Mark Struberg strub...@yahoo.de:
Hi folks!
I'm not sure if I'm seeing ghosts or if we still are broken since a
while now
:
Sent: Friday, November 16, 2012 4:40 PM
Subject: Re: trunk broken?
Well, I removed the core-impl-2.1.1 shading and started a CI build now.
Jenkins will tell us the truth.
If it's broken then we will not release next week but need to do a detailed
investigation.
LieGrue,
strub
Development dev@myfaces.apache.org
Cc:
Sent: Friday, November 16, 2012 4:40 PM
Subject: Re: trunk broken?
Well, I removed the core-impl-2.1.1 shading and started a CI build now.
Jenkins will tell us the truth.
If it's broken then we will not release next week but need to do a
detailed
I just checked out trunk, and tried mvn install
That results in a lot of compile errors on Trinidad Impl.
First one is this:
C:\java\trinidad-svn\trinidad\trinidad-impl\src\test\java\org\apache\myfaces\trinidadinternal\renderkit\ComponentDefinition.java:[31,54]
package
Now it fails for me;
not sure if you were expecting that :-)
On Dec 5, 2007 12:10 AM, Andrew Robinson [EMAIL PROTECTED] wrote:
I just checked in the pom.xml that uncovers the broken test cases.
Once they are all fixed, we can set the forkMode back to once for
performance reasons.
Committed
a bit higher in the stack trace, I just saw this:
[INFO] [surefire:test]
[INFO] Surefire report directory:
D:\work\Apache\___TRINIDAD_TRUNK\trinidad-impl\target\surefire-reports
javax.faces.FacesException: java.lang.ClassNotFoundException:
That is the exception that happens with the forking. Once the
CoreRenderKitTest is fixed (I cannot do it today), we can set the fork
to once or none and this error will go away. The real problem is that
CoreRenderKitTest is broken.
-Andrew
On Dec 5, 2007 3:41 AM, Matthias Wessendorf [EMAIL
I'm trying to test the 1.2.x trunk and it is not building. I pulled
down the latest trunk and the problem is there as well. Is someone
working on this, or is it my environment?
[surefire] Running
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafUtilsTest
[surefire] Tests run: 2,
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO] Apache MyFaces Trinidad ... SUCCESS [16.734s]
[INFO] Apache MyFaces Trinidad
to be safe, I am now saying bye bye to my repo.
-M
On Dec 4, 2007 9:02 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
[INFO]
[INFO] Reactor Summary:
[INFO]
Oh,
and this was behind the firewall.
can check outside of corp-network later.
-M
On Dec 4, 2007 9:02 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
[INFO]
[INFO] Reactor Summary:
[INFO]
I tried with a bare settings.xml and an empty .m2/repository -- same error
I am on Xubuntu gutsy Linux, what is your platform (perhaps it is
environment related)?
contents of
trinidad-impl/target/surefire-reports/org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafUtilsTest.txt:
Yeah, I'm running the same platform also Andrew and it's breaking for me
as well.
Andrew Robinson wrote:
I tried with a bare settings.xml and an empty .m2/repository -- same error
I am on Xubuntu gutsy Linux, what is your platform (perhaps it is
environment related)?
contents of
so, what do the surefire reports tell ?
They at least show where it breakes and on what method-call.
-Matthias
On Dec 4, 2007 10:16 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Yeah, I'm running the same platform also Andrew and it's breaking for me
as well.
Andrew Robinson wrote:
I tried
Like Matthias, I cleaned out my .m2/repository and trunk and found that
using mvn install was successful.
MVN 2.0.6
Java 1.5.0_13
Mac OS X 10.5.1
-Matt
On Dec 4, 2007 2:16 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Yeah, I'm running the same platform also Andrew and it's breaking for me
as
Börnd is running ubuntu linux,
perhaps he can help out.
-M
On Dec 4, 2007 10:38 PM, Matt Cooper [EMAIL PROTECTED] wrote:
Like Matthias, I cleaned out my .m2/repository and trunk and found that
using mvn install was successful.
MVN 2.0.6
Java 1.5.0_13
Mac OS X 10.5.1
-Matt
On Dec 4,
I cleaned everything out and got a new tree and it fails. :(
Matthias Wessendorf wrote:
Börnd is running ubuntu linux,
perhaps he can help out.
-M
On Dec 4, 2007 10:38 PM, Matt Cooper [EMAIL PROTECTED] wrote:
Like Matthias, I cleaned out my .m2/repository and trunk and found that
using
just compile
Matthias Wessendorf schrieb:
ok,
please check the test-case's surefire report.
Perhaps that brings light into the dark.
-M
On Dec 4, 2007 11:11 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
I cleaned everything out and got a new tree and it fails. :(
Matthias Wessendorf
Andrew is doing some research. He thinks it looks to be an ordering
issue. The surfire report contains the stacktrace Andrew sent earlier.
Scott
Matthias Wessendorf wrote:
ok,
please check the test-case's surefire report.
Perhaps that brings light into the dark.
-M
On Dec 4, 2007 11:11
The junit test cases are coded as order dependent -- but the tests
should be independent of each other.
The linux jre/junit must be choosing a different execution order.
This looks like a significant amount of work to fix to make the tests
truly independent of each other
-Andrew
On Dec 4, 2007
still problems with the jar plugin.
After adding a pluginManagement section for the jar plugin.
It's works
[INFO]
[INFO] Reactor Summary:
[INFO]
[INFO]
If you add forkModepertest/forkMode to the surefire
test plugin in the impl it will reproduce the problem.
-Andrew
On Dec 4, 2007 3:26 PM, Bernd Bohmann [EMAIL PROTECTED] wrote:
still problems with the jar plugin.
After adding a pluginManagement section for the jar plugin.
It's
Cool. Good luck with that Andrew.. :) LOL. Just kidding. Can you
write up a JIRA ticket?
Scott
Andrew Robinson wrote:
I just checked in the pom.xml that uncovers the broken test cases.
Once they are all fixed, we can set the forkMode back to once for
performance reasons.
Committed
FYI - I went ahead and commited the golden file changes r595766.
Perhaps I lost the email but I am a little concerned that I never saw
a continuum build failure for this so there may be yet a bigger issue
here too with the build automation.
Regards,
Matt
On Nov 15, 2007 6:21 AM, Matthias
That's great :), thanks a lot for updating the golden files.
regards,
Catalin
On Nov 16, 2007 8:25 PM, Matt Cooper [EMAIL PROTECTED] wrote:
FYI - I went ahead and commited the golden file changes r595766.
Perhaps I lost the email but I am a little concerned that I never saw
a continuum
There is also a wiki page about it (see [1])
-M
[1] http://wiki.apache.org/myfaces/Trinidad_RenderKit_test_framework
On Nov 15, 2007 2:44 AM, Catalin Kormos [EMAIL PROTECTED] wrote:
Hi Jeanne,
That's great, many thanks for providing this information, as i wasn't very
sure how to tackle it.
The current trunk (1.0.5) is broken in SVN with the golden files test
failing for the treeTable. Looks like img tags are now being used
instead of span elements.
I think it was revision 595029 that broke it:
r595029 | ckormos | 2007-11-14 13:14:19 -0700 (Wed, 14 Nov 2007) | 1 line
Changed paths:
Hi,
Yes you're right, sorry about that; before, text icons were supported, and
the patch introduced image icons, and the tests weren't patched yet. If
nobody has any objections, we'll update the tests also, asap, to test for
img instead of span in the ouput.
regards,
Catalin
On Nov 14, 2007
No objections.
The normal practice is when I see test failures, I go to the
test-failures directory. In your case, you see
treeTable-minimal-golden.xml, treeTable-minimalIE-golden.xml, etc.
Then what I do is diff the src with the test-failures. So you would
look at the diff between the src
Hi Jeanne,
That's great, many thanks for providing this information, as i wasn't very
sure how to tackle it.
regards,
Catalin
On Nov 15, 2007 3:33 AM, Jeanne Waldman [EMAIL PROTECTED] wrote:
No objections.
The normal practice is when I see test failures, I go to the
test-failures
32 matches
Mail list logo
