Re: Refactoring the Maven Build
Hi Jesse (and everyone), you are more than welcome to not go so easy on me. I am a hands-on process improvement guy with many years of experience as a build engineer and release manager. I am also the Editor in Chief at CM Crossroads (www.cmcrossroads.com) where I write about topics related to configuration management including build engineering. I have worked with Ant, Make/GNU Make and MS Build along with Maven 1.0.2 and Maven 2. I have been struggling to get my arms around Maven for some time now and wanted to make a concerted effort to get past my learning curve because it has become increasingly clear that Maven is the build tool of choice for Java applications. In my work, I have been asked several times to review existing Maven builds that had the problems that I described in the article. I did not create these problems. They were created by software developers who were, as you say, a higher caliber maven user than I am today. I appreciate your comments which I am reviewing and I am glad to refactor my article on Refactoring the Maven build, but I suspect that I am not the only person struggling to get up to speed with maven. Perhaps I am a little more daring because I am willing to publicly start the conversation. I would also suggest that Maven is tough for many people to master and it could be argued that we, as a community, could do a better job explaining the concepts and spreading the knowledge. I would like to be part of that effort. So I will challenge you Jesse (and others) to share what you know (as you obviously do on this list) and also to help mentor the rest of us along. I will do my best to come up to speed as well and I can probably add some value by helping others along with their learning curve too. What other resources are there available for newbies to learn how to use Maven? I know of the PDF that we can all download and books published by O'Reilly and Packt. I have written a number of articles on Maven and will write lots more (which you are absolutely welcome to critique). http://www.cmcrossroads.com/cm-basics/13111-the-maven-super-pom http://www.cmcrossroads.com/cm-basics/13070-getting-started-with-maven http://www.cmcrossroads.com/cm-basics/11656-a-little-more-maven-102 http://www.cmcrossroads.com/cm-basics/10379-maven-102-the-walk-down-memory-lane-you-may-very-well-need Feel free to send me your articles and I will get them published (that includes articles from other beginners who climbing the stairs with me). I will always be delighted incorporate feedback and suggestions as I try to be the best that I can be. regards, Bob http://www.linkedin.com/in/BobAiello __ On 3/8/2010 9:39 AM, Jesse Farinacci wrote: Hi Bob, On Mon, Mar 8, 2010 at 8:09 AM, Bob Aiellobob.aie...@verizon.net wrote: I just wrote an article on tactics for refactoring the Maven build and I would love to get your input. http://www.cmcrossroads.com/cm-basics/13317-refactoring-the-maven-build Feel free to post comments or send them to me privately. Bob Aiello Editor in Chief CM Crossroads http://www.linkedin.com/in/BobAiello raiello [at] acm.org Well, you seem to be a manager and not a technical developer, so I'll go easy on you. Your article is definitely filled with the right buzz words, they just don't seem to be used appropriately. The title, Refactoring the Maven Build, suggests that there will be some sort of detail provided on how to refactor the Maven pom.xml, but there aren't any details on this at all. Tip # 1 - Using help:effective-pom to diagnose problems is good Tip # 2 - Understanding what is going on in the build is generically useful Tip # 3 - Adding tracing to Maven itself isn't going to be useful to any reader unless you provide your changes, please do not Tip # 4 - Declaring dependencies in a clear and consistent way? What does this even mean? Being a correct, well-formed XML document will see to that.. Tip # 5 - There's so much wrong in this one I don't know where to start ... please just delete it Tip # 6 - This is the likely result of your misunderstanding Maven, and switching the packaging type from jar to war without ever cleaning out the .m2/repo and/or without changing the artifact's version - tsk-tsk on you! Tip # 7 - Anyone that has written a plugin for Maven, even a HelloWorldMojo, is going to be of a higher caliber Maven user than you.. telling them to 'optimize' their plugins isn't at all valuable or useful Tip # 8 - Here, you seem to have digressed from the original thesis; are you speaking about a Maven Repository Manager? It's unclear, and worse still, you provide no details about what you're trying to fix, or how you recommend fixing it Tip # 9 - This is a non-issue if you are using well defined best practices for software development - by this I mean using actual versions and tagging your source code version control system appropriately
Re: Refactoring the Maven Build
As good and as pervasive as Maven is, if you review build tools then you may want to take a look at Ivy too. I plan to. Yes, Maven is hard to learn. The web site doesn't quite seem to be organized either for learning *or* for reference. The only book I could find when I went looking for one, _Maven: the Definitive Guide_, would have to be three times as thick if it were really definitive. Everything the new user reads praises convention over configuration and then doesn't tell you the conventions. Maven embodies some very definite ideas about how software should be built. If you try going some other way, Maven will smack your hand over and over until you winkle out what it wants you to do. Maven wants to be in control of things. It downloads what it wants, when it wants to, without asking. It puts things where it wants to, without telling you where they went. You must accept this. It is a thing that goes down hard for many developers. Maven is not readily discoverable. The way to get basic help from it is a complex formula that stretches all the way across the screen. The usual ways of asking a tool how it works will yield either reminders of things the newbie wasn't ready to learn, or a screenful of seeming gibberish. All that said, once you have scaled the learning wall (I'm maybe 40% up) Maven will do a good job for you so long as you use it the way it expects to be used. I haven't given up on it. (Oh, no! I've suffered enough that I won't rest until Maven cringes before my stern gaze, whimpering, what is thy will, O my master? as a good tool should.) -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Friends don't let friends publish revisable-form documents. pgpvnosedEGcZ.pgp Description: PGP signature
Re: Refactoring the Maven Build
I agree with your comments about the documentation. It needs some outside review to get the organization more oriented to the new person. The definitive guide is missing some of the things that you need to actually build something functional. I suggested some rewording and table changes and provided an example to the web page on transitive dependencies (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies) to make it more readable by someone who does not know how it works but they were never incorporated. The proliferation of plug-ins is also confusing. If you have a million supported conventions does that really help? There probably should be a Best Practices document that describes the most productive ways to use Maven to do software development. It would likely be highly contentious for those who have developed some odd ways to do things. For most of us, we would just adapt if the Best Practices promised that Maven would be our faithful servant if we followed them. It would tell you how to structure your IDE project, how to manage your own libraries, how to deal with dependencies, etc. for different normal applications. It would give you examples of great parent poms, poms to build libraries and poms to build and deploy different types of applications (web, portal, web services, standalone applications) using your libraries and 3rd party libraries. There are probably 10-15 Best Practices that would satisfy 98% of software developers. The other 2% could read the Maven docs and explore the plug-ins. Ron Mark H. Wood wrote: As good and as pervasive as Maven is, if you review build tools then you may want to take a look at Ivy too. I plan to. Yes, Maven is hard to learn. The web site doesn't quite seem to be organized either for learning *or* for reference. The only book I could find when I went looking for one, _Maven: the Definitive Guide_, would have to be three times as thick if it were really definitive. Everything the new user reads praises convention over configuration and then doesn't tell you the conventions. Maven embodies some very definite ideas about how software should be built. If you try going some other way, Maven will smack your hand over and over until you winkle out what it wants you to do. Maven wants to be in control of things. It downloads what it wants, when it wants to, without asking. It puts things where it wants to, without telling you where they went. You must accept this. It is a thing that goes down hard for many developers. Maven is not readily discoverable. The way to get basic help from it is a complex formula that stretches all the way across the screen. The usual ways of asking a tool how it works will yield either reminders of things the newbie wasn't ready to learn, or a screenful of seeming gibberish. All that said, once you have scaled the learning wall (I'm maybe 40% up) Maven will do a good job for you so long as you use it the way it expects to be used. I haven't given up on it. (Oh, no! I've suffered enough that I won't rest until Maven cringes before my stern gaze, whimpering, what is thy will, O my master? as a good tool should.) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Refactoring the Maven Build
On Tue, Mar 9, 2010 at 11:29 AM, Ron Wheeler rwhee...@artifact-software.com wrote: I suggested some rewording and table changes and provided an example to the web page on transitive dependencies (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies) to make it more readable by someone who does not know how it works but they were never incorporated. Link? Is there a JIRA issue with a patch? -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Refactoring the Maven Build
Wendy Smoak wrote: On Tue, Mar 9, 2010 at 11:29 AM, Ron Wheeler rwhee...@artifact-software.com wrote: I suggested some rewording and table changes and provided an example to the web page on transitive dependencies (http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies) to make it more readable by someone who does not know how it works but they were never incorporated. Link? Is there a JIRA issue with a patch? This was my posting with the suggestions. It was at the end of a long discussion where Anders gently but firmly hammered the concept of transitive dependencies into my thick skull. I finally got it and now my staff regrets the day I found this. We are refactoring all of our builds to use Maven differently (and, I hope, better)! I am sure that my wording could be improved and the example more detailed. There was no positive response to my suggestion so I did not press the issue with a JIRA entry. Ron Once you know the answer, the matrix is accurate but it is too convoluted to be read by someone who does not know the answer already. Each of the scopes (except for import) affects transitive dependencies in different ways, as is demonstrated in the table below. If a dependency is set to the scope in the left column, transitive dependencies of that dependency with the scope across the top row will result in a dependency in the main project with the scope listed at the intersection. If no scope is listed, it means the dependency will be omitted. might be written as follows: Each of the scopes affects transitive dependencies in different ways. The table below describes the rules. If a dependency in the higher level pom is set to the scope in the left column and the transitive dependencies of the lower level pom are set to the scopes named at the top of other column, this will result in a dependency with the derived scope listed in the cell at the intersection. If no scope is listed, it means the dependency will be omitted. For example, if the project pom declares a dependency on a group pom with a scope of provided and the group pom includes a jar with scope compile, the resulting scope for that jar will be provided. Of course, import scope does not participate in transitive dependencies. If it is possible to colour the table or apply fonts so that header columns and rows are more clearly marked, that would also help. Thanks for all the help. My test project compiles and produces a 27K war file instead of a 21Mb war. Once I get the other 20+ projects fixed up and tested, I will have a much quicker portal startup and some relief from the Java equivalent of dll-hell. It also should make starting a new project much easier since the dependencies are now grouped much more sensibly. I just hope it runs after it is deployed. Ron - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Refactoring the Maven Build
Hi everyone, I just wrote an article on tactics for refactoring the Maven build and I would love to get your input. http://www.cmcrossroads.com/cm-basics/13317-refactoring-the-maven-build Feel free to post comments or send them to me privately. Bob Aiello Editor in Chief CM Crossroads http://www.linkedin.com/in/BobAiello raiello [at] acm.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Refactoring the Maven Build
Hi Bob, On Mon, Mar 8, 2010 at 8:09 AM, Bob Aiello bob.aie...@verizon.net wrote: I just wrote an article on tactics for refactoring the Maven build and I would love to get your input. http://www.cmcrossroads.com/cm-basics/13317-refactoring-the-maven-build Feel free to post comments or send them to me privately. Bob Aiello Editor in Chief CM Crossroads http://www.linkedin.com/in/BobAiello raiello [at] acm.org Well, you seem to be a manager and not a technical developer, so I'll go easy on you. Your article is definitely filled with the right buzz words, they just don't seem to be used appropriately. The title, Refactoring the Maven Build, suggests that there will be some sort of detail provided on how to refactor the Maven pom.xml, but there aren't any details on this at all. Tip # 1 - Using help:effective-pom to diagnose problems is good Tip # 2 - Understanding what is going on in the build is generically useful Tip # 3 - Adding tracing to Maven itself isn't going to be useful to any reader unless you provide your changes, please do not Tip # 4 - Declaring dependencies in a clear and consistent way? What does this even mean? Being a correct, well-formed XML document will see to that.. Tip # 5 - There's so much wrong in this one I don't know where to start ... please just delete it Tip # 6 - This is the likely result of your misunderstanding Maven, and switching the packaging type from jar to war without ever cleaning out the .m2/repo and/or without changing the artifact's version - tsk-tsk on you! Tip # 7 - Anyone that has written a plugin for Maven, even a HelloWorldMojo, is going to be of a higher caliber Maven user than you.. telling them to 'optimize' their plugins isn't at all valuable or useful Tip # 8 - Here, you seem to have digressed from the original thesis; are you speaking about a Maven Repository Manager? It's unclear, and worse still, you provide no details about what you're trying to fix, or how you recommend fixing it Tip # 9 - This is a non-issue if you are using well defined best practices for software development - by this I mean using actual versions and tagging your source code version control system appropriately during a release; any deployed artifact should be recreatable Tip # 10 - This seems like more buzz word jumbo, I'm not sure I see any tip here at all I'm sorry if I'm being harsh, but this really isn't going to be a valuable contribution. You don't even link to where you can get more information about Maven, or where much better resources may be found (e.g. http://www.sonatype.com/products/maven/documentation/book-defguide ) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Refactoring the Maven Build
Bob- In addition to some strangeness that Jesse mentioned, I think you missed a few important points, especially given what I understand to be your site's core audience: 1. Use a Maven Repository Manager 2. Use an organizational POM. 3. Lock down all plugin versions (probably via #1) 4. Use a Maven Repository Manager These three are far more important than most of the items you've listed. In fact, #4 would make more sense if it talked about using dependencyManagement at the organizational pom level to declare the standard version of libraries to be used. #7 cracked me up. If you're sitting around optimizing inhouse Maven plugins, that might be a sign you have too much time on your hands. I'd agree that you shouldn't assume a plugin knows what you want done but that's not really optimization. I can only assume that the external repository referred to in #8 is actually an internal Maven Repository Manager. In which case, if you search the archives I think you'll see that controlled access to the Internet really creates support problems. We can debate why organizations think they need to do this (although I'll pass right now), but if you're going to advocate for deploying an MRM with locked down Internet access, the least you can do is articulate the consequences of doing so. I'll disagree with Jesse a bit about #10 - I actually think there's a good point in there - Maven supports asymmetrical parent/child relationships and each combination (parent-child, child-parent, child-parent) corresponds to a specific pattern (e.g. aggregation, inheritance, multi-module). The times I've seen multi-module projects which needed to be rightsized it was largely due to using the wrong parent child relationship. (also see Use an organizational POM) In any case, thanks for writing this and getting the word out. Justin On 3/8/10 9:39 AM, Jesse Farinacci wrote: Hi Bob, On Mon, Mar 8, 2010 at 8:09 AM, Bob Aiello bob.aie...@verizon.net wrote: I just wrote an article on tactics for refactoring the Maven build and I would love to get your input. http://www.cmcrossroads.com/cm-basics/13317-refactoring-the-maven-build Feel free to post comments or send them to me privately. Bob Aiello Editor in Chief CM Crossroads http://www.linkedin.com/in/BobAiello raiello [at] acm.org Well, you seem to be a manager and not a technical developer, so I'll go easy on you. Your article is definitely filled with the right buzz words, they just don't seem to be used appropriately. The title, Refactoring the Maven Build, suggests that there will be some sort of detail provided on how to refactor the Maven pom.xml, but there aren't any details on this at all. Tip # 1 - Using help:effective-pom to diagnose problems is good Tip # 2 - Understanding what is going on in the build is generically useful Tip # 3 - Adding tracing to Maven itself isn't going to be useful to any reader unless you provide your changes, please do not Tip # 4 - Declaring dependencies in a clear and consistent way? What does this even mean? Being a correct, well-formed XML document will see to that.. Tip # 5 - There's so much wrong in this one I don't know where to start ... please just delete it Tip # 6 - This is the likely result of your misunderstanding Maven, and switching the packaging type from jar to war without ever cleaning out the .m2/repo and/or without changing the artifact's version - tsk-tsk on you! Tip # 7 - Anyone that has written a plugin for Maven, even a HelloWorldMojo, is going to be of a higher caliber Maven user than you.. telling them to 'optimize' their plugins isn't at all valuable or useful Tip # 8 - Here, you seem to have digressed from the original thesis; are you speaking about a Maven Repository Manager? It's unclear, and worse still, you provide no details about what you're trying to fix, or how you recommend fixing it Tip # 9 - This is a non-issue if you are using well defined best practices for software development - by this I mean using actual versions and tagging your source code version control system appropriately during a release; any deployed artifact should be recreatable Tip # 10 - This seems like more buzz word jumbo, I'm not sure I see any tip here at all I'm sorry if I'm being harsh, but this really isn't going to be a valuable contribution. You don't even link to where you can get more information about Maven, or where much better resources may be found (e.g. http://www.sonatype.com/products/maven/documentation/book-defguide ) -Jesse - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
