jwebunit-development — Concerns current development ongoing in JWebUnit.

RE: [Jwebunit-development] RE: Problem with TestServer in debug m ode

[Nick N. <Nic...@sn...>]

I'm all for using something else.

However, I did find a workaround in debug mode.  You can't interuppt the
beginAt methods or any gotoPage methods.
I just put a breakpoint after these lines.

Sounds like a generaic test webapp using jetty.  I'm not too familair with
jetty.

If we all agree, Is anyone interested in doing this change to jetty and a
full webapp.  I may be able to attempt it but it may be a while before I
make the changes.  Been very busy lately at work.

I have to find something for the jacobie api and a test harness anyway.

Too bad there wasn't a generic sf project that just had jetty and a generic
test webapp that has generic tests.  This may seem like to the extreme, but
it makes more sense like this.  Then jacobie project, jwebunit project could
both use the same testing webapps structure.

Any thoughts!!!

Nick


> -----Original Message-----
> From: James E Weaver [mailto:JEW...@th...]
> Sent: Friday, June 18, 2004 10:17 AM
> To: 'jwe...@li...'
> Subject: [Jwebunit-development] RE: Problem with TestServer in debug
> mode
> 
> 
> Heya,
> 
> Yes, the pseudo-server from httpunit was very good in that it 
> allowed us to
> write good functional tests for jwebunit, but it does have 
> its downsides.
> 
> Keep in mind when you are testing this way - through the API against a
> deployed web application, what you are doing is really more 
> along the lines
> of acceptance / functional tests rather than unit tests.  It may be
> possible to write true unit tests for some of the engine 
> code.  We did not
> make much of an effort at this in jWebUnit.  If I had it to 
> do again, I
> probably would have more true unit tests in jWebUnit (via 
> mock objects,
> shunts, other techniques).
> 
> That doesn't solve the problem though - we still want good 
> functional tests
> regardless of unit-test coverage, and it makes sense with 
> multiple engines
> to want to swap out the engine and run the same suite of 
> functional tests.
> 
> I'm not opposed to trying to transition the api tests to use 
> jetty.  It
> would require some work to get the various fake web pages we 
> declare in the
> tests separated into an app, and to programatically launch 
> jetty with that
> app when the tests are run.  And it would require us to 
> include jetty as a
> dependency for developers on the project.  I don't think 
> that's too much of
> a downside.  On the upside, using a real container for the 
> app may allow us
> to test some things we couldn't test against the httpunit pseuoserver.
> 
> jim
> 
> 
> 
> 
> |---------+------------------------------------------------>
> |         |           Nick Neuberger                       |
> |         |           <Nic...@sn...>            |
> |         |           Sent by:                             |
> |         |           jwe...@li...|
> |         |           ceforge.net                          |
> |         |                                                |
> |         |                                                |
> |         |           06/18/2004 09:44 AM                  |
> |         |                                                |
> |---------+------------------------------------------------>
>   
> >-------------------------------------------------------------
> -----------------------------------------------|
>   |                                                           
>                                                  |
>   |       To:       'Martijn Dashorst' 
> <ma...@da...>, Nick Neuberger 
> <Nic...@sn...>     |
>   |       cc:       
> "'jwe...@li...'" 
> <jwe...@li...>|
>   |       Subject:  RE: [Jwebunit-development] Problem with 
> TestServer in debug mode                           |
>   
> >-------------------------------------------------------------
> -----------------------------------------------|
> 
> 
> 
> 
> Yeah thats what I thought.  A timing issue.  Or a socket issue.  I'm
> getting
> an IOException on the following from HttpUnitDialog.
> 
>                                      resp = wc.getResponse(new
> GetMethodWebRequest(initialURL));
>                          } catch (Exception e) {
>                                      throw new
> RuntimeException(ExceptionUtility.stackTraceToString(e));
> 
> 
> That is a major bummer..  It hard to debug code in a run mode type of
> environment.  Maybe I'll check the httpunit mailing list.  It 
> looks like
> TestServer uses a HttpUserAgentTest (psuedo server) from 
> httpunit.  It may
> be a config or bug in the httpunit class.
> 
> I might just have to use something more robust just for testing.  ie.
> tomcat or something a bit smaller.  donno.
> 
> Nick
> 
> > -----Original Message-----
> > From: Martijn Dashorst [mailto:ma...@da...]
> > Sent: Friday, June 18, 2004 9:16 AM
> > To: Nick Neuberger
> > Cc: 'jwe...@li...'
> > Subject: Re: [Jwebunit-development] Problem with TestServer in debug
> > mode
> >
> >
> > Nick Neuberger wrote:
> >
> > >But, when I stick a breakpoint in any test method of a test
> > case, the test
> > >always fails....  But in run mode, they work fine.  I think
> > it has something
> > >to do with the "TestServer" or its httpunit testing classes.
> >  Any thoughts.
> > >
> > >
> > I had the same problem when I tried assessing why the WebCookieTest
> > didn't work.
> >
> > >Any thoughts on the "TestServer" class.  I need a psuedo 
> type of mini
> > >webserver for serving up pages for the jacobie integration.
> > >
> > >Anyone else have "debug" mode issues running the test cases?
> > >
> > >
> > Yep, I also have these issues. I guess that some timeout on the rmi
> > connection goes off.
> >
> > I am currently in the process of writing an article concerning the
> > integration of jwebunit, jetty and your webproject. On our current
> > project we are able to run the jwebunit tests in the same jvm as the
> > project. This allows for easy debugging. Perhaps this is also
> > a nice way
> > to test jWebUnit itself.
> >
> > Martijn
> >
> 
> 
> - - - - - -
> This e-mail message is intended only for the use of the individual or
> entity
> identified in the alias address of this message and may contain
> confidential
> and privileged information. Any unauthorized review, use, 
> disclosure or
> distribution of this e-mail message is strictly prohibited. 
> If you have
> received this e-mail message in error, please notify the 
> sender immediately
> by reply e-mail and delete this message from your system. Thank you.
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San 
> Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority 
> Code NWMGYKND
> _______________________________________________
> Jwebunit-development mailing list
> Jwe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-development
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San 
> Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority 
> Code NWMGYKND
> _______________________________________________
> Jwebunit-development mailing list
> Jwe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-development
> 


- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

[Jwebunit-development] RE: Problem with TestServer in debug mode

[James E W. <JEW...@th...>]

Heya,

Yes, the pseudo-server from httpunit was very good in that it allowed us to
write good functional tests for jwebunit, but it does have its downsides.

Keep in mind when you are testing this way - through the API against a
deployed web application, what you are doing is really more along the lines
of acceptance / functional tests rather than unit tests.  It may be
possible to write true unit tests for some of the engine code.  We did not
make much of an effort at this in jWebUnit.  If I had it to do again, I
probably would have more true unit tests in jWebUnit (via mock objects,
shunts, other techniques).

That doesn't solve the problem though - we still want good functional tests
regardless of unit-test coverage, and it makes sense with multiple engines
to want to swap out the engine and run the same suite of functional tests.

I'm not opposed to trying to transition the api tests to use jetty.  It
would require some work to get the various fake web pages we declare in the
tests separated into an app, and to programatically launch jetty with that
app when the tests are run.  And it would require us to include jetty as a
dependency for developers on the project.  I don't think that's too much of
a downside.  On the upside, using a real container for the app may allow us
to test some things we couldn't test against the httpunit pseuoserver.

jim




|---------+------------------------------------------------>
|         |           Nick Neuberger                       |
|         |           <Nic...@sn...>            |
|         |           Sent by:                             |
|         |           jwe...@li...|
|         |           ceforge.net                          |
|         |                                                |
|         |                                                |
|         |           06/18/2004 09:44 AM                  |
|         |                                                |
|---------+------------------------------------------------>
  >------------------------------------------------------------------------------------------------------------|
  |                                                                                                            |
  |       To:       'Martijn Dashorst' <ma...@da...>, Nick Neuberger <Nic...@sn...>     |
  |       cc:       "'jwe...@li...'" <jwe...@li...>|
  |       Subject:  RE: [Jwebunit-development] Problem with TestServer in debug mode                           |
  >------------------------------------------------------------------------------------------------------------|




Yeah thats what I thought.  A timing issue.  Or a socket issue.  I'm
getting
an IOException on the following from HttpUnitDialog.

                                     resp = wc.getResponse(new
GetMethodWebRequest(initialURL));
                         } catch (Exception e) {
                                     throw new
RuntimeException(ExceptionUtility.stackTraceToString(e));


That is a major bummer..  It hard to debug code in a run mode type of
environment.  Maybe I'll check the httpunit mailing list.  It looks like
TestServer uses a HttpUserAgentTest (psuedo server) from httpunit.  It may
be a config or bug in the httpunit class.

I might just have to use something more robust just for testing.  ie.
tomcat or something a bit smaller.  donno.

Nick

> -----Original Message-----
> From: Martijn Dashorst [mailto:ma...@da...]
> Sent: Friday, June 18, 2004 9:16 AM
> To: Nick Neuberger
> Cc: 'jwe...@li...'
> Subject: Re: [Jwebunit-development] Problem with TestServer in debug
> mode
>
>
> Nick Neuberger wrote:
>
> >But, when I stick a breakpoint in any test method of a test
> case, the test
> >always fails....  But in run mode, they work fine.  I think
> it has something
> >to do with the "TestServer" or its httpunit testing classes.
>  Any thoughts.
> >
> >
> I had the same problem when I tried assessing why the WebCookieTest
> didn't work.
>
> >Any thoughts on the "TestServer" class.  I need a psuedo type of mini
> >webserver for serving up pages for the jacobie integration.
> >
> >Anyone else have "debug" mode issues running the test cases?
> >
> >
> Yep, I also have these issues. I guess that some timeout on the rmi
> connection goes off.
>
> I am currently in the process of writing an article concerning the
> integration of jwebunit, jetty and your webproject. On our current
> project we are able to run the jwebunit tests in the same jvm as the
> project. This allows for easy debugging. Perhaps this is also
> a nice way
> to test jWebUnit itself.
>
> Martijn
>


- - - - - -
This e-mail message is intended only for the use of the individual or
entity
identified in the alias address of this message and may contain
confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Jwebunit-development mailing list
Jwe...@li...
https://lists.sourceforge.net/lists/listinfo/jwebunit-development

RE: [Jwebunit-development] Problem with TestServer in debug mode

[Nick N. <Nic...@sn...>]

Yeah thats what I thought.  A timing issue.  Or a socket issue.  I'm getting
an IOException on the following from HttpUnitDialog.

			resp = wc.getResponse(new
GetMethodWebRequest(initialURL));
		} catch (Exception e) {
			throw new
RuntimeException(ExceptionUtility.stackTraceToString(e));
 

That is a major bummer..  It hard to debug code in a run mode type of
environment.  Maybe I'll check the httpunit mailing list.  It looks like
TestServer uses a HttpUserAgentTest (psuedo server) from httpunit.  It may
be a config or bug in the httpunit class.

I might just have to use something more robust just for testing.  ie.
tomcat or something a bit smaller.  donno.

Nick

> -----Original Message-----
> From: Martijn Dashorst [mailto:ma...@da...]
> Sent: Friday, June 18, 2004 9:16 AM
> To: Nick Neuberger
> Cc: 'jwe...@li...'
> Subject: Re: [Jwebunit-development] Problem with TestServer in debug
> mode
> 
> 
> Nick Neuberger wrote:
> 
> >But, when I stick a breakpoint in any test method of a test 
> case, the test
> >always fails....  But in run mode, they work fine.  I think 
> it has something
> >to do with the "TestServer" or its httpunit testing classes. 
>  Any thoughts.
> >  
> >
> I had the same problem when I tried assessing why the WebCookieTest 
> didn't work.
> 
> >Any thoughts on the "TestServer" class.  I need a psuedo type of mini
> >webserver for serving up pages for the jacobie integration.
> >
> >Anyone else have "debug" mode issues running the test cases?
> >  
> >
> Yep, I also have these issues. I guess that some timeout on the rmi 
> connection goes off.
> 
> I am currently in the process of writing an article concerning the 
> integration of jwebunit, jetty and your webproject. On our current 
> project we are able to run the jwebunit tests in the same jvm as the 
> project. This allows for easy debugging. Perhaps this is also 
> a nice way 
> to test jWebUnit itself.
> 
> Martijn
> 


- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

Re: [Jwebunit-development] Problem with TestServer in debug mode

[Martijn D. <ma...@da...>]

Nick Neuberger wrote:

>But, when I stick a breakpoint in any test method of a test case, the test
>always fails....  But in run mode, they work fine.  I think it has something
>to do with the "TestServer" or its httpunit testing classes.  Any thoughts.
>  
>
I had the same problem when I tried assessing why the WebCookieTest 
didn't work.

>Any thoughts on the "TestServer" class.  I need a psuedo type of mini
>webserver for serving up pages for the jacobie integration.
>
>Anyone else have "debug" mode issues running the test cases?
>  
>
Yep, I also have these issues. I guess that some timeout on the rmi 
connection goes off.

I am currently in the process of writing an article concerning the 
integration of jwebunit, jetty and your webproject. On our current 
project we are able to run the jwebunit tests in the same jvm as the 
project. This allows for easy debugging. Perhaps this is also a nice way 
to test jWebUnit itself.

Martijn

[Jwebunit-development] Problem with TestServer in debug mode

[Nick N. <Nic...@sn...>]

This for me have been very busy at work so I haven't much time to make a
solid integration yet.  

I've got a connection to the JACOBIE branch but nothing has been committed.
I refactored the code to support an interface and have it working with the
current  jwebunit unittests via the httpunit engine in "run" mode.  

All unit tests pass.....

But, when I stick a breakpoint in any test method of a test case, the test
always fails....  But in run mode, they work fine.  I think it has something
to do with the "TestServer" or its httpunit testing classes.  Any thoughts.

Any thoughts on the "TestServer" class.  I need a psuedo type of mini
webserver for serving up pages for the jacobie integration.

Anyone else have "debug" mode issues running the test cases?

See Ya,

Nick



- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

[Jwebunit-development] [Fwd: [jira] Closed: (MAVENUPLOAD-138) Upload of new version of jwebunit]

[Martijn D. <ma...@da...>]

The new release has been uploaded to ibiblio.org.

This means that from now on you can use the dependency of jwebunit in 
your maven POM's. Make sure you include the dependencies of jWebUnit in 
your POM as well. The XML entries below are the dependencies you need in 
your 'POM' to use the latest jWebUnit release (1.2). Include these in 
your <dependencies></dependencies> part of your maven file to use them.

Martijn Dashorst

        <dependency>
            <groupId>jwebunit</groupId>
            <artifactId>jwebunit</artifactId>
            <version>1.2</version>
            <properties>
                <war.bundle>false</war.bundle>
            </properties>
            <url>http://jwebunit.sourceforge.net</url>
        </dependency>

        <dependency>
            <groupId>nekohtml</groupId>
            <artifactId>nekohtml</artifactId>
            <version>0.8.1</version>
            <properties>
                <war.bundle>false</war.bundle>
            </properties>
            <url>http://www.apache.org/~andyc/neko/doc/html/index.html</url>
        </dependency>

        <dependency>
            <groupId>rhino</groupId>
            <artifactId>js</artifactId>
            <version>1.5R4.1</version>
            <properties>
                <war.bundle>false</war.bundle>
            </properties>
            <url>http://www.mozilla.org/rhino/download.html</url>
        </dependency>
       
        <dependency>
            <groupId>xml-apis</groupId>
            <artifactId>xml-apis</artifactId>
            <version>1.0.b2</version>
            <properties>
                <war.bundle>false</war.bundle>
            </properties>
            <url>http://xml.apache.org/xerces2-j</url>
        </dependency>

        <dependency>
            <groupId>xerces</groupId>
            <artifactId>xercesImpl</artifactId>
            <version>2.6.2</version>
            <properties>
                <war.bundle>false</war.bundle>
            </properties>
            <url>http://xml.apache.org/xerces2-j</url>
        </dependency>

        <dependency>
            <groupId>servletapi</groupId>
            <artifactId>servletapi</artifactId>
            <version>2.3</version>
            <properties>
                <war.bundle>false</war.bundle>
            </properties>
            <url></url>
        </dependency>

        <dependency>
            <groupId>httpunit</groupId>
            <artifactId>httpunit</artifactId>
            <version>1.5.4</version>
            <properties>
                <war.bundle>false</war.bundle>
            </properties>
            <url>http://httpunit.sourceforge.net</url>
        </dependency>

RE: [Jwebunit-development] Re: Release is a success?

[Nick N. <Nic...@sn...>]

> From: James E Weaver [mailto:JEW...@th...]

> It's really nice to have some help.  Wilkes and I were both pretty 
> played out on
> jWebUnit - it definitely needed you.

I couldn't agree more.  An open-source project can consume everything you
have if there are only
a couple of active contributors.  I'm glad we are contributing together.  It
makes everything easier
for the entire project.

> This should dovetail with the work Nick is doing.  He is 
> heading us towards
> support for an alternate engine to httpUnit behind the 
> jWebUnit API, and
> the fit plugin is an alternate means to interact with the 
> jWebUnit API.
> Swappable front-ends, back-ends, the API for interaction and 
> assertions in
> common.

Looks like a solid approach.  Can't wait to see everything take shape in the
next few months.  I have been extremely busy at work and haven't had much
time to fine tune any testing stuff here... More to come probably next week.

See Ya,

Nick


- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

[Jwebunit-development] Re: Release is a success?

[James E W. <JEW...@th...>]

Hi,

I would say so, and thanks very much for making it happen.  Thanks to all
the contributors as well; they had to wait a pretty long time ;-).  It's
really nice to have some help.  Wilkes and I were both pretty played out on
jWebUnit - it definitely needed you.

