-
1. Re: Request: htmlunit from sourceforge in thirdpary.
ryan.campbell Apr 12, 2006 3:35 PM (in response to walkerrl49)
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossBuild
See sections at bottom on repository structure and thirdparty maintenance. -
2. Re: Request: htmlunit from sourceforge in thirdpary.
chilin Jul 17, 2006 6:12 PM (in response to walkerrl49)Hi,
I'm taking over the task(s) Bob described at the beginning of this post.
I've identified that we need to add the following 4 new jars to the repository:
. commons-io.jar
. htmlunit.jar
. js.jar
. nekohtml.jar
And we also need to upgrade commons-collections.jar and commons-httpclient.jar from version 2.1 & 2.0.2 to version 3.1 & 3.0 respectively.
3.1 commons-collections.jar and 3.0.1 commons-httpclient.jar already exist in the repository, so I modified build/build-thirdparty.xml to include them. However, this caused compile errors in multiple testsuite modules.
Being new to this, I'd like to find out what is the standard procedure of handling this. Should I attempt to fix the testsuite to cope with the new version (not sure about the magnitude)? Or is it ok to include multiple versions of a jar file in the thirdparty directory (so only the admin-console's htmlunt test uses the new version, everything else remains the same)?
Any other suggestions?
Chi -
3. Re: Request: htmlunit from sourceforge in thirdpary.
starksm64 Jul 18, 2006 12:38 AM (in response to walkerrl49)Its not ok to include multiple versions of a library in the main build. If a component needs another incompatible version is needs to be pulled out the build and integrated as a binary component with its conflicting version isolated via class loader scoping.
If the error is due to changes in the commons httpclient, what are the changes causing problems? Updating the testsuite would make it incompatible with the 4.0 branch code. -
4. Re: Request: htmlunit from sourceforge in thirdpary.
chilin Jul 18, 2006 7:33 PM (in response to walkerrl49)The new HttpMethod.getResponseBody() now throws an IOException which needs to be caught or declared.
Taking your advice, we'll be maintaining the two incompatible jars under the project directory and load them from there. Since we're doing this, we'll probably also store the four new jars at the same location rather than add them into the the repository.