Discussions

News: Maven: The Definitive Guide online

  1. Maven: The Definitive Guide online (32 messages)

    Jason Van Zyl has posted his book, "Maven: The Definitive Guide," online. It's browseable online, and as Talios points out, there's a downloadable PDF as well. The book's not quite finished - the chapter on IDEs is still missing - but is otherwise quite complete. The introduction addresses a core question: Why not just use Ant? Here's the explanation, in part:
    Ant is a great project. So was Make. However, they both suffer from the inherent weakness of the "Inner-Platform Effect" anti-pattern. The Inner-Platform Effect roughly states that by making a system too flexible and configurable, the configuration of the system itself becomes so complex it takes a specialist in order to maintain it, thus re-introducing the problem that the system was attempting to solve. Or in other words, the configuration becomes a platform itself, requiring all of the tools and special knowledge of any programming language... effectively creating a system in a system. For many non-trivial projects Ant scripts can become almost as complex than the projects that they are required to build.
    The chapter on archetypes is very interesting, partly because the typical Maven2 archetypes are fairly limited for Java EE. However, a later chapter directly addresses this, by showing a more complex example consisting of an EAR, an EJB jar, and a web app. The EAR module configuration can create a wide number of module types: the four main Java EE types (web app, client app, ejb jar, resource archive) as well as Hibernate archives, Plexus archives, and JBoss service and web service archives. It's an excellent book by authors very familiar with Maven 2. It's a good introduction as well as an excellent reference.

    Threaded Messages (32)

  2. Nice work! Thank Jason!
  3. To give credit where credit is due the book to date is the hard work of Eric Redmond, and John Casey. I'm certainly the instigator and I will be working on the IDE, convervsion, and team collaboration related chapters but Eric is the driving force and author of the majority of the content. Both John and Eric have also made some pretty cool tools to deliver the content. Also note we are getting amazing input from Mike Loukides at O'Reilly. He's a fantastic editor and it's his input that will make the guide a great book. Eric has already incorporated his input for a few chapters and the book has been update online to reflect that.
  4. Correction[ Go to top ]

    That is a downloadable HTML version of the book, not a PDF version. Apparently the PDF version will be available shortly (perhaps when the book is finished?). Cheers, Ashley. -- Ashley Aitken Perth, Western Australia mrhatken at mac dot com
  5. Re: Correction[ Go to top ]

    Once we have the PDF generation working, which is something we'll be doing with O'Reilly, we'll make it available for free on the site along with the HTML version.
  6. Then the same applies for[ Go to top ]

    I quote: "The Inner-Platform Effect roughly states that by making a system too flexible and configurable, the configuration of the system itself becomes so complex it takes a specialist in order to maintain it, thus re-introducing the problem that the system was attempting to solve." So now we have a 15 chapter book explaining maven... is that really going to be simpler?
  7. Re: Then the same applies for[ Go to top ]

    Yes, look at the Timeless Way of Building, or a Pattern Language by Christopher Alexander which are far greater in breadth and then ask any able architect, landscape architect, or city planner if it has made things simpler and they will emphatically answer with a resounding yes. I don't claim that this first attempt at the book should be compared at all to Alexander's work but this is what we're trying to do. Create a standard reference for the patterns that are a applicable to all development infrastructures in the way Alexander's books are applicable city infrastructures. This is the part most people have trouble coming to terms with with respect to Maven in that it is a tool designed for groups. An individual trying to bend Maven to their preconceived notions of project setups are often frustrated. The 15 chapters are an attempt to outline what happens over and over again in every project. So, yes, once learned in the grand scheme of things it is simpler. There is an investment of time, just like there is for a programmer learning design patterns, and an architect studying the Pattern Language. But the overall net effect is a gain, not just on an indivual level but on the level of the group. The term used to describe this effect is called social capital which is a measure of how well groups work together. A term coined by the anthropologist Jane Jacobs to measure the effective usuability of the city's design by the people who live there.
  8. Re: Then the same applies for[ Go to top ]

    I quote:
    "The Inner-Platform Effect roughly states that by making a system too flexible and configurable, the configuration of the system itself becomes so complex it takes a specialist in order to maintain it, thus re-introducing the problem that the system was attempting to solve." So now we have a 15 chapter book explaining maven... is that really going to be simpler?
    Oh the irony. The reality is that it does take a fulltime person to manage a non-trivial maven build. I should know, since I was one in a previous job and boy did it make me hate maven. There are some good things about maven, but my bias perspective is maven is complex, and doesn't have enough flexibility. for example, with ANT, I can pass it a different build file. I searched and searched, but couldn't find a way to make maven take a different build file. sometimes I needed to run a regression on an older build. With ANT I could just give it a different build file, but not with maven. If I could make a wish, it would be that maven never existed :) peter
  9. Re: Then the same applies for[ Go to top ]

    I quote:
    "The Inner-Platform Effect roughly states that by making a system too flexible and configurable, the configuration of the system itself becomes so complex it takes a specialist in order to maintain it, thus re-introducing the problem that the system was attempting to solve."

    So now we have a 15 chapter book explaining maven... is that really going to be simpler?


    Oh the irony. The reality is that it does take a fulltime person to manage a non-trivial maven build. I should know, since I was one in a previous job and boy did it make me hate maven.

    There are some good things about maven, but my bias perspective is maven is complex, and doesn't have enough flexibility. for example, with ANT, I can pass it a different build file. I searched and searched, but couldn't find a way to make maven take a different build file. sometimes I needed to run a regression on an older build. With ANT I could just give it a different build file, but not with maven.

    If I could make a wish, it would be that maven never existed :)

    peter
    Well depends of your setup I guess because I had a very good experience with Maven 2. In my former job, we successfuly and actually quite easily converted 5 ADF Oracle projects to Maven using the JDeveloper plugin. In our case, Maven was great since we wanted to dump JDeveloper but you require it to work on ADF projects require unless you are a unreadable XML lover. Maven allowed us to have a very smooth transition. We were able to easily use Eclipse or JDeveloper to work on any given project. Pretty neat if you ask me! I doubt it would have be possible using Ant.
  10. Re: Then the same applies for[ Go to top ]

    I quote:
    "The Inner-Platform Effect roughly states that by making a system too flexible and configurable, the configuration of the system itself becomes so complex it takes a specialist in order to maintain it, thus re-introducing the problem that the system was attempting to solve."

    So now we have a 15 chapter book explaining maven... is that really going to be simpler?


    Oh the irony. The reality is that it does take a fulltime person to manage a non-trivial maven build. I should know, since I was one in a previous job and boy did it make me hate maven.

    There are some good things about maven, but my bias perspective is maven is complex, and doesn't have enough flexibility. for example, with ANT, I can pass it a different build file. I searched and searched, but couldn't find a way to make maven take a different build file. sometimes I needed to run a regression on an older build. With ANT I could just give it a different build file, but not with maven.

    If I could make a wish, it would be that maven never existed :)

    peter
    Does maven take a build file? I thought the point was to not have to recreate a build architecture from scratch every time you create a new project. I know you can check in the pom.xml files that tell Maven how to build so that isn't an issue. I'm sure you could even version the Maven environment itself. I kind of laugh every time the Maven bashers yell at how it didn't work for their non-trivial environment. Well, every tool has its sweet spot so don't blame the tool if your project has outgrown it. I'd also point the finger at the human tool that possibly over-engineered the project or failed to work within the tool's specifications. Better documentation is what Maven has needed for awhile now so hopefully this book will be the ticket. I'm still on the fence with Maven. There are things I like and things that need improvement. Whether I like it or not, as a consultant I need to accept it as a reality so I'd better learn how to best use it.
  11. Re: Then the same applies for[ Go to top ]

    That is laughable. That's like saying "if your project never changes and doesn't need to support older releases, then Maven is your sweet spot." Take for example a "real" product that ships and you have to support multiple versions. Since Maven doesn't allow you to give it a different pom, you can't easily apply a patch to an older build and run the test. Things like jar dependencies, deployment process, number of apps and features change. I agree that for an environment that has to support older versions of a release for several years Maven may not be the sweet spot. If I worked on a simple webapp that doesn't have to worry about supporting older releases and running a full blown regression test with 5K+ unit tests, then sure Maven might save me some time. But then again, so would ANT. The benefits of Maven are over stated. my bias 2 bits. peter
  12. Build different version?[ Go to top ]

    Excuse if I'm missing something, but wouldn't the ability to build and support different versions of a project come down to using something like cvs or subversion? If I'm working on the 1.4.blah branch, why can't I store the pom.xml in the version control in that branch. I can't imagine having a stack of build files laying around that are version specific. "Hey Joe, I need to work on bug #8673." "Oh, check out branch 'release 3' then grab the build.xml.release3 file out of the network share, rename it to build.xml, and drop it in the project." Like I said, maybe I'm missing something, but it seems a bit ridiculous to me.
  13. Re: Build different version?[ Go to top ]

    Excuse if I'm missing something, but wouldn't the ability to build and support different versions of a project come down to using something like cvs or subversion? If I'm working on the 1.4.blah branch, why can't I store the pom.xml in the version control in that branch. I can't imagine having a stack of build files laying around that are version specific. "Hey Joe, I need to work on bug #8673."
    "Oh, check out branch 'release 3' then grab the build.xml.release3 file out of the network share, rename it to build.xml, and drop it in the project." Like I said, maybe I'm missing something, but it seems a bit ridiculous to me.
    Lets say you start out with trunk and cut a release. Some time later, a bug is found, which impacts the next release and the old one. So say I did create a branch of that release and the trunk moved forward, but there are significant changes. The question then is, how do you efficiently update the old branch. That includes changes to the build, code and unit tests? to make matter worse, say you have to test on several different platforms like windows, unix, hpux, aix and mainframe. How many freaking copies of the branch are you going to keep around and manage? Now multiply that out by the number of databases you support. make matters worse, say you have an aggressive development schedule and there's multiple development branches going on with merges every 3 months. How many branches do you have to main now? and how does not having the ability to use a different POM make life easier? Frankly, some of the design decisions in Maven are flat out stupid. Especially when doing a little thing like allowing a different build file would make life easier. I'm sure some people will think "why would you want to have multiple developement branches and deal with merges?" or "why do you need to do full regression test on a version that is 1 year old?" Ignore the "why" questions and think about how Maven would or wouldn't make life easier? Think about whether the idea of allowing a different build file really is that big of deal and why maven insists that it's bad practice. there are things I like about maven, but the weaknesses make it a complete PITA. I would only use it for open source projects where there are no branches and no need to support older releases. but i'm sure plenty people will disagree. peter
  14. Re: Build different version?[ Go to top ]

    My point is that the build.xml or pom.xml should be stored in the repository with the code. If you're maintaining different branches already (which most projects I work on have at least three branches) you keep the build file in the branch. That way you check out the project from the repository and it's ready to go. In that respect I don't see a difference between ant and maven. BTW, the idea the open source projects don't have branches and don't support older versions is rather laughable. "So say I did create a branch of that release and the trunk moved forward, but there are significant changes. The question then is, how do you efficiently update the old branch. That includes changes to the build, code and unit tests? to make matter worse, say you have to test on several different platforms like windows, unix, hpux, aix and mainframe. How many freaking copies of the branch are you going to keep around and manage? Now multiply that out by the number of databases you support." So you have one copy of the branch in your repository. If you need to make changes to it, you check it out, ready to go, with all it's unit tests, code, and build information. Make the changes and check it back in. The more you harp on the need to use a different pom, the more I question your build process.
  15. Re: Build different version?[ Go to top ]

    I've been using maven for over almost 2 years and this is exactly the strategy we've been using for re-building old releases with patches. The POMs are in source control and are labeled/checked out alongside the source and the build is subsequently run with the proper version of the POM. Typically the POM doesn't require a change to build the older version, but even if it did, it would be branched and merged just like source code would be. For our organization, it has proven to be very efficient and very easy to add new "non-trivial" projects. We have a master-pom that any project can inherit from that picks up all the "customization" required. We are an IBM-RAD shop and and for the most part use the RAD defaults for project structures. The master pom configures the appropriate jar/war/ear plugins to use RAD's defaults as well as configuring the reporting plugins (Checkstyle, findbugs, PMD, etc per our rules) and the individual project POM's essentially consist of just the dependencies specific to that project.
  16. Re: Build different version?[ Go to top ]

    I seems you confuse version control and your build system. Maven is not repsonsible for your branch management. Maven builds what it is instructed to build just like ant. Maven2 supports profiles and subprojects which I think will support your (db * env = build) problem. Yeah, maybe you should use ant for maximum flexibility but don't poison the well because someone made a book freely available. Teams that adopt maven2 and accept its convention and don't whine over edge cases will probably be more productive then ant users. All I can say is that it works for me.
  17. Re: Build different version?[ Go to top ]



    Lets say you start out with trunk and cut a release. Some time later, a bug is found, which impacts the next release and the old one.

    So say I did create a branch of that release and the trunk moved forward, but there are significant changes. The question then is, how do you efficiently update the old branch. That includes changes to the build, code and unit tests?
    How is it different from any file stored in a CVS repository? Just merge the pom.xml correctly and everything should be fine.
    to make matter worse, say you have to test on several different platforms like windows, unix, hpux, aix and mainframe. How many freaking copies of the branch are you going to keep around and manage? Now multiply that out by the number of databases you support.

    make matters worse, say you have an aggressive development schedule and there's multiple development branches going on with merges every 3 months. How many branches do you have to main now? and how does not having the ability to use a different POM make life easier?

    Wow if you had read a little bit more on Maven you would have found out that profiles solve those problems quite nicely. The problem is that you absolutely want to solve it the Ant way (using different build files). When it not possible, you blame Maven.
    Frankly, some of the design decisions in Maven are flat out stupid. Especially when doing a little thing like allowing a different build file would make life easier.
    PROFILES, ...
    I'm sure some people will think "why would you want to have multiple developement branches and deal with merges?" or "why do you need to do full regression test on a version that is 1 year old?"

    Ignore the "why" questions and think about how Maven would or wouldn't make life easier? Think about whether the idea of allowing a different build file really is that big of deal and why maven insists that it's bad practice.

    there are things I like about maven, but the weaknesses make it a complete PITA. I would only use it for open source projects where there are no branches and no need to support older releases. but i'm sure plenty people will disagree.

    peter
    Again I don't get what you want to tell us here. This is CVS or SVN job to deal to restore the old pom.xml file. How can you blame Maven for that?
  18. Re: Build different version?[ Go to top ]

    Especially when doing a little thing like allowing a different build file would make life easier.
    ``mvn -f '' I don't know if that's specific to m2 or not, because I don't use either for building, but I do use m2 for a postbuild task for some mojos. The public repos don't seem to enforce any quality control for naming or POM validity, making transitive dependencies _worthless_. ibiblio should force all POMs to resolve before they are deployed and remove duplicate artifacts with different organization paths. I just converted our sizable multiproject Ant build to use Ivy and it was nothing less than a pain in the ass to use the m2 repos. I basically had to turn off pom usage and pull in all of the deps manually. I had tried this in the past with m2's "OMG it's magic and does everything... flawlessly?" dependency management. Needless to say, it didn't work. Pull in one wrong project and you've just spent an hour downloading deps that you don't need at all, have variables in the POMs that aren't defined anywhere, etc. Anyway, m2 would be nice if it used Ivy for the dependencies, had a decent catalog of mojos that actually worked and were up to date, and had a larger set of core developers to do all of this. :)
  19. Re: Build different version?[ Go to top ]

    Especially when doing a little thing like allowing a different build file would make life easier.

    ``mvn -f '' I don't know if that's specific to m2 or not, because I don't use either for building, but I do use m2 for a postbuild task for some mojos. The public repos don't seem to enforce any quality control for naming or POM validity, making transitive dependencies _worthless_. ibiblio should force all POMs to resolve before they are deployed and remove duplicate artifacts with different organization paths. I just converted our sizable multiproject Ant build to use Ivy and it was nothing less than a pain in the ass to use the m2 repos. I basically had to turn off pom usage and pull in all of the deps manually. I had tried this in the past with m2's "OMG it's magic and does everything... flawlessly?" dependency management. Needless to say, it didn't work. Pull in one wrong project and you've just spent an hour downloading deps that you don't need at all, have variables in the POMs that aren't defined anywhere, etc. Anyway, m2 would be nice if it used Ivy for the dependencies, had a decent catalog of mojos that actually worked and were up to date, and had a larger set of core developers to do all of this. :)
    I don't believe maven1 supports that. I see all the maven fanboys are out defending it. I've read maven1 docs dozens of times and I've also looked at the source. I do contribute to quite a few open source projects, so I do know how open source works and have provided patches for a few projects over the years. thanks for reminding me m2 supports -f option now. The specific scenario I'm thinking of, which is very common in my experience where different pom or build files are useful. 1. say the deployment process changes between branches, but not the code. The most obvious is changing jdbc drivers. In maven1, the way we got around it was to make a different set of build files with different jdbc properties. 2. a change in a library, which affects compilation, but not runtime. Say you use version x.x of a library and have to change to a newer release. 3. keeping n copies of a repository is not practical if a snap shot of a repo takes over 10gb of disk space. I'm sure people are going to say HD is cheap now. Sure it's cheap, but not if your company won't buy you new HD. The first thing the money crunchers will say is "delete your old files. you don't need new HD." We kept as many copies as practical until we ran out of disk space. It really does require a fulltime person to maintain and manage all those different repos and builds. 4. there's a dev branch which is adding new features. this usually means a different deploy and build process. Sometimes you want to see what happens if you run the new scripts on the main trunk. Why? It's useful to see how things will fail, so that it can be documented. I'm sure people will disagree and keep saying "you don't get maven." Maybe I don't, but frankly, I wouldn't recommend maven1 to anyone. M2 still annoys me, but it does have some improvements. For my money, ANT + good conventions is better than Maven. it provides consistency without all the annoying stuff Maven forces on you. peter
  20. Re: Build different version?[ Go to top ]

    The point of this thread is that a Maven book came out. The book covers Maven 2 exclusively so bringing up Maven 1's shortcomings is out of context and misleading. The Maven project and proponents have been very public about how Maven2 is a complete overhaul and that Maven 1 is deprecated. In short, they've admitted that they got it wrong in Maven 1 and had to start over with Maven 2 to do it right - welcome to open source. With the danger of being labeled a fanboy I'm again accusing that your posts on this topic have been more FUD than helpful criticism. Why not say Java is unusable today because version 1.0's JVM was too slow and didn't provide the XML support you need? It is fair to criticise Maven's shortcomings (I do all the time) but the reason people keep saying you don't understand Maven is because you are complaining about issues from an old, deprecated release that have been solved. I suppose it is apache's fault for not coming up with a new name for version 2.
  21. I do agree, its unfair to criticise M2 based on the M1 experience. Long, slow, inconsistent builds. But at the same time, the criticisms of Ant are based on old Ant, before , before Ivy, before the presetdef and macrodef tasks let you define new tasks that scale across many projects in a team. So please, provide constructive criticism of Ant, but lets temper it with knowledge of modern Ant+Ivy, and experience of real-world maven. The one where you suddenly fall out of the simple world of the POM into embedded use of the out-of-date version of Ant that maven ships with, the one where you end up trying to create your own archetype just to get javacc to create java source before compiling, or the one where you spend hours trying to discover why servlet-2.3 and dom4j are sneaking in to your application. -steve
  22. maven is like the projects[ Go to top ]

    "you are complaining about issues from an old, deprecated release that have been solved." Which can be retroactively applied to maven2. By your logic maven2 doesn't need to exist, now that ant1.7 + ivy + m2tasks are here. The only problem left that maven seems to solve is that a lot of 'enterprise' teams don't know how to build and deploy enterprise code bases into systems - maven2 solves that by severely restricting what they are allowed to do. That's not a timeless way of building; that's the projects, the polar opposite of what Alexander was trying to achieve.
  23. Re: Build different version?[ Go to top ]

    I have used ANT, since its early days, when it was considered the killer build tool (enough to hopefully bury make anyway), and as it matured (for example through collaboration with IVY). The greatest features included a flexible scripting language (albeit XML), extensible tasks and a suite of plugins BUT therein lay the challenge. Since ANT allowed individuals/organisations almost complete freedom in defining project structures/styles/build processes they tended to be tailored to suit personal/team preference rather than a coherent set of best practices. In our experience on various large enterprise projects we tried to define some sense of best practice (atleast within the organisation). It basically included highly flexible ANT scripts, with a concept of parent and child projects, and various tweaks (using properties files and command line parameters) to control the build process (code checks, dependencies, etc.) and the final delivered artifacts. The further along the line we went the closer it seemed we were getting to our own custom build tool (which we had to maintain, explain, document), and then Maven 1 came onto the scene, and we hoped it would solve all our problems... Although using maven 1 was tough [i.e. with the lack of documentation and project momentum; its called open source for a reason ;)], it supported a more structured build process, one that was at least steeped in some sense of best practice (some common project structure atleast). Were some things less than perfect? Hell yeah, but given the alternative it became the lesser of two evils, we stuck with it (for over 2 years) and it does eventually grow on you? All the bad press that Maven 1 received for its sometimes warranted complexity has to to a large extent hurt Maven 2 adoption. It is perhaps not well known that Maven 2 was completely re-designed taking into consideration many of the challenges that were faced by Maven 1 adopters, and tried to establish a more coherent set of best practices as well as provide more thorough documentation. It scales very well on large enterprise projects, the knowledge gained on using maven is almost immediately transferrable onto other projects using maven, and it is fairly transparent in its efforts to support a more comprehensive software development, build and release process. Are some things still less than perfect? Hell, yeah, but there is definite momentum in the project? I would encourage people to give Maven 2 a try with an open mind and then debate the merits and demerits from an informed position. And if Maven 2 is not the answer (and I believe its a fairly good approximation), then hopefully a fruitful discussion will move us closer in the right direction?
  24. knowledge transfer[ Go to top ]

    "the knowledge gained on using maven is almost immediately transferrable onto other projects using maven" +10
  25. Re: Then the same applies for[ Go to top ]

    That is laughable. That's like saying "if your project never changes and doesn't need to support older releases, then Maven is your sweet spot."

    Take for example a "real" product that ships and you have to support multiple versions. Since Maven doesn't allow you to give it a different pom, you can't easily apply a patch to an older build and run the test.

    Things like jar dependencies, deployment process, number of apps and features change. I agree that for an environment that has to support older versions of a release for several years Maven may not be the sweet spot. If I worked on a simple webapp that doesn't have to worry about supporting older releases and running a full blown regression test with 5K+ unit tests, then sure Maven might save me some time. But then again, so would ANT.

    The benefits of Maven are over stated. my bias 2 bits.

    peter
    Laugh all you want, but it seems to me, and obviously others, that you don't really understand Maven2 enough to be bashing it. I'm working on a project right now that uses Maven2 and has worked fine through one supported release, two upcoming releases, and a whole bunch of branches in between. Using CVS we're able to check in the pom files and tag them to releases/branches like any other code artifact - big whoop. Maybe we're just stupid like a fox but I'm able to check out any tag and build it with Maven against the tagged pom file just fine. Heck, I can even run the unit tests at that point. The things you are laughing at, like versioned jar dependencies are trivial. Maven pulls the version we specified in the pom, whether that was today or 4 months ago. I guess it is a good thing that this free book is now available so that everybody who is interested can be on the same page. Like I said before, I'm still sitting on the fence but the things you're knocking appear to be more FUD than constructive.
  26. IDE integration is one of maven's big weaknesses, IMHO. Maven tries to be an IDE itself, with its plugins, lifecycles, and the like. It's like a "text mode IDE", and that doesn't make sense to me. I understand the need for a script based build tool, I've been using ant for ages - including complex setups with several builds "inheriting" from a central one, xdoclet and j2ee integration, and so on. I also understand the need for dependency management, and maven does a good job at that, but so does ivy. Ant plus either maven tasks or ivy seems to be the way to go.
  27. So I like the idea of Maven and even played with it on a few projects. A few questions. 1. Is it possible to get the POMs to pull down source code zips along with the jars? Most open source I use I pull down the source for the occasional stepping through. 2. I found the repository maven pulls down to be really unpleasant to work with in Eclipse because adding the jars required a really tiresome drill down into various subdirectories. Other than some sort of ant script to copy all the jars into a flat lib directory I was wondering if anyone else had a good way of keeping your Eclipse dependencies up to date without having such a tedious manual process.
  28. Check out the eclipse plug-in and configure it with downloadSources=true. All the sources will be downloaded for you and it will generate the .classpath file for you with sources attached. It cuts down on the "drilling" by using a "M2_REPO" classpath variable defined pointing to the root of your maven repository. One thing I do desire is something that will help with the reverse. Developers occasionally update the .classpath files, are ignorant of or forget about the POM and our build breaks. A plugin that would "merge" the two would be great.
  29. Good job! In fact, when using Maven, the poor documents breaks me (and others). a cup of Java, cheers! Sha Jiang
  30. Well done, Jason ![ Go to top ]

    Hi, this is just a good news. The previous book was quite good, I can't weit reading this new one. I must admit that I never was a stro,g suporter of Maven, due to Maven 1 which was quite a painfull experience, but with Maven 2, we have reached a point where using Maven is just possible. And the fact is that it's evolving quickly in the good direction. Starting a new project is just a breeze, and as I'm using maven on a big project, with more than 20 sub-projects, I must admit it's running smoothly, is reliable, and ok, not as fast as we would expect, but enough for our need ! Keep on the good job, and I wish you the best with Sonatype btw !
  31. cOOl, it is really an amazing work. congrats to the honorable authors.
  32. Ant may be open-ended but I came up to speed on Ant and was able to handle complex one-of-a-kind build requirements very quickly - mostly by rooting around in the Ant docs to find similar examples. Ant is perhaps a silly misue of XML but at least it is pretty easy to understand what is going on. I'm new to maven (starting out with m2) but I have already spent far more time learning it than I ever spent learning Ant. And probably the reason is that the docs are so incomplete. I really don't like tools that are not transparent. I tried the 5 minute getting started example and it downloaded 450 files into a repository - what is this garbage about!!! For instance if I want to find out the specific versions of all the direct and indirect dependencies that are used to build my project, I'm not clear how to do that. I'm spending a lot of time rooting around in the repository with little understanding of where to look. Archtypes, profiles, plugins, phases - what a mess! Hopefully this new book will clear some of this up. I haven't given up (yet).
  33. More newbei gripes[ Go to top ]

    For a start how about some simple definitions - goal, artifact, phase, plugin, mojo, profile. You eventially figure out what these terms means by groping around in the maven 2 docs. This book also needs such a glossary for these kinds of terms.