Some progress should be made on the fit plugin over the next two to three
weeks - I plan to use it on a project, so have a billable excuse for doing
the work ;-).  I'm leaning towards releasing the fit plugin as a separate
package on the jWebUnit site, once it's in good shape and I've gotten some
help with the legal issues (Ward's fit is GPL, jWebUnit is BSD).

This should dovetail with the work Nick is doing.  He is heading us towards
support for an alternate engine to httpUnit behind the jWebUnit API, and
the fit plugin is an alternate means to interact with the jWebUnit API.
Swappable front-ends, back-ends, the API for interaction and assertions in
common.

And of course there are yet more patches, bug reports, and feature requests
in the queue for us to sort through....

Thanks again,

Jim W.

[Jwebunit-development] Release is a success?

[Martijn D. <mar...@to...>]

It looks like the release was long overdue, considering the number of
downloads since its availability: 185 on june 14. 3000+ pageviews!
=20
The release can be considered a success, IMO.
=20
Thank you all for the support and help in cranking out this release!
=20
Martijn

Re: [Jwebunit-development] Problems using setFormelement

[Laurent D. <ldu...@ya...>]

Laurent Duperval wrote:

> com.meterware.httpunit.FormParameter$UnusedParameterValueException: 
> Attempted to assign to parameter 'EntriesPerPage' the extraneous value 
> '2'.

ARGH! My brain kicked in again right after I received this. Turns out my 
form doesn't allow me setting a value of 2, but my servlet accepts it. 
So I have to call the servlet directly instead of passing by the HTML pages.

L

[Jwebunit-development] Problems using setFormelement

[Laurent D. <ldu...@ya...>]

Hi,

I have a test that does something like this:

public void testFoo() {
gotoPage("foo");
setFormElement(FOO_ELEM, "fooValue");
 .
 .
 .
<here I do all sorts of stuff>
 .
 .
 .
gotoPage("foo");
setFormElement(FOO_ELEM, "barValue");
}

The second setFormElement gives me this error:

com.meterware.httpunit.FormParameter$UnusedParameterValueException: 
Attempted to assign to parameter 'EntriesPerPage' the extraneous value '2'.
    at com.meterware.httpunit.FormParameter.setValues(FormParameter.java:92)
    at com.meterware.httpunit.WebForm.setParameter(WebForm.java:533)
    at com.meterware.httpunit.WebForm.setParameter(WebForm.java:526)
    at 
net.sourceforge.jwebunit.HttpUnitDialog.setFormParameter(HttpUnitDialog.java:299)
    at net.sourceforge.jwebunit.WebTester.setFormElement(WebTester.java:789)
    at 
net.sourceforge.jwebunit.WebTestCase.setFormElement(WebTestCase.java:317)

I suspect that the second setFormElement creates a multi-valued 
attibute, but my form only accepts onve value for the attribute. Am I 
correct in my assessment? If so, how do I fix this? If not, what is the 
problem with my code?

L

RE: [Jwebunit-development] Contribution

[Nick N. <Nic...@sn...>]

What is the bug?

Can you include a link to which bug ticket on sf.net?

the memory issue problem.

> -----Original Message-----
> From: Laurent Duperval [mailto:ldu...@ya...]
> Sent: Monday, June 14, 2004 9:56 PM
> To: bm...@ya...
> Cc: jwe...@li...
> Subject: Re: [Jwebunit-development] Contribution
> 
> 
> BB wrote:
> 
> >Hi,
> >
> >Ive found bug in JWebUnit. How do I contribute the fix
> >back to JWebUnit?
> >
> >Best Regards,
> >
> >
> >  
> >
> 
> Enter it at http://www.sf.net/projects/jwebunit. THere is a page for 
> bugs there.
> 
> L
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
> Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
> Conference, June 28 - July 1 at the Moscone Center in San 
> Francisco, CA
> REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority 
> Code NWMGYKND
> _______________________________________________
> Jwebunit-development mailing list
> Jwe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-development
> 


- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

Re: [Jwebunit-development] Contribution

[Laurent D. <ldu...@ya...>]

BB wrote:

>Hi,
>
>Ive found bug in JWebUnit. How do I contribute the fix
>back to JWebUnit?
>
>Best Regards,
>
>
>  
>

Enter it at http://www.sf.net/projects/jwebunit. THere is a page for 
bugs there.

L

[Jwebunit-development] Contribution

[BB <bm...@ya...>]

Hi,

Ive found bug in JWebUnit. How do I contribute the fix
back to JWebUnit?

Best Regards,


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 

[Jwebunit-development] Off topic: using Maven

[Martijn D. <ma...@da...>]

Nick Neuberger wrote:

>I'm very familiar with ANT but not Maven.  Are there goods and bads to using
>Maven?
>  
>
Read this article:
http://www.theserverside.com/articles/article.tss?l=MavenMagic
It is a very good read.

The dependency resolving is very comfortable. All dependencies are 
resolved automatically. Site generation is also magnificent. Junit 
reports (normally rather painful to generate in the right directory for 
your ant project site) are just 1 line away. Adding clover support or 
jcoverage is also 1 line.

For business projects, it is nice to see which developers are part of 
the development team. With statcvs one can see the major contributors 
(nice for evaluations ;-). Using the changes.xml file, the changes 
plugin and the announcement plugin, it is very easy to generate an 
announcements.txt (posted on the theserverside.com) and it is integrated 
with the site.

The bads are: it is slower, sometimes too slow. It depends on the type 
of site you generate. If you enable all reports, you can get a decent 
cup of coffee. But if you're only interested in the test reports, then 
it is not much slower than using ant.
It is also not very stable. Since it depends on many plugins, some of 
which aren't of production quality. However most plugins just re-use ant 
tasks and just work.

>It seems like its very much the same.  We may try and start using maven here
>at work as well.  Although, we have about 20 projects to build and we are
>using cruisecontrol to build our code..
>  
>
Integration of maven with cruisecontrol is not more difficult than 
integrating ant. Or so I'm told. I should just start with the most 
simple project you have and mavenize it. Integrate it with cc. 
*EVALUATE* and come to the conclusion that it works ;-) Then go to 
project number 2.

