Discussions

News: Five tips for successfully deploying Maven

  1. Five tips for successfully deploying Maven (28 messages)

    Maven is more of a project management system than just a build tool. Domain-driven design expert Peter Backlund provides five handy tips for adopting Maven in your projects in as painless and efficient way as possible.
    Maven is one of those things that people seem to hate rather intensely, but nevertheless adoption is steadily rising in the Java community. I've worked with Maven almost daily since the 1.0 betas, and here are five things that I think could help your team working more efficiently with Maven.

    Threaded Messages (28)

  2. Here's my tip. Don't use maven. Sorry, I couldn't resist. Flame on! peter
  3. Here's my tip. Don't use maven.

    Sorry, I couldn't resist. Flame on!

    peter
    I have to second that. Maven is very complicated and goes beyond the boundaries of being being fairly balanced in terms of being powerful and easy to use. It's simply too complex a tool to use to be useful in the long run and for a software project of a significant size, even though it purports to help out in that area. Too many moving parts to keep track of. I equate Maven to early J2EE. It needs a serious face lift the likes of JEE5, and onwards to start making sense to busy working software development professionals. Right now, it's more akin to a black art that's mostly being evangelized by a zealous cultist sect.
  4. Here's my tip. Don't use maven.

    Sorry, I couldn't resist. Flame on!

    peter

    I have to second that. Maven is very complicated and goes beyond the boundaries of being being fairly balanced in terms of being powerful and easy to use.

    It's simply too complex a tool to use to be useful in the long run and for a software project of a significant size, even though it purports to help out in that area. Too many moving parts to keep track of.

    I equate Maven to early J2EE. It needs a serious face lift the likes of JEE5, and onwards to start making sense to busy working software development professionals. Right now, it's more akin to a black art that's mostly being evangelized by a zealous cultist sect.
    I disagree. First of all, it's not a dark art. It's documented pretty well. I suggest the free book Better Builds with Maven. I found Maven to be quite painless and easy to use and a huge productivity boost. After 2 weeks, I started changing every project I've ever touched from ANT to maven and never want to go back to the ANT days. My best guess it that if you actually got familiar with the product, you wouldn't be so quick to dismiss it. In particular, try out the various plugins described in the Better Builds with Maven book. My favorites are the eclipse plugin, the Jetty plugin, cargo, the deploy plugin, and and the code metrics plugins. Maven has plenty of room for improvement, but I challenge you to replicate all the functionality documented in Better Builds with Maven with any technology available now and then comment if you think it's too difficult to use.
  5. Maven is very complicated and goes beyond the boundaries of being being fairly balanced in terms of being powerful and easy to use.

    It's simply too complex a tool to use to be useful in the long run and for a software project of a significant size, even though it purports to help out in that area.
    I agree. I think it could be better to spend time to improve the Maven-alter ego dependency manager: Apache Ivy. I used both Maven (since 2.0.3) and Ivy (since pre-apache versions) and my definitive choice is Ivy. It simply makes what we need. Moreover, I can not ignore that Maven has many better features as: - better documentations; - a build life-cycle (In Ivy you have to build up your build program from scratch); - easy generation of project documentation (site:site); - better project modularization. As counterpart Ivy is better for: - repository management: it is very easy to manage in general and in particular is very easy to install new artifacts with dependencies; - very fast project building; - if you want you can compile avoiding to access to the repository (to speed up the building process); - easy to use and to customize (you have the whole power of Ant); - the plugin versions are not updated in real time!!! De gustibus non est disputandum... ...but Maven has many limitations that cannot be ignored.
  6. I equate Maven to early J2EE. It needs a serious face lift the likes of JEE5, and onwards to start making sense to busy working software development professionals. Right now, it's more akin to a black art that's mostly being evangelized by a zealous cultist sect.
    Funny, the same can be said about zealous cultist Spring fanboys only a few years ago. When was the last time you looked at Maven2? Look again. I used to be an ant user. After using Maven2 for a while I've converted all of my projects to it and haven't looked back. It's so much lighter, cleaner, easier, and makes it easy for developing my project on multiple OS's, multiple computers, and easy to use a CI server. The standardized directory structure and configuration is a huge plus.
  7. Funny, the same can be said about zealous cultist Spring fanboys only a few years ago. When was the last time you looked at Maven2? Look again.
    Personally, I think Maven2 documentation is still fairly poor. Compared to the documentation for core ant tasks for example, most plugin documentation is very, very thin. As for Spring comparison: Well it started out as a somewhat meaningful thin wrapper over J2EE to avoid EJBs (essentially a reinvention of stateless session beans without the configuration hazzle) and has grown to become a full blown JEE replacement-on-top-of-JEE-but-with-even-more-mindless-xml-configuration-where-people-build-millions-of-interfaces-for-classes-with-exactly-one-implementation. If that is where Maven is heading: Godspeed!
  8. I think Maven is the greatest thing since sliced bread. It may be overkill for a single small to medium sized project if nobody on the team knows Maven. However, in my case for a large organization looking to provide a standard consistent building, reporting, documentation, dependency management, project structure, etc across the organization, Maven has been a godsend.
  9. I think Maven is the greatest thing since sliced bread. It may be overkill for a single small to medium sized project if nobody on the team knows Maven. However, in my case for a large organization looking to provide a standard consistent building, reporting, documentation, dependency management, project structure, etc across the organization, Maven has been a godsend.
    I wholeheartedly disagree. It's perfect for a small project. Source code + other classpath resources in a jar, or war. Honestly, we've all done it before. javac + jar, maven2 is great at. If you want to do something interesting, like having separate dependency sets depending on your target for instance (dynamic jar dependency), you're pretty screwed. Autoconf supports it in a different mindset. Ivy does in its dependency-set definition.
  10. Maven is great![ Go to top ]

    As a long-time Ant user, Maven is awesome. Ant scripts are easier to write, but harder to read. Maven builds are harder to write, but easier to understand. There are some rough spots: the repo is still confusing. I hit glaring bugs in 2.0.9. They were fixed in 2.0.10, but that's still bad for such a mature project. But overall, Maven has really simplified many of my day to day grunt tasks. This is the most practical new software tool that I've discovered in the past few years.
  11. Re: Maven is great![ Go to top ]

    I have been using maven for a few years and it has helped immensely over previous techniques for building and testing. I think it's greatest strength is simply that it standardizes the paths for where to put the various elements of your code. Once those are standardized then standard plugins can be written. Maven got everyone to agree on those paths. I think the reason so many people don't like it is because before version 2.0.9 it had a lot of very bad bugs. I've researched numerous issues with the "maven uncertainty principle" caused by things like bugs in the maven classloader. Since the 2.0.9 release things have worked fairly well. Also maven is slow compared to a simple ant script because it is doing alot more and because it often ends up checking remote repositories for updates. But once you understand how it works and how to get it do what you want, which does take awhile, it is quite an advancement over the previous ad-hoc ant script approach. My favorite plugins are the jetty plugin, and the standard unit test plugin.
  12. Re: Maven is great![ Go to top ]

    My favorite plugins are the jetty plugin, and the standard unit test plugin.
    Javadoc, clover plugins pretty cool too. +1 for maven here. My favorite part is the seemless IDE integration (Intellij). Same portable project file is usable from IDE and command line. Huge improvement over ant rolled build scripts. I will admit that maven was a total pain to get going. The documentation is HORRIBLE and error messages even worse. The way I was able to figure things out was to look at how other OSS projects used it.
  13. get rid of xml[ Go to top ]

    suggestion to maven coders: ditch xml and adopt a real scripting language. xml is not a programming language! then maven gets interesting.
  14. Re: get rid of xml[ Go to top ]

    xml is not a programming language!
    before I get flamed for this, I should clarify. XML is not a scripting language. :) "programming" is to generic, can mean anything. XML is not an imperative language, it's designed for declarative constructs: documents, configuration, data.
  15. Re: get rid of xml[ Go to top ]

    Couldn't agree more Peter. The pom.xml exists to define a project and the use of a declarative language is a perfect selection for this task. Xml has been horribly misused by many other projects/specs, but this not one of them... If you dislike maven, that's fine. It's people who have to use/maintain your project after you move on who benefit, not just from the pom.xml that tells them everything about your project, but also the cleaner code you will find yourself writing to conform to maven's compile time class path management. Rex
  16. Re: get rid of xml[ Go to top ]

    Couldn't agree more Peter. The pom.xml exists to define a project and the use of a declarative language is a perfect selection for this task. Xml has been horribly misused by many other projects/specs, but this not one of them... If you dislike maven, that's fine. It's people who have to use/maintain your project after you move on who benefit, not just from the pom.xml that tells them everything about your project, but also the cleaner code you will find yourself writing to conform to maven's compile time class path management.

    Rex
    The Maven idea is a good one. No one really argues against that point, however, the implementation is a bit poor. This would have been ok in the 1990's but, this is 2009. Things should be space-agey. I think Maven should take a page from the Wicket/Netbeans book and spend time hiding the unnecessary plumbing from busy programmers who mainly need workable turnkey solutions to help them to leave the office by 5:00 p.m. the latest. Not everyone has the time to invest in fudging through clutter the first time to figure out how something should work. The creators of such projects should look at ensuring that the end users of their creations have a good experience the first time by ensuring that the end users are properly shielded from time wasting glut. In other words, ensure that the interfaces for your creations are properly buttoned up and abstracted to allow for a pleasant and productive user experience the first time. The contrary is the story of so many open source projects (i.e. user experience quality sacrificed for overly exposed complexity).
  17. Re: get rid of xml[ Go to top ]

    XML is not a scripting language. :) "programming" is to generic, can mean anything. XML is not an imperative language, it's designed for declarative constructs: documents, configuration, data.
    Programming is hardly generic and is usually assumed to be something usually turing complete. XML is neither turing complete nor has execution instructions. You can apply instructions in XSLT, but that's turning XML INTO a language with instructions. The only instructions in XML are, among others as I'm doing this off the cuff: - start a tag - add metadata to the tag - end the tag - start and end a comment - define the encoding - dtd or schema definition to define a sub grammar - namespaces? When I can do 1+1 in XML, lemme know. :)
  18. Re: get rid of xml[ Go to top ]

    suggestion to maven coders: ditch xml and adopt a real scripting language. xml is not a programming language!

    then maven gets interesting.
    Well, Maven is not a scripting tool, that's what makes it different from Ant for exmple. The POM file is primarily a configuration file. Maven is a declarative build system backed by a number of conventions, to minimize the need of scripting. That said, sometimes you do need to script things, and that's not exactly as streamlined as it could be. There's the Antrun plugin of course, and GMaven looks promising (despite the horrible logotype): http://groovy.codehaus.org/GMaven+-+Executing+Groovy+Code
  19. For the record, the claim that I'm a "Domain-driven design expert" was added by the TSS editors :-). While it is true that I am engaged in the DDD community, it really has nothing to do with Maven and don't want anyone to get the impression that it does. Anyway, the point of article was not primarily to advocate people to move to Maven, but rather help those who have made the move but are struggling, or those who are thinking of making the move and could use a few pointers.
  20. Strange article[ Go to top ]

    If you like Maven or not, some of the tips seem bizarre. Like "learn how to use the dependency plugin" or "use the documentation"...hmm. I think Maven gets dependency management mostlyright, but it is a much too rigid as well as patronizing as a build tool. Strangely, the people who want the most freedom in some dimension, say using Groovy, want a very constrained environment when it comes to building. Some of my thoughts on Maven can be found here. Maven is a lot more verbose than the usual maven elevator pitcher confesses. Maven projects for trivial J2EE projects outgrow Ant projects definitions fairly quickly. (Maven catches up again, if you need and use the mvn site). Maven dependency management can get really messy if your project creates more than one artifact with different dependencies (common when creating EJB implementations and clients).
  21. I'm relatively new to Java, but have had a good look at Maven mainly because of the hype. While it is a (java) project management tool, many of the posters I've read and people I've asked appear to use it for dependency management. So what I was wondering was shouldn't the Java runtime do this when a jar is built, similar to how it's done in .Net? (http://msdn.microsoft.com/en-us/library/1w45z383.aspx). This way when you add a conflicting dependency you don't get the problem at runtime (if not using Maven) or build time (if using Maven?). You get the error when you add the reference in the IDE - when you should get the error - when the error is actually caused. I've been surprised to see seasoned Java practitioners spend days chasing errors a that were ultimately caused by conflicting dependencies. The burn on project time for issues such as this should NEVER happen. Christian.
  22. I'm relatively new to Java, but have had a good look at Maven mainly because of the hype. While it is a (java) project management tool, many of the posters I've read and people I've asked appear to use it for dependency management.

    So what I was wondering was shouldn't the Java runtime do this when a jar is built, similar to how it's done in .Net? (http://msdn.microsoft.com/en-us/library/1w45z383.aspx). This way when you add a conflicting dependency you don't get the problem at runtime (if not using Maven) or build time (if using Maven?). You get the error when you add the reference in the IDE - when you should get the error - when the error is actually caused.

    I've been surprised to see seasoned Java practitioners spend days chasing errors a that were ultimately caused by conflicting dependencies. The burn on project time for issues such as this should NEVER happen.

    Christian.
    That's coming in the very hotly debated JSR277 and JSR294: a java module system similar to OSGi. It was supposed to be in Java 7 but since there is so much debate about how it should be done, it will not make Java 7. Project Jigsaw is the compromise, but will be proprietary to Sun's JVM. That is different from being able to say I need library X version 3.2.1 and having it downloaded from a corporate or public repository on your computer. That's where Maven and Ivy come in. JSF277/294 are also not build systems.
  23. That's coming in the very hotly debated JSR277 and JSR294: a java module system similar to OSGi. It was supposed to be in Java 7 but since there is so much debate about how it should be done, it will not make Java 7. Project Jigsaw is the compromise, but will be proprietary to Sun's JVM.

    That is different from being able to say I need library X version 3.2.1 and having it downloaded from a corporate or public repository on your computer. That's where Maven and Ivy come in. JSF277/294 are also not build systems.
    Wow, JSR 277 has been around for quite a while. Are there any reference implementations people can take a look at? Maybe such an implementation will help crystallise the decision making process in the same way as early working software helps with agile projects. If the Java platform takes this long to decide on how it innovates it will become the next Cobol. For the record I'm using Ivy and I see no need for automatic dependency downloading for enterprise software build processes - although it helps with the initial build when you first grab your 3rd party library. Christian.
  24. Wow, JSR 277 has been around for quite a while. Are there any reference implementations people can take a look at? Maybe such an implementation will help crystallise the decision making process in the same way as early working software helps with agile projects.
    That's what they decided to do. Since there were very very religious emotional debates between the JSR277 and JSR294 (OSGi) groups, Sun has decided to begin the work anyway so they can modularize the JDK. In the future when a standardized API is decided upon, they will support it. You can participate here: http://openjdk.java.net/projects/jigsaw/
    If the Java platform takes this long to decide on how it innovates it will become the next Cobol.
    This is Java, not Microsoft. Java is a bunch of specifications that the entire industry works together to create and agree upon. Then, multiple vendors create their implementations. Backwards compatibility is a top priority. I don't think the same is true with Microsoft and .NET. They can make any change they want without being disrupted by standards committees. Not all of the JSR standards take this long to come to a decision on. The standards process has worked like this for nearly 15 years and Java is nowhere near dead or cobol-like yet.
  25. That's what they decided to do. Since there were very very religious emotional debates between the JSR277 and JSR294 (OSGi) groups, Sun has decided to begin the work anyway so they can modularize the JDK. In the future when a standardized API is decided upon, they will support it. You can participate here:

    http://openjdk.java.net/projects/jigsaw/
    I'll check that and OSGI out.
    This is Java, not Microsoft. Java is a bunch of specifications that the entire industry works together to create and agree upon. Then, multiple vendors create their implementations. Backwards compatibility is a top priority. I don't think the same is true with Microsoft and .NET. They can make any change they want without being disrupted by standards committees. Not all of the JSR standards take this long to come to a decision on. The standards process has worked like this for nearly 15 years and Java is nowhere near dead or cobol-like yet.
    I take your point. I'd say MS didn't have backward compatibility as a priority because running multiple versions of the run time on the same machine is pretty trivial (I understand it's just as trivial to do in Java), although back compatibility hasn't been broken since version 2.0. I believe version 2.0 broke because of how they chose to implement generics. Personally I'm not a fan of type erasure. Christian.
  26. That's what they decided to do. Since there were very very religious emotional debates between the JSR277 and JSR294 (OSGi) groups, Sun has decided to begin the work anyway so they can modularize the JDK. In the future when a standardized API is decided upon, they will support it. You can participate here:

    http://openjdk.java.net/projects/jigsaw/

    I'll check that and OSGI out.
    This is Java, not Microsoft. Java is a bunch of specifications that the entire industry works together to create and agree upon. Then, multiple vendors create their implementations. Backwards compatibility is a top priority. I don't think the same is true with Microsoft and .NET. They can make any change they want without being disrupted by standards committees. Not all of the JSR standards take this long to come to a decision on. The standards process has worked like this for nearly 15 years and Java is nowhere near dead or cobol-like yet.


    I take your point. I'd say MS didn't have backward compatibility as a priority because running multiple versions of the run time on the same machine is pretty trivial (I understand it's just as trivial to do in Java), although back compatibility hasn't been broken since version 2.0. I believe version 2.0 broke because of how they chose to implement generics. Personally I'm not a fan of type erasure.

    Christian.
    Actually there are breaking changes between 2.0 and 3.5, but it's not nearly as bad. If you use strong assemblies though, you end up with DLL hell. peter
  27. Actually there are breaking changes between 2.0 and 3.5, but it's not nearly as bad. If you use strong assemblies though, you end up with DLL hell.
    I'd be interested if you posted a link documenting where an app compiled on .Net 2.0 and deployed to a 3.5 box no longer works. .Nets 3.0 to 3.5 were just additional assemblies much like javax. I'd also like an example of how using strong assemblies results in DLL hell as my experience over the last 7 years is the exact opposite - which is why I'm pushing for Java to have the same. Even using DI frameworks where you don't compile your app against the implementing assembly the issue still doesn't happen if your DI configuration specifies the full strong assembly name in the dependency. Christian
  28. I like to hear about people's favorite tools for a particular purpose. Obviously, for building and overall project management, we're talking about Maven on this thread. But what about a repository manager? Peter mentioned Nexus (http://nexus.sonatype.org/) as his favorite. What do people reading this thread commonly use? Cheers, David Flux - http://www.fluxcorp.com - Java Job Scheduler. File Transfer. Workflow.
  29. Nexus+Maven+q4e[ Go to top ]

    All the dev/build stuff can be done through the ant tasks or even cmd line, but there's a maven and maven is the bets what we have (for now). It's easy to use, easy to extend and easy to adop to your needs. Nexus+Maven+q4e and you're ready to go with the best performance.