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 <[email protected]> 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: [email protected] For additional commands, e-mail: [email protected]
