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

Sorry to bother you…

I have set Java Preferences to ‘Open in 32 Bit Mode’; however, I still have the same problem.

When I used Maven with Perforce in the past, we had to take great care when merging pom.xml files between branches. How do you handle merging pom.xml files between branches where you want the version to stay different, especially after performing a Maven release?

I see Perforce has a KB article on Maven integration: http://kb.perforce.com/?article=1023. What’s your take on it?

Cheers!