Since Friday, a spammer tries to spam me via pingbacks 😦
It’s nice that WordPress lets me move this comment to spam, it’s not so nice that the spam keeps coming back.
But I’m sure they’ll fix that soon 🙂
Since Friday, a spammer tries to spam me via pingbacks 😦
It’s nice that WordPress lets me move this comment to spam, it’s not so nice that the spam keeps coming back.
But I’m sure they’ll fix that soon 🙂
Documentation usually has these three attributes: It’s incomplete, outdated and plain wrong.
That doesn’t apply to every bit of information in your documentation but it you can be sure the statement above is correct for the whole documentation.
As a consumer of such documents, it’s a nice puzzler to determine into which of the three categories a bit of information belongs.
This leads to the common “we hate documentation” stance that all software developers soon adopt, no matter if they have to write/maintain the documentation or if they have to use it.
As we all know, the only reliable source of documentation are unit tests. But they can still be incomplete (= missing the example you need) or outdated (= missing examples for the latest API).
The solution? Generate documentation from the source code. And I don’t mean “from javadoc in the source code”, I mean literally from the code. If a method is used in a certain way in 317 places in your code and once in a different way, then you have two examples. One of them probably works, the other is probably documents a bug which your tests missed.
Eclipse is starting to get support for this. The first step was code completion. Now we have a couple of guys working on Eclipse Code Recommenders.
This summer, Stefan Henß starts to work on an “extended documentation platform” for Eclipse.
I’ve recreated the testing repository using the latest version of my Maven Tools 4 Eclipse.
To browse the repository, please use the Nexus interface.
If you pull in any dependencies from the repository, non-Eclipse artifacts will come from from Project Orbit. If you want non-Eclipse dependencies (like log4j) from Maven Central, you need to change your profiles.
Deactivate “m4e.orbit” and activate “m4e.maven-central“. From the command line, that’s “-P m4e.maven-central” but I suggest to put these into your settings.xml (add “<activeProfile>m4e.maven-central</activeProfile>” to it).
Note that you don’t need to deactivate the profile m4e.orbit. As soon as you specify a profile on the command line or via the settings, it’s deactivated automatically.
“mvn help:active-profiles” and “mvn dependency:tree” are your friends.
Let me know if you find anything missing, odd, broken by filing a bug or posting a comment here.
Some dependencies from the new repo can also be found on Maven Central. One nasty problem is that both repos contain org.eclipse.equinox.app but the version from Maven Central contains odd dependencies which break your build.
To fix this, add this to your parent/root POM:
<dependencyManagement> <dependencies> <dependency> <groupId>org.eclipse.dash</groupId> <artifactId>dependency-management</artifactId> <version>3.6.2</version> <type>pom</type> <scope>import</scope> </dependency> <dependencies> <dependencyManagement>
This will limit all version ranges to the versions found in our new repository. Since Maven Central didn’t import new versions for at least one year, this should fix all problems.
Related posts: