Can anyone help with this? It looks like velocity errors are being
generated from a checkstyle report.
Dennis Byrne
[WARNING] Error loading report org.apache.maven.changelog.ChangeLogReport -
AbstractMethodError: canGenerateReport()
[WARNING] Error loading report
On 3/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Can anyone help with this? It looks like velocity errors are being
generated from a checkstyle report.
I vote we move it over to the (newer) Continuum instance on port 8081
and see if it works there.
Any committer is welcome to a Continuum
On 3/24/07, Wendy Smoak [EMAIL PROTECTED] wrote:
I vote we move it over to the (newer) Continuum instance on port 8081
and see if it works there.
It was already there, and building fine. I changed the build
definition to deploy, etc.
Has the password changed or does the user just no longer exist? Maybe I can
kill the dir - which machine is this on?
Dennis Byrne
On 3/24/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 3/24/07, Wendy Smoak [EMAIL PROTECTED] wrote:
I vote we move it over to the (newer) Continuum instance on
On 3/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Has the password changed or does the user just no longer exist? Maybe I can
kill the dir - which machine is this on?
It was just me forgetting the password. I removed core/api/impl from
the old continuum on port 8080, but I still don't know
I don't know either, but thanks.
Dennis Byrne
On 3/24/07, Wendy Smoak [EMAIL PROTECTED] wrote:
On 3/24/07, Dennis Byrne [EMAIL PROTECTED] wrote:
Has the password changed or does the user just no longer exist? Maybe I
can
kill the dir - which machine is this on?
It was just me forgetting
Hi,
Can someone with permissions add this artifact to continuum?
org.apache.myfaces.core:myfaces-build:jar:1.2.0-SNAPSHOT
It is in the 1.2 branch, the core/build folder...
Thanks!
Bruno
On 02/12/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report :
On 12/1/06, Bruno Aranda [EMAIL PROTECTED] wrote:
Can someone with permissions add this artifact to continuum?
org.apache.myfaces.core:myfaces-build:jar:1.2.0-SNAPSHOT
It is in the 1.2 branch, the core/build folder...
Done. Or attempted, anyway. We'll see if it works.
--
Wendy
On 2/20/06, Craig McClanahan [EMAIL PROTECTED] wrote:
I did indeed see that (thanks for the fix) ... and Sean has already checked
that change in (I see it in the trunk sources for Shale that I just checked
out), so it will be in the 20060221 nightly build. That doesn't necessarily
translate
The call is required in the setUp() method to make things work correctly on
the *first* test, when you have the MyFaces implementation in the classpath
of the tests. Calling it in tearDown() doesn't hurt anything, but protects
test developers who try to subvert the JUnit test lifecycle stuff.
fyi - IIRC we tackled this problem slightly differently in the ADF Faces codebase.In an effort to fully isolate anything that might be keyed by ContextClassLoader (including FactoryFinder internal state), we created a trivial wrapper ClassLoader to provide a unique ContextClassLoader in setUp()
Development'
Subject: Re: FactoryFinder.releaseFactories() - was [continuum] BUILD FAILURE:
API
fyi - IIRC we tackled this problem slightly differently in the ADF Faces
codebase.
In an effort to fully isolate anything that might be keyed by
ContextClassLoader (including FactoryFinder internal
Hi Dennis,On 2/20/06, Dennis Byrne [EMAIL PROTECTED] wrote:
Do you guys have anything fancy for ThreadLocal references of FacesContext?Did you set this to null per TestSuite? per TestCase? per test method ?Yes, IIRC there is a TestFacesContextFactory implicitly registered with the FactoryFinder by
On 2/20/06, John Fallows [EMAIL PROTECTED] wrote:
fyi - IIRC we tackled this problem slightly differently in the ADF Faces codebase.In an effort to fully isolate anything that might be keyed by ContextClassLoader (including FactoryFinder internal state), we created a trivial wrapper ClassLoader to
That is a *really* good idea ... I'll be adding it to Shale's test framework
tonight. I don't see it as mutually exclusive with any of the other cleanups
we are doing to ensure that different tests do not interfere with each
other.
Craig
You may want to look at this when you do that.
On 2/20/06, Dennis Byrne [EMAIL PROTECTED] wrote:
That is a *really* good idea ... I'll be adding it to Shale's test frameworktonight. I don't see it as mutually exclusive with any of the other cleanupswe are doing to ensure that different tests do not interfere with each
other.CraigYou may want
On 2/19/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report :
http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/34/buildId/511
Build statistics:
State: Failed
...
[INFO] snapshot struts:shale-test:1.0.1-SNAPSHOT: checking
[mailto:[EMAIL PROTECTED]
Sent: Sunday, February 19, 2006 10:27 PM
To: 'MyFaces Development'
Subject: Re: [continuum] BUILD FAILURE: API
On 2/19/06, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report :
http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm
I updated the Shale snapshots about half an hour ago... coincidence?
Wendy
This would have happened w/ or w/out your update.
The fix for this was to put FactoryFinder.releaseFactories() in setup() and in
tearDown() . This setup() call is to clear configured Factory info from
previous tests (
On 2/19/06, Dennis Byrne [EMAIL PROTECTED] wrote:
I updated the Shale snapshots about half an hour ago... coincidence?WendyThis would have happened w/ or w/out your update.The fix for this was to put FactoryFinder.releaseFactories() in setup() and in tearDown() .This setup() call is to clear
Purely speaking, FactoryFinder.releaseFactories() should
only be necessary in tearDown() - which is where it makes
the most sense, since releasing factories is cleanup, which
is the job of tearDown().
Practically speaking, it's simplest and safest to call it
in both methods - which means that
On 2/19/06, Adam Winer [EMAIL PROTECTED] wrote:
Purely speaking, FactoryFinder.releaseFactories() shouldonly be necessary in tearDown() - which is where it makesthe most sense, since releasing factories is cleanup, whichis the job of tearDown().Practically speaking, it's simplest and safest to
22 matches
Mail list logo
