continuum-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brent Atkinson <brent.atkin...@gmail.com>
Subject Re: Getting Selenium tests updated
Date Thu, 23 Aug 2012 06:41:08 GMT
Hi Brett,

I figured out that:

 1) Jetty doesn't seem to like the resource configuration for the new setup
 2) The tomcat profile wasn't active even though it was declared active by
default, causing cargo to use jetty.

Once I realized this, I simply specified the following from the
continuum-webapp-test module:

$ mvn -Ptomcat7x clean install

Any idea about what would cause this?

I believe I fixed the build.sh and windows path issues, but I'm still
seeing failures when deleting certain files and timeouts for a few last
tests. I'm still looking into these.

Brent

On Wed, Aug 22, 2012 at 7:54 AM, Brent Atkinson <brent.atkinson@gmail.com>wrote:

> Brett,
>
> I am having a little trouble due recent changes made in r1367475 to the
> cargo configuration. Basically, the default cargo won't work. I get an
> error due to mail/Session references not being present. Looking at the
> changes it looks like that may have been intentional? How should I go about
> running the entire test suite as before (mvn clean install)?
>
> Brent
>
>
> On Tue, Aug 21, 2012 at 2:09 PM, Brent Atkinson <brent.atkinson@gmail.com>wrote:
>
>> Yes, I will try to:
>>
>> * cover windows with a similar test if feasible: build.bat
>> * fix the path validation
>> * discover the source of the deletion issue... I think it is a file
>> handle as you said... will check and try to track it down if your fix
>> doesn't address it for me.
>>
>> Brent
>> On Aug 21, 2012 9:57 AM, "Brett Porter" <brett@apache.org> wrote:
>>
>>>
>>> On 21/08/2012, at 2:08 PM, Brent Atkinson <brent.atkinson@gmail.com>
>>> wrote:
>>>
>>> > The time outs might be due to the fact that the build still appears to
>>> be
>>> > trying to execute build.sh (DistributedBuildTest.java:156).
>>>
>>> So, these just need to be disabled on Windows - or we could have a
>>> build.bat alternative for that?
>>>
>>> >
>>> > The testAddMavenToolWithBuildEnvironment failure appears to be because
>>> of
>>> > the characters in my Windows path "C:\Program Files (x86)\Apache
>>> Software
>>> > Foundation\apache-maven-2.2.1\bin\.."
>>>
>>> Looks like overly strict validation - would you be comfortable fixing
>>> that up?
>>>
>>> >
>>> > I can't see why the ReleaseTest.java's setUp() fails, but I think it
>>> might
>>> > be running up against a path length limitation.
>>>
>>> Shouldn't be... it's only in target/conf/prepared-releases of your test
>>> checkout. I think there's a chance that it's an open file handle - I just
>>> fixed an unlikely one, did that help?
>>>
>>> - Brett
>>>
>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message