Re 1, getting rid of external dependencies is great.
Re 2, using a xUnit style seems like a very good idea. The code should
be minimal.
Re 8, I believe the comment refers to old code that we don't have any
more (it ended up in the yubico-c project).
I have added you to the yubico-j project. Feel free to make these
changes. Ping the list and I'll review and revert anything that I don't
like. :)
Thanks,
Simon
PS. The google code svn server seems broken sometimes, so if you get a
'Bad Gateway' error just retry later.
http://code.google.com/p/yubico-j/source/browse/trunk/COPYING
Are you ok with this license?
Thanks,
/Simon
/Simon
[javac] /home/jas/src/yubico-j/src/com/yubico/base/test/ModhexTest.java:4: static import declarations are not supported in -source 1.4
[javac] (try -source 1.5 to enable static import declarations)
[javac] import static com.yubico.base.test.UnitUtil.assertEqual;
[javac] ^
[javac] 1 error
Is there a simple fix to this other than to bump the java requirement to
1.5? I'm not sure if bumping the java requirement will be a problem,
but if it can be avoided easily that is always good.
One alternative may be to bump it to 1.5 only for the test directory.
Thanks,
Simon
> Sorry!
>
> I was thinking, should keep this <1.5, no reason to go higher with this....
> Habit. Will fix!
Works fine now, thanks!
I have linked the JavaDoc manual from the project front page too. They
look very nice. How do you generate these files?
I've incremented the version from 1.0 to 1.1. Maybe we should do
another release when you are finished with your changes. No need to
delay it, release early release often and all that...
Btw, 'ant test' fails but maybe you are working on this?
[junit] Running com.yubico.base.test.ModhexTest
[junit] Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0.005 sec
[junit] Test com.yubico.base.test.ModhexTest FAILED
[junit] Running com.yubico.base.test.PofTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.327 sec
/Simon
/Simon
I'm not a strong java programmer, so I don't know what the Best Practice
within the java community is with regards to ant vs eclipse, junit vs
other frameworks.
/Simon
Putting the self-tests in src/ will enlarge the core library *.JAR, so I
would be in favor of putting all self tests under test/ and building
them to a separate JAR. And if we separate the files, I don't think it
matters if we use a external unit framework because it will only enlarge
the *-test JAR, not the core JAR.
Arne, what do you think? Is moving your tests from src/ to test/ and
rewriting them to use the junit framework ok with you?
> We are on extremely same page when it comes to
> '' favor of reducing external dependencies". I do not understand why nobody
> has
> made a xUnit framework purely using reflection (at least that I know of).
Maybe junit 4 supports it? Anyway, it seems junit is rather popular.
> Eclipse I am told by my coworker is a good Ant friend, I used to do a lot of
> Ant
> hacking in the old days so I can look into this... But soon going to meet
> some
> friends at the pub seeing Sverige win so doubt get much done tonight ;-(
You must have seen a different match than I did... :-(
/Simon
> Going up from 1.0, 1.1 might be ok now...
Yup, if we can sort out the self test stuff, I think we should release
1.1.
> The next I was thinking of was get function that is more user friendly
> towards validator programmers.
> But perhaps should be discussed in terms of what plans one has with
> this library..?..
The idea is that this library should be small and only contain core
functions -- it can then be used like larger packages like the
'yubico-server-j' project that implements a complete server.
However, if it is possible to write a validator function that abstracts
away some of the details in verifying an OTP that may fit into this
library. I'm not sure it is possible to write this in a abstract and
flexible enough way though. But a patch would prove me wrong. Please
don't commit any validation stuff without discussion first, though.
/Simon
Btw, what are your thoughts on log4j? Right now log4j is only used by
the old self-tests, which seems rather pointless to me -- if there are
problems with the self-tests, a developer needs to look at the code
anyway.
I think we should remove all traces of log4j in this project.
> I do not like any of the logging framework. In our company we have made our
> own
> logging code, one for client side and one for server side and are happy with
> that.
> That a side, logging is important special in servers. In open source code I
> would probably
> go along and use log4j if situation dictated. But I do not think the type of
> methods this
> library has should do logging or dictate logging framework. Mine thinking...
I've removed all log4j stuff from yubico-j now. Servers can and
probably chose to use a logging framework, but that is beyond the scope
of the yubico-j project.
Thanks,
/Simon
/Simon