Jason, The test failures in the security module are documented here - http://issues.apache.org/jira/browse/GERONIMO-1672 The Connector15DCBTest failures is new. These tests used to pass in the old trunk. There is no MailCapTest in rev. 418907. The PluginInstallerTest is a new test added in 1.1 and needs help.
Thanks Anita --- Jason Dillon <[EMAIL PROTECTED]> wrote: > I've reconfigured all modules to us the latest surefire plugin, and > most tests work... except for a few exceptions: > > system/**/PluginInstallerTest.java > security/**/LoginKerberosTest.java > connector-builder/**/Connector15DCBTest.java > mail/**/MailcapTest.java > > Each of these fail in someway that was not obvious to me why, so I > configured these specific tests to be excluded. I've removed all of > > the maven.test.skip=true bits from poms and recommend that they never > > be re-added. IMO, the tests must always pass and they should be > quick enough to run and thus not force people to disable them to run > > builds. > > All of this work is in this branch: > > https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/ > m2migration/ > > I've given up on submitting patches for the moment, but I plan on > creating an RTC issue when there is significant change to be applied > > back to trunk... and will provide a patch for clarity, but recommend > > that folks use this branch to test/validate on top of scanning the > patch. > > I would appreciate some help in resoling why the above listed tests > are failing. > > One major thing that has changed, is that the working directory for > tests has been changed from ${basedir} to ${basedir}/target, so there > > were several changes needed to bind files to the correct path. IMO > this is a best practice, regardless of what the working directory > is.... tests should always use ${basedir} to root themselves and > ensure that the tests will work even when the working directory > changes. > > I do not believe that the failed tests listed above fail because of > this change, but it is possible that they are for reasons I do not > understand. > > * * * > > A side note, we should create a module that contains support classes > > for unit (and integration) tests to allow some of the redundant code > > to be collected, organized and maintained in a central location. I > believe we will want to implement this soon after the m2 migration is > > complete and update all tests to extend from that framework to > simplify the code required to perform highly reliable testing. > > Logging configuration is still a bit whack for tests... some tests > spit out a bunch of junk while others just complain with Log4j > configuration warnings. I will be resolving this shortly with the > implementation of the logging-config plugin extension, which will > allow all modules to share the same config.. BUT before this will > work we need to setup a peer project for all of the independent build > > plugins. > > More mail to come on that soon. I plan on setting up a project in > the sandbox, proving and example for how it works using this sandbox/ > > svkmerge/m2migration branch and then detailing/documenting it to the > > list once it is functional. > > If you have any questions or comments please let me know. > > And... again, can I get someone to look at why the tests listed above > > fail? > > Thanks, > > --jason > > PS. sandbox/svkmerge/m2migration also has the latest assembly plugin > > changes from GERONIMO-1737 which I am also evaluating. > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
