Re: Re: Implementation certification procedure

Julian Mehnle ha scritto:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Stefano Bagnara wrote:
>> gnu.gcj.runtime ??? I guess you are using gcj and not a JAVA(tm)
>> virtual machine. Please use a compliant virtual machine (I usually use
>> openjdk or any sun implementation, but bea, ibm, harmony jvms should
>> work too).
> 
> http://packages.debian.org/lenny/sun-java6-jre
> ^^^ This looks like the Java(TM) virtual machine to me, right?
> 
> It seems that for the JDK (!= JRE) I had erroneously installed the 
> default-jdk (=> java-gcj-compat-dev) package rather than the 
> sun-java6-jdk one.

Sure sorry. I forgot you are not a java guy. To compile packages you 
need a JDK and not a JRE.
However to run jSPF you only need the JRE.
Testing the library without building will only require the JRE (we don't 
have bytecode-compiled distribution for our tester yet).

> After correcting that, the build succeeded.  Unfortunately, the test 
> output is still LOTS of raw stuff that I cannot ever hope to comprehend.  
> But at least it looked legitimate. :-)

The DEBUG output is verbose. It is useful to have it verbose to have any 
chance to understand non-repeatable bugs and you run the build in a 
continuous integration environment.

In java there are a number of Junit runners and they will produce fancy 
and cleaner output.

I'm not going to alter our build for this. IMHO there is no real need 
for this. Instead I prefer to waste my time working on the live tester 
so that I can see the same output for any implementation.

>>> I appreciate your helping me getting jSPF to build, though.
>> This is the same for jSPF: you should only need a proper java virtual
>> machine (1.4+) installed.
> 
> Not exactly.
> 
> I recommend that you include a note in your BUILDING.txt file that one may 
> have to use `mvn package` instead of `mvn -Plocal`, and also have it say 
> that tests will be run automatically when doing a build.

Ok, but this is not about compliance. Users use the compiled version. 
This is not perl, java bytecode works on any platform without the need 
to be compiled. Users of our library won't compile it.

I'll add an hint, anyway.

> I also encountered two other show stoppers (one see above, the other being 
> that some part of Maven seems to parse the output of `env` incorrectly 
> when the environment contains shell functions -- WTF?), but they are not 
> specific to jSPF so there's nothing you can do about them.

I want to point out that it should not require you to be able to build a 
library in order to declare it compliant. A library could even be closed 
source while still pass any test.

> Finally, it would be good to get the testing output in a more readable and 
> much less cluttered format, or at least include a way to filter out the 
> noise.

"noise" is something depending on the information you are looking for.

You can use the "mvn package site" command. It will create a full 
website for the jSPF tool and this will include the surfire test report 
in the target/site/surefire-report.html file.

I don't expect a perl developer and a java developer to agree on best 
practices ;-)

>> I am happy you decided to try this. Let me know if you have any more
>> issue and I'll help.
> 
> Please tell me what troubles with testing Mail::SPF you were referring to:

I don't remember, it's 1.5 years ago. I admit I had not too much 
interest in this so I stopped at the first issues, but I was not 
successful in compiling/installing/running it in our Solaris box because 
I had a different perl installed and I was not able to change that and 
on my windows box (but there I have perl installation issues more often 
than not).

>>>>>> The same difficulties I find with Mail::SPF testsuites and pyspf
>>>>>> testsuites..
> 
> Perhaps I can improve something there.

If I'll try again in the near future to build on the 2 problematic boxes 
I'll report a better issue.

Thank you,
Stefano