With regards,

Martijn

Re: [Jwebunit-development] cvsignore file

[Martijn D. <ma...@da...>]

Nick Neuberger wrote:

>I was wondering why .classpath and .project are in the cvsignore file.
>  
>
As did I. Probably it has some historical reason.

>Is there a specific reason for this?
>  
>
I guess it has to do with different installations of clients. If we all 
agree on using maven as the primary build tool, then we could add 
.classpath and .project to the CVS repository. Then everyone could 
create a classpath variable in Eclipse named MAVEN_REPO which would 
point to the local maven repository. All library dependencies would be 
resolved against that variable. I.E. 
MAVEN_REPO/httpunit/jars/httpunit-1.5.4.jar and so on.

It is not even necessary for everyone to use maven as their build system 
(would be comfortable though), as long as everyone declares the 
MAVEN_REPO variable (when they use Eclipse) and mimic the repository 
structure of maven.

My 2cts.

Martijn

Re: [Jwebunit-development] =?ISO-8859-1?Q?paper=B4s?=

[Martijn D. <ma...@da...>]

proxy-teste wrote:

>hello..
>
>there=B4s some article for reference of the jwebunit? =20
> =20
> =20
>
What information are you looking for?

Can't you find it in:
 o http://jwebunit.sourceforge.net/quickstart.html or the
 o=20
