Jonathan Costers (JIRA) wrote:
[ https://issues.apache.org/jira/browse/RIVER-301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689745#action_12689745 ]
Jonathan Costers commented on RIVER-301:
----------------------------------------
Excellent! Glad it works.
Running some of the categories takes a while, others take ages to complete ..
No wonder Sun created a full blown distributed test harness for running these
tests :-) This alone could be a separate Apache project :-D
I'm running the 'discoverymanager' category right now, I know this one takes
hours on my machine.
I'm pretty sure there are some loose ends here and there, since porting the
GNUMake files was a huge manual and repetitive task. But, I've been running
lots of categories and only few errors occur. I'm trying to fix them as they
come along.
I've checked most of the JAR files off to a build of river/qatests/trunk using
make, and they seem to contain the same class files and resources.. But I'll
most likely have missed some things.
I believe this can contribute to some new dynamic on this project. I see people
are introducing a ClassDep alternative with acceptable licensing .. well these
Ant files sure are a nice test for it :-) They have a zillion ClassDep
instantiations in there!
Best
Jonathan
Thanks for the tip, nice work ;)
Cheers,
Peter.
Move the tests into the JUnit framework inside the main source project
----------------------------------------------------------------------
Key: RIVER-301
URL: https://issues.apache.org/jira/browse/RIVER-301
Project: River
Issue Type: Task
Components: other
Affects Versions: AR3
Reporter: Tom Hobbs
Attachments: integrationtest.xml, RIVER-301.patch, RIVER-301.patch,
River-301.patch.zip, River-build-qa5.patch
Original Estimate: 672h
Remaining Estimate: 672h
The tests donated by SUN live in their own source project and are runnable in a
format that is unfriendly towards IDEs and new developers to the River project.
This is the proposal to move the test code, mostly unmodified, into the main
source directory whilst shoe-horning it into JUnit 3. This will allow it to be
easily viewable and runnable. Such a structure will also reduce the
code-compile-test cycle since no JARs will have to be created in the middle of
the cycle and no long command-line incantations.
