Provide extra instructions in failure message

testGetPluginCSS depends on gendoc.css existing in the classpath,
but currently this file is only created by the copy-css Ant target.
If this test is run in a clean checkout before any command line builds
(e.g. when a developer checks out an initial copy of the source tree
and tries to run all the tests in their IDE, which is how I discovered
this issue) then it will always fail.  The fix is simply to run a
command line build before trying to run this test another way.

Most users will never see this message, but those who do are likely
doing what I did, so add a note to the assertion failure message
suggesting they try running a command line build before running this
test again.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Tell users to create env var when test fails

testBuild_DelEnvVar depends on an environment variable named TESTENV being set
but it doesn't matter what this value is set to.  When this test fails because
that environment variable is not set the failure is obvious when looking at the
code (assertNotNull(env.getVariable(TEST_ENVVAR))) but it is not immediately
obvious what this variable should be set to.  In .ant-scripts/build-test.xml
it appears the actual value is not important, so it can be set to anything.

In order to prevent others from having to hunt this information down in the
future we can provide a more descriptive error message informing users that
it is perfectly safe to simply set it to a dummy value.  Most users will never
see this message because the Ant build scripts automatically set this up before
running the tests, so specifically call it out for developers trying to run
this test in their IDE.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Add reminder to revisit gendoc.css issue later

gendoc.css is currently created by the Ant build.  Its contents are simply the
concatenation of cruisecontrol.css and configxml-gendoc.css.  However, the
purpose of this file is not immediately obvious because the gendoc'ed
configxml.html file still links directly to cruisecontrol.css and
configxml-gendoc.css in its header (see: configxml_html.vm).

I suspect the reason for creating gendoc.css is so that its contents can be
exposed via JMX (see CruiseControlControllerJMXAdaptor#getPluginCSS), however
the purpose of exposing the contents via JMX is not immediately obvious to me,
either.  I think this should be revisited in the future, and if there's still
a need to expose the contents via JMX then I would like to discuss alternative
solutions such as manually merging the two files together, checking that file
into version control, and updating the configxml.html template to directly
refer to that file.  I don't think it's wise to depend on the presence of a
file like gendoc.css which is nested in our source tree (it is copied to
main/src/net/sourceforge/cruisecontrol/gendoc/html/) but not actually checked
into version control, and I don't think it's wise for any tests or production
functionality to depend on this file being present on the classpath.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Clear static state between tests

BuildLoopMonitorRepository caches a BuildLoopMonitor in static state which may
be shared between all of the tests in DashboardControllerTest.  The cached
BuildLoopMonitor can be purged by calling cancelPosting on the repository.

Unfortunately, testShouldBeAbleToStartPostingIfThereIsNOExistingPosting is
dependent on not having any BuildLoopMonitor cached at the beginning of the
test.  Instead of merely forcing the BuildLoopMonitorRepository to purge its
cache at the beginning of that test, let's do that in setUp() so that every
test starts with a clean repository.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Better info message

Combine adjacent string literals.  Add missing space to make message more
readable.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Locate and set local Subversion working copy

The svn info tests fail on systems with newer Subversion clients.  It appears
svn info no longer automatically searches parent directories for a valid local
working copy, so when run out of the directory where our Ant build runs the
tests there were build failures.

The simplest work-around is to always walk the directory hierarchy ourselves
and explicitly set the local working copy path when we find the first .svn
entry.  This initial implementation isn't terribly robust, for example it
doesn't even check that the .svn entry is a directory let alone a valid
Subversion directory, but it is good enough as a first step.

This issue also exposes the fact that our svn tests are somehow dependent,
or at least affected by, the fact that CruiseControl itself uses Subversion.
This diff doesn't address that problem, either, although that is something I
believe we should investigate further and improve.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Add latest version of XPP3

XPP3 is an XML pull parser.  It is a dependency of XStream.  Add the latest
release in preparation for a forthcoming upgrade of XStream.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Add latest version of XStream

We currently have XStream v1.2.2 in our tree, but that version fails to
correctly recognize JDK 7.  This results in several test failures due to
missing default constructors when building with JDK 7 (see:
http://jira.codehaus.org/browse/XSTR-651).

This commit merely adds the latest XStream release to the tree.  It is
not yet hooked up to the builds; that will happen next.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Add missing dependency on XPP

XStream requires XPP, but I missed this dependency when I first broke out
build-paths.xml for the reporting dashboard.  That omission didn't break
anything because a version of xpp3 was included in reporting/dashboard/lib
and automatically copied into the .war file.  I only noticed when I tried
to remove that older version in preparation for upgrading to the latest
release.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Copy XPP and XStream into binary release zip

Make sure we explicitly copy both jars into the binary release zip because
they live in the shared lib/ directory.  This temporarily means there will
be duplicate copies in both the source tree as well as cruisecontrol.jar and
dashboard.war.  I plan on fixing that soon, but in the meantime this is
necessary for upgrading XStream to work with JDK 7.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Hook latest XPP and XStream to the build

Actually upgrade our dependency to now point at the latest versions of both
XPP and XStream.  Remove old versions of both jar files.

This is necessary to build with JDK 7.  We don't actually use any new Java 7
features or APIs, but due to Oracle's acquisition of Sun Microsystems some
internal strings changed which caused old versions of XStream to incorrectly
use the wrong reflection engine (see: http://jira.codehaus.org/browse/XSTR-651)
which caused a number of test failures.

I verified that we still build successfully with JDK 5 and JDK 6 using the
latest versions of these libraries.

Also, be note that just because we are compatible with JDK 7 does not mean it
is ok to introduce any dependencies on Java 7.  It is expected that we remain
fully source and API compatible with Java 5.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Preparation for sharing IntelliJ configuration

Add .idea/ directory in prepartion for committing a working IntelliJ
configuration skeleton.  Committing this separately to make it easier
to control which config files are added and which are ignored, etc.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>
Initial IntelliJ IDEA configuration

Generated with IntelliJ IDEA 13; might not be compatible with earlier versions.
We already have Eclipse .classpath and .project in the tree, and since IntelliJ
now offers a free Community Edition I think it makes sense to also add IntelliJ
configuration in the tree.  Hopefully, this will make it easier for others to
setup a CruiseControl development environment and contribute to the project, as
well as make it easier for existing developers to migrate to new machines.  :)

Currently, there are only modules for .ant-scripts/, main/ and main/loggers/.
I'm still working through the library dependencies necessary for the reporting
app and dashboard.  Also, I haven't tried running the functional tests in main/
from within IntelliJ yet, so there might be some more tweaks necessary there.

Signed-off-by: Kent R. Spillner <kspillner@acm.org>