http://jwebunit.sourceforge.net/apidocs/net/sourceforge/jwebunit/WebTeste=
r.html=20
javadoc?

Hope to help,

Martijn Dashorst

[Jwebunit-development] =?iso-8859-1?b?cGFwZXK0cw==?=

[proxy-teste <pro...@bo...>]

hello..

there=B4s some article for reference of the jwebunit?  
  =0D
=
please, I await.  
  
Thank you
=0A =0A_______________________________=
___________________________________________=0AAcabe com aquelas janelinha=
s que pulam na sua tela.=0AAntiPop-up UOL - =C9 gr=E1tis!=0Ahttp://antipo=
pup.uol.com.br/=0A

[Jwebunit-development] cvsignore file

[Nick N. <Nic...@sn...>]

I was wondering why .classpath and .project are in the cvsignore file.

Is there a specific reason for this?

I was hoping these files would be in the repository.  Its not too necessary.

I'm using eclipse and it took me a little bit just to find out that eclipse
checks that .project file for the "tags".  Thus, I didn't see the new
branches..

This isn't major, I already workaround the issue.  I just added to the
"branch list" inside eclipse, then checkout project as -> project wizard.
Then manually built the project settings to get everything built properly.

Any thoughts?

See Ya,

Nick


- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

RE: [Jwebunit-development] Release 1.2 ready for announcement

