Loading Profile...
EMPLOYEE
What do you want us to write next?
What do you want us to write next? We're wondering if, you, the reader, have any input into what you are looking for when it comes to Maven documentation. Are you looking for a more task-centric book like a Cookbook? Or, are you looking for longer tutorials? Please let me know, we're also interested in known what specific areas of Maven documentation you think could use more attention.
I’m confident
Follow this discussion to get notifications on your dashboard.
-
Inappropriate?I would be nice to see a chapter on why someone should use Maven. The reason I hear of people who are afraid to use Maven are that ANT is suffiient and does the job just the same. I have to say that those people are right, it just requires a lot of scripting in ANT.
The learning curve for Maven is also steep, if you are not a 100% familiar with it you should not use it.
I’m thankful
2 Comments
Add a comment
-
I'm not going to say anything bad about Ant; in fact, many complex Maven builds include Ant scripts in some way. The Maven project that builds this book uses Ant for post processing steps after it renders the Docbook with XSL. Ant is capable and established.
Thank being said, I do think I can make some better arguments for using Maven and when Maven might be preferred over a more procedural approach. The one thing I wanted to shy away from was an argumentative tone "Maven is better than X, Y, or Z." My editor told me that we do have to do a little bit of this.... people expect it, but I'm also not convinced that we need to be building barriers between communities.
I go back and forth with Steve Loughran very often, and we have strong disagreements about build systems. He wrote the Ant book for Manning. The last thing I'm interested in is adding to the vitriol that characterizes programming disputes. It is counter-productive.
Adding a task now to add some more reasoned "arguments" for Maven usage. -
In my opinion it's all about the complexity of your builds. Where I work, we have a ludicrous number of builds, many of which share sub modules with other builds. Managing our dependencies, both internal and third party, would be a nightmare without Maven.
So, I think what you say is true for simple projects with minimal complexity and dependencies, but beyond that, Maven is a clear win. Take a look at some of the open source projects using it and I think you'll see what I mean. -
Inappropriate?a chapter about maven release plugin usage:
moving from snapshot to release, making sure that your cvs/svn repository is consistent with your maven repository, and not breaking builds by re-deploying released artifacts is key to maven usage in the enterprise world.2 Comments Add a comment
-
I second this. In all my projects, this is something we haven't really settled on. The result has been that we use Maven to build like it used to be done with Ant. That is, the resulting artifact(s) are not deployed to a repository but manually copied from the target folder to some mapped network disk. IMO, not the way it is meant to be...
-
me too! :-)
-
Inappropriate?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
I’m thankful
1 Comment Add a comment
-
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? -
Inappropriate?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....
I’m confused
-
Inappropriate?It'd de nice to have a chapter about NMaven. Even though it is a plugin still in the incubating status it adds a whole new facette to Maven by making it possible to build .net projects.
I’m confident
1 Comment Add a comment
-
Ok, we're definitely planning to add some content about NMaven. I've put this into the queue, but I'm not sure what our timeframe is going to be for implementing this. I'd anticipate NMaven content in Q4.
-
Inappropriate?In an enterprise setting, one of the biggest issues is how to best leverage Maven for deployment to production. In my opinion it is unfortunate that Maven uses the term 'deploy' to mean copying artifacts to a shared Maven repository. Once the artifacts are 'deployed' to a shared repository, a great deal of work and process still remain in order to distribute (deploy if you will) the software to say hundreds of sites (at least in my case).
Questions that come with respect to deploying into production include:
When should we stop using Maven and resort to other means to distribute software?
Should Maven have a direct role to in full-blown integration test environments? Or should Maven be left behind before entering this environment?
How can we best leverage Maven for production software deployment/distribution?
Would it make sense to have distributed Maven repositories in many production sites and launch applications in production using artifacts from these repositories? Or should we wait for Tycho so that we can use Maven and OSGi together to accomplish this?
How can Maven best be leveraged when rolling out a software update to many production sites?
That's just a start at questions related to production software distribution/deployment. This is certainly a more advanced topic than learning the basics of how to use Maven for builds. However if Maven is to live up to its full potential it kind of makes sense to have a very good story about how we get from artifacts in a shared Maven repository to software running in many production sites.1 Comment Add a comment
-
Pat, these are real problems in commercial/enterprise use of Maven, and we have plans to address these types of things via Nexus and/or other products. A best practices chapter is also a good thing to add in the book.
-
Inappropriate?How about a Maven Cookbook? Something analogous to the Rails Cookbook. Instead of a tutorial with reference material, it would be a list of self-contained "recipes" for solving specific problems with Maven. -
Inappropriate?Hi I would like a chapter talking about some cool plugins for example maven reactor, I think is an unvaluable tool when we need to deal with really complex multi-module projects, I would also like to see the use of maven release and maven scm, best practices for using them
The book is looking execellent
Cheers
Gabriel
