Hi,
during the trip back from Amsterdam I spent some time reviewing the current
Stanbol code base, and fixing some issues.
Here are some remarks:
1. Stanbol doesn't build, it complains that
eu.iksproject:eu.iksproject.kres.shared.dependency.owlapi:jar:0.6-SNAPSHOT is
missing.
This is a major issue since it prevents building the whole stack, and putting
it under continuous integration.
2. Lots of files (almost 600) have tabs instead of (or mixed with) spaces. This
is bad behavior, because, depending on how your editor is set-up (tabs can be
2, 4 or 8 spaces long, depending on people choices), some people will get ugly
looking code.
I have a massive patch that expands all the tabs to 8 spaces. Will apply it
soon, unless there is some protests.
3. More generally we need to use a common formatting standard. The only way to
do so efficiently is to start with common formatter settings for Eclipse, and
apply it massively to the code base.
4. I have seen code duplicated from external projects:
- Base64.java: I know that it's not part of the Java standard Library, but
there is an Apache library for this, let's do this instead of forking their
code.
- DOMUtils.java: this has been forked from Sun Microsystems code, and as a
license that looks like a BSD license, except for this provision "You
acknowledge that Software is not designed, licensed or intended for use in the
design, construction, operation or maintenance of any nuclear facility." This
makes it non open source, and this file has to be removed. (Olivier tells me
that Xstreams is a better alternative anyway).
- There are lots (~20) files that have been copied from geonames (I believe).
I'm not really happy about this, specially since
a. It's not obvious which files have been modified and which ones have been
kept as-is.
b. When file as been modified, it's not obvious where.
5. I have removed, and will keep removing, all the unneeded getter and setters
javadoc comments ("getFoo(): get the foo", "setFoo(Foo foo): set the foo, foo:
the Foo to set..."). This is unneeded cruft added by the IDEs, and, if not
reviewed and completed manually to better explain what a Foo is and how to set
it properly, it's better to remove the javadoc comment).
6. I think our classes deserve better javadoc comments that just "MyClass.java"
or no comment at all.
7. I have, in FISE, changed most of the constants references from, say,
"Properties.DC_RELATION" to only "DC_RELATION", using static imports. This
makes the code easier to read, and with any IDE it is still possible to get the
definition of the constant by hovering over the constant where it's used.
8. Remember that interfaces are not the right place to define constants. And
it's usually better to use enums for integer constants (see Bloch's Effective
Java, 2nd ed., chapters 19 and 30).
That's it for today. We have also to change all the "eu.iksproject" to
"org.apache.stanbol" and to put the right license headers. I think it would
also be useful if everyone would sign their code in the header or in the
Javadoc.
S.
--
Stefane Fermigier, Founder and Chairman, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com/ - +33 1 40 33 79 87 - http://twitter.com/sfermigier
Join the Nuxeo Group on LinkedIn: http://linkedin.com/groups?gid=43314
New Nuxeo release: http://nuxeo.com/dm54
"There's no such thing as can't. You always have a choice."