[Nick N. <Nic...@sn...>]

> Martijn wrote:
> Thanks, I enjoyed doing it. At work we use maven as the default build 
> tool, so it wasn't *that* hard.
> 

I'm very familiar with ANT but not Maven.  Are there goods and bads to using
Maven?

It seems like its very much the same.  We may try and start using maven here
at work as well.  Although, we have about 20 projects to build and we are
using cruisecontrol to build our code..

Any thoughts...

Nick Neuberger


- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

[Jwebunit-development] Publicity: the serverside.com has picked up our release!

[Martijn D. <ma...@da...>]

OK, I admit: I helped a little :-)

See:
http://www.theserverside.com/news/thread.tss?thread_id=26574

Martijn

Re: [Jwebunit-development] Release 1.2 ready for announcement

[Martijn D. <ma...@da...>]

Nick Neuberger wrote:

>Great Job...
>
>the site looks very good, very consistent....  Excellent job on the change
>to Maven.  Much needed.
>  
>
Thanks, I enjoyed doing it. At work we use maven as the default build 
tool, so it wasn't *that* hard.

>BTW - What is the branch name that I can use for the jacobie refactoring
>work.
>  
>
JACOBIE

RE: [Jwebunit-development] Release 1.2 ready for announcement

[Nick N. <Nic...@sn...>]

