Dooing's dashboard

me too! :-) – Dooing, on August 16, 2008 07:34

I just saw you updated to Maven book 1.13 beta (btw the website still says 1.12) -
There's also a best practice section now. Great, thanks. It helped a bit, but it's way to short. Hm, I don't want to keep nagging the whole time, but I guess this thing here is all about nagging - or with other words - to make the best maven book even better! :-)

What I am still missing in the best practice section, for example, is how will each of these layouts work in daily business? I mean, for example, with dependency management I fear that developers, especially new ones, will tend to forget to update the dependency management section, so other projects will still work with older versions of the project submodules. Updating the dependency management for third party dependencies is easy - it's the only place you have to update the version - but with sub projects, you have to update the version of the subproject, the version of the parent pom AND THIRD the version in dependency management. Then you have to deploy the new parent pom, and finally deploy the new sub project pom. 5 steps for just changing something in a sub project. hmmm. Maybe it was better to use SNAPSHOTS between a weekly release cyclus? You see, it's still not entirely clear....

Nexus is great, but what I am missing is an "added security layer" - and I am not talking about the website and so on - I mean, when deploying a file to nexus that has already deployed, it would be nice if nexus would reply:
This artifact has already been deployen on 12/12/07 12:10:45 by Dooing. Do you really want to overwrite this file?!

(The name and date could be retrieved from the jars manifest file for example...)

P.s.: Also version ranges and transitive dependencies should be explained in more detail - in the current version there is about 1/2 - 1 page about each of these topics.
What I am missing, with version ranges: Why should I use them, what's the purpose / benefit?!
Transitive dependencies / conflict resolution: dependency:tree, dependency:analyze, effective-pom, best practice (when moving from ant or maven 1). When I had a project before that had about 10 dependencies and it was working as desired, now with maven 2 with transitive dependencies it might have 2o dependencies in the jar. Should I leave them, or exclude them? – Dooing, on July 08, 2008 05:52

Generally speaking, your book gets better and better, yet still it's more
focused on Maven 2 Beginners, I guess - you write for example about the site plugin, but most times, when I got a concrete question,
your book stops to go into more details...

For example:

- scm plugin in detail
-how to filter a single property only
-reports in detail
-javascript compression (in detail)
-tomcat plugin, jetty plugin, deployment in general and in detail
-assembler plugin in detail
- site plugin in detail
- release plugin in detail (why should I use it, what does it do...)
- some words about the help plugin
- the "one" plugin would probably be good too (even though using them is damn easy, but I guess pointing it out wouldn't hurt).
- Maven best practices - e.g. inheritance vs. composition - see
http://www.nabble.com/Proper-Dependen...
- Archetypes in detail
- Why are plugin version set to a concrete version in the super pom? Wouldn't it be better to always get the newest plugin versions?
- profiles in detail
- when to add a plugin into the regular plugin section, and when to add it to the plugin management. Brian wrote something about it in his blog, which I, however, did not completly understand (and he still didn't reply to my post! :-( )
http://blogs.sonatype.com/brian/2008/...

In general, I could say, for everything you explain in your book, I miss the next 1-5 pages, I mean the ones still to be written, after what's already included, that go in more detail, explain more complicated stuff,
make it more "real" - many examples you give in your book smell so "hello world" - you get it? ;-)

Cheers,

Marcus