>> While trying to improve the build process I came across the JUnit test
>> cases which setup I do not understand at all.
> That code definitely needs commenting, sorry for the confusion!
> Basically, what's happening is that prior to running the unit tests a
> "test" JAMWiki instance is installed in the "target" folder with all
> test topics loaded into it. That way when the unit tests run there will
> be an HSQL instance with topics available, and a valid properties file
> with appropriate test settings.
This is what I have assumed but in my opinion there is a better way of
doint that. Instead of doing that @Before setup() over and over again,
which you obviously do. You could create a test suite, wich prepares
this environment once and then tell the test suite to run all tests will
need this test setup. See here  for JavaDoc reference.
>> First of all, why is a clean always autoperformed? What is the need for?
>> It imposes a severe performance penality on the builds.
>> I disabled that and all tests started to fail.
> The "clean" is done because the "test" install sets itself up in the
> Maven "target" folder, so each unit test run wipes out any old instance
> and sets up a new one. If there is a better way to do that then I'd be
> in favor of making a change, although it's worth noting that the "test"
> setup itself is useful for unit testing purposes since it exercises the
> default JAMWiki setup paths.
This is not necessary, Maven always copies (test-)resources over to
(test-classes), you are guaranteed to have a fresh copy. You tests
should be always idempotent.
>> I started digging and found JAMWikiUnitTest#setup.
>> Why the heck do you manually copy the resources? This is Maven's task.
>> Doesn't matter what I started to change in the setup method, test still
> This is partially a legacy thing - "src/test/resources/data/files"
> contains expected output for several parser unit tests, and in the past
> these were copied so that lookups could find the result files. That may
> not be needed any longer and could probably benefit from some
Yes, probably. See comment above.
>> Every package run costs 4 minutes, this makes really hard to improve the
>> POM interatively.
> If it helps, for now feel free to disable unit tests by default and I
> can try to help out with speeding this up. I agree that the build is
> really slow - as the number of unit tests has grown things have gotten
> progressively worse, but since it wasn't causing serious issues for
> anyone it wasn't an issue I was looking into. It sounds like it may now
> be time to try to speed things up :)
Actually, I don't mind to have a big set of tests cases but the wipe of
target everytime. The JFlex generation consumes a lot of time on my
machine. The tests are virtually cheap. Anyway, I think the test
structure could be reworked to be more efficient.
>> 1. ParserTest#parseResult: There is no need to retrieve the file at all.
>> A input stream should suffice.
> Sounds good to me.
Will do. Added to to do list.
>> 2. TestFileUtil#retrieveFileContent: Why do you do that manually? There
>> is Commons IO! Plus, you did not specify the file encoding which might
>> cause errors in the test run.
> This is probably a legacy issue, or just an oversight from the initial
> implementation. Feel free to swap this for the Commons IO version, or I
> can do so next time I sit down to write code.
Will do. Added to to do list.
> Thanks for the detailed analysis, and let me know what I can do to make
> this easier to work with.
There'll be more spots in the project structure I'll discuss overtime.