Great Job...

the site looks very good, very consistent....  Excellent job on the change
to Maven.  Much needed.

I have not used maven but have been very impressed with the output from
maven-based sites..

BTW - What is the branch name that I can use for the jacobie refactoring
work.

Nick

> -----Original Message-----
> From: Martijn Dashorst [mailto:ma...@da...]
> Sent: Sunday, June 13, 2004 5:56 PM
> To: 'jwe...@li...'
> Subject: [Jwebunit-development] Release 1.2 ready for announcement
> 
> 
> Gentlemen,
> 
> I've uploaded the jwebunit-1.2.zip file to sourceforge and it 
> is in the 
> release filesystem. I've also tagged, and branched the 
> current state of 
> CVS (as Vivek has described in his CVS best practices).
> 
> Tag in main branch: RELEASE_1_2
> Release 1.2 branch: release_1_2, first tag to work of: 
> Root_release_1_2
> 
> Bug fixes for jwebunit 1.2 that are desperately needed and can't wait 
> until 1.3 should go into that branch.
> 
> I'll also created a branch for Nick to work on: JACOBIE. All jacobie 
> integration should go into that branch.
> 
> Next I'll announce the release.
> 
> Martijn Dashorst
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by the new InstallShield X.
> From Windows to Linux, servers to mobile, InstallShield X is the
> one installation-authoring solution that does it all. Learn more and
> evaluate today! http://www.installshield.com/Dev2Dev/0504
> _______________________________________________
> Jwebunit-development mailing list
> Jwe...@li...
> https://lists.sourceforge.net/lists/listinfo/jwebunit-development
> 


