Hi Siegfried,
some last notes on guitest target, not to try to convince you, but to see
what to do:
- first, the tests are actually running: guitests target depends on jar,
which in turn executes the tests target, before the tests are ran within
the junit.swingui.TestRunner. You should have the test report corresponding
to the first test execution at $SVN/tests/reports/junit-noframes.html,
noting that 964 tests out of 964 ran OK.
- Strangely, junit.swingui.TestRunner runs only 962 tests, 17 of them
failing. There are some other weird issues with this runner:
+ lots of messages (a couple of thousands) on stdout like:
[java] log4j:ERROR [junit.runner.TestCaseClassLoader@776be68f]
whereas object of type
[java] log4j:ERROR A "org.apache.log4j.RollingFileAppender" object
is not assignable to a "org.apache.log4j.Appender" variable.
+ stacktraces regarding hsqldb startup (several dozens):
[java] [Server@5087c7a8]: [Thread[HSQLDB Server
@5087c7a8,5,main]]: run()/openServerSocket():
[java] java.net.SocketException: Unrecognized Windows Sockets
error: 0: JVM_Bind
+ the tests target takes almost 5 minutes on my PC, whereas the guitests
takes half the time
+ the tests failing are all related to setup methods, failing because
either this code:
Context initCtx = new InitialContext();
throws an unexpected exception (no InitialContext available) or this
one:
Properties props = new Properties();
props.put( PageSorter.PROP_PAGE_NAME_COMPARATOR,
HumanComparator.class.getPackage().getName() + ".HumanComparator" );
throws a NPE on the second line
+ Most importantly: all the(se) tests run fine through normal tests
target / Eclipse
- Wrapping up this issue, to me it seems an issue of
junit.swingui.TestRunner, which btw, is not present in JUnit 4.x (all
modern IDEs support JUnit execution from quite a while, so it seems like it
didn't make sense to continue mantaining this runner). So, I'd rather
delete guitests target from build.xml, as all the test are passing and the
test failing issues seem to be related to the runner, WDYT?
- Regarding the RAT report: would it be fine if we add those 17 exceptions
to the report, so it gets 0 issues, provided that we appropiatly put them
down in the comment of the Ant target?
br,
Juan Pablo
On Sat, Nov 10, 2012 at 12:20 AM, Siegfried Goeschl <sgoes...@gmx.at> wrote:
> Hi Craig,
>
> worx for me ... ;-)
>
> Cheers,
>
> Siegfried Goeschl
>
>
> On 09.11.12 23:15, Craig L Russell wrote:
>
>> Hi Siegfried,
>>
>> Thanks for taking a look at the release. You have given a good reason for
>> your -1. Reasonable people may disagree; I would not call this issue a
>> blocker. In fact, there's no requirement that a release actually work (!)
>> but that it is legally proper and downstream users might find it useful.
>> That's why a -1 will not block a release, assuming more +1 than -1.
>>
>> We have several +1 and your -1 so far. If we don't get any more votes, we
>> will forward the vote to the IPMC for their approval.
>>
>> Regards,
>>
>> Craig
>>
>>
>> On Nov 9, 2012, at 2:09 PM, Siegfried Goeschl wrote:
>>
>> Hi Florian and Harry,
>>>
>>> thanks for responding even in the middle of the night ...
>>>
>>> ad 1) my bad - I indeed used an old wiki page set - shame on me
>>>
>>> ad 2) "The guitests target is not part of the build sequence for good
>>> reasons" - I know but how you find any new GUI bugs if the guitests are
>>> considered broken and not executed? Maybe the next time we get 18 errors
>>> instead of 17 but when the tests are ignored that one bug could cause
>>> frustration within the JSPWiki user community when it escapes into the real
>>> world - I had my five minutes of fame when a late change caused a NPE in my
>>> commons-exec release - I think I got more than 20 mails with "btw, there is
>>> a stupid NPE in this method". IMHO it is acceptable to state that 17 tests
>>> are indeed broken but those 17 tests should be commented out to get overall
>>> guitests working - for the remaining 17 tests we can create a JIRA and hope
>>> for better times.
>>>
>>> ad 3) I completely agree with your disagreement and I dislike the RAT
>>> report as well ... :-) ... but two thoughts on that : on the one hand there
>>> are already exceptions defined in the RAT report generation on the other
>>> hand some guys are pretty stubborn regarding RAT report violation - they
>>> have somehow the tendency to skip interpreting the RAT report and complain
>>> about it which could cause a RC to fail. I had too many rejected RC with
>>> Apache Commons ...
>>>
>>> Conclusion - 1) was my mistake, I have a major issue with 2) and minor
>>> issue with 3)
>>>
>>> Still on -1
>>>
>>> Hope you understand me reasoning
>>>
>>> Siegfried Goeschl
>>>
>>> On 09.11.12 21:54, Florian Holeczek wrote:
>>>
>>>> Hi Siegfried,
>>>>
>>>> first, thanks for having had a thorough look at the stuff!
>>>>
>>>> 1) [Major] when I deploy the exploded WAR to my local Tomcat the "Find
>>>>> Pages" in the left hand navigation does not work - it shows an
>>>>> non-existing Wiki page instead of opening a search page - I tried with
>>>>> the
>>>>> LuceneSearchProvider and the BasicSearchProvider but it does not work. I
>>>>> did not see any error message in jspwiki.log but the fulltext search DOES
>>>>> work when using the "Quick Navigation"
>>>>>
>>>>
>>>> you're probably using an old wiki page set, so this is expected
>>>> behaviour. Please see https://issues.apache.org/**
>>>> jira/browse/JSPWIKI-664<https://issues.apache.org/jira/browse/JSPWIKI-664>
>>>>
>>>> 2) [Major] when running "ant guitests" 17 out of my 962 test fail.
>>>>> Could be some missing configuration I'm not aware of but I would expect
>>>>> all
>>>>> tests to pass ... ;-)
>>>>>
>>>>
>>>> The guitests target is not part of the build sequence for good reasons
>>>> :-)
>>>>
>>>> 3) [Minor] The RAT report could appreciate a few more exceptions to
>>>>> get rid of the "17 Unknown Licenses"
>>>>>
>>>>
>>>> I completely disagree in this point - The RAT report is nothing one
>>>> will want to tell "Great, all fine!", in order to print it out and decorate
>>>> some wall. Instead, it's only a helper tool that is meant to generate a
>>>> good, unfiltered overview of reality. It's then up to the reader to
>>>> interpret its contents.
>>>> Putting exceptions into it means that you lose control over the ignored
>>>> files and risk to oversee relevant issues in later modifications of these
>>>> files.
>>>>
>>>> Can anyone double-check? Currently (see 1+2) my vote is
>>>>>
>>>>> [ ] +1 Approve the release
>>>>> [X] -1 Disapprove the release (please provide specific comments)
>>>>>
>>>>
>>>> The only issue IMO is no. 2 - but it's a minor issue that should not be
>>>> blocking a release. WDYT?
>>>>
>>>> Regards
>>>> Florian
>>>>
>>>
>>>
>> Craig L Russell
>> Architect, Oracle
>> http://db.apache.org/jdo
>> 408 276-5638 mailto:Craig.Russell@oracle.**com <craig.russ...@oracle.com>
>> P.S. A good JDO? O, Gasp!
>>
>>
>
