I posted a write-up here. I wrote it because the Maven tools I played with, when integrated with PDE, didn’t “just work.” Basically, I wanted to do coding in PDE and have a Hudson-based CI without any fuss in between.

Generating Ant files is nice because it gives you all the benefits of a declarative build tool, but it leaves you with a procedural description of what it is doing.

I am looking for more PDE-based projects to test it on. There are a couple RFC-0112 Bundle repositories around, and I have some code for downloading dependencies. If anyone is interested, then I could integrate dependencies download with auto-builder.

James Percent
james@empty-set.net

In VMware’s case, there are few to no project managers in the company (at least in R&D). It tends to be yet another hat for engineering managers to wear when they have a spare minute, so a responsibility like curating the wiki is treated as extremely low priority (read: it never gets done).

The idea behind the librarian was to establish at least one person for multiple teams to rely on for helping them organize and keep their information up to date. I agree that it could be overkill for many organizations where others are able to dedicate adequate time to the task.

As this article in the book was focused on PM things, the wiki idea was to provide a more shared responsibility to update relevant content, rather than requiring the PM to collect and distribute any/all information.

As a PM, I have taken responsibility on my projects for managing wiki organization so that it’s useful. So the PM is the curator… the team members are the contributors. It requires some work on the PM’s part – particularly in the early going, as wiki organization can morph drastically with the initial content. Once it’s organized though, and understood, folks get the hang of where to put particular content.

It’s like moving into a new house and organizing your garage. If you don’t provide some structure of where things go at the beginning, then you’re out of luck. But the effort at the beginning to establish order can make for a garage that requires only cursory maintenance over time. (Put up a peg-board !)

I don’t think it requires a librarian. Certainly, if you have significant documentation requirements that require a tech-writer, this sort of thing is right up their alley and can potentially be tacked on.

Thanks for the thought-provoking post.

@Xqnstyl: We don’t use a repository manager. The original (local) repository came from one developer’s machine and as new artifacts are needed, we have a couple of simple scripts that will fetch the artifact, its POM, the source if available and then add it to Perforce.

One key note is that we do not use Maven for performing a release. VMware has its own build and release process (which just happens to call `mvn package` at a particular step). We also haven’t adopted the process of revving individual modules in the project and having people depend on them. The versions are currently all in lockstep and you always depend on the current version (sadly).

So typically when work is done (even in a branch), it’s the code and the contents of the POM that change, not the version associated with it.

As for the Maven SCM support for Perforce, we don’t use it. All devs have the p4 client as well as P4WSAD on their systems to edit and submit changesets. Because we don’t use Maven to do releases, we haven’t had a need to try the plugin. From my cursory reading of the page you linked to, I don’t see another case that would be relevant to us.

ks