- - - - - - 
This e-mail message is intended only for the use of the individual or entity
identified in the alias address of this message and may contain confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution of this e-mail message is strictly prohibited. If you have
received this e-mail message in error, please notify the sender immediately
by reply e-mail and delete this message from your system. Thank you.

Re: [Jwebunit-development] Status report release 1.2

[Martijn D. <ma...@da...>]

Status report on the release 1.2

- we release 1.2, and distribute it also to the maven repository
Release 1.2 is released, announcement has been sent.
maintainers of ibiblio repository have been apprized of our new version, 
the bundle for upload to ibiblio had been created and submitted to JIRA. 
See also:
    http://maven.apache.org/repository-upload.html

Now just wait until the jar has been uploaded.

Martijn

[Jwebunit-development] JWebUnit 1.2 is released

[Martijn D. <ma...@da...>]

The jwebunit team is pleased to announce the jWebUnit 1.2 release!

http://jwebunit.sourceforge.net

jWebUnit is a Java framework that facilitates creation of acceptance 
tests for
web applications. It evolved from a project where we were using HttpUnit 
and
JUnit to create acceptance tests. As the tests were being written, they 
were
continuously refactored to remove duplication and other bad smells in 
the test
code. jWebUnit is the result of these refactorings.

Changes in this version include:

  New Features:

o assertTextNotInElement method addition
o assertFormNotPresent method addition
o goto a page directly by url Issue: 724337. Thanks to Alex Chaffee.
o support for clicking links by text when there are multiple links with 
same
  text on page Thanks to justin sampson.
o support for multiple checkboxes with different values Issue: 627735.
o Moved the build system from Ant to Maven.
o Added support for cookies. Issue: 715841. Thanks to Vivek Venugopalan.

  Fixed bugs:

o Wrong text in Assert Issue: 856218. Thanks to Roberto Cosenza.
o quickstart.html setBaseUrl is mistyped Issue: 908440. Thanks to Vasile
  Alaiba.
o assertFormElementPresent fails when a form is in an IFRAME Issue: 910242.
  Thanks to Hien Nguyen.
o assertLinkPresentWithImage("foo") fails if foo isn't first Issue: 908372.
o broken link in jwebunit-1.1.1 set of files Issue: 918278. Thanks to Jim
  Cloughley.
o prevent js files from being returned as response content
o Fork enabled for ant-build compile. Issue: 727614. Thanks to Brad Clarke.
o Form submit overload for forms with multiple submit buttons. Issue: 
745868.
  Thanks to Charles Blaxland.

  Changes:

o form assertion failure messages more accurate
o Upgraded all dependencies (httpunit, rhino, nekohtml, xerces, junit) to
  their newest released version. 

Have fun!
-The jwebunit team