Maven 2.1.0 Released

Discussions

News: Maven 2.1.0 Released

  1. Maven 2.1.0 Released (14 messages)

    Maven 2.1.0 is released ! Check out the full release notes here

    Threaded Messages (14)

  2. congratulation to Maven team[ Go to top ]

    We've already used maven for a long time, it's great to upgrade to newest version. Congrats to maven team.
  3. Finally - I will be officially able to use the same version of Maven with Eclipse and from the command line, since m2eclipse essentially forced usage of 2.1 beta anyway. That aside, Maven is great for dependency management - when you need it - but it is a very poor and extremely rigid build system. At least when you want to keep things simple. 2.1 does very little to fix that. For example, it takes a bizarre amount of code to create a version class that returns the respective version number. For a lot of basic things one wants to do, one needs to fallback to ant, since the Maven plugins simply fail (XDoclet being a particularly annoying example).
  4. Finally - I will be officially able to use the same version of Maven with Eclipse and from the command line, since m2eclipse essentially forced usage of 2.1 beta anyway. That aside, Maven is great for dependency management - when you need it - but it is a very poor and extremely rigid build system. At least when you want to keep things simple. 2.1 does very little to fix that.

    For example, it takes a bizarre amount of code to create a version class that returns the respective version number. For a lot of basic things one wants to do, one needs to fallback to ant, since the Maven plugins simply fail (XDoclet being a particularly annoying example).
    I concur. It is a real life saver for what concern dependency management. The plugins system is probably the best they could do but, in any case, there is the good old antrun plugin :)
  5. For example, it takes a bizarre amount of code to create a version class that returns the respective version number.
    Strange. For me it is enough to use: src/main/resources true And use ${project.version} in version.properties file, which is then resource-loaded from any (e.g. Version) class... I don't want Maven to change (except for generate) my source files... regards Grzegorz Grzybek
  6. Still too complicated[ Go to top ]

    For example, it takes a bizarre amount of code to create a version class that returns the respective version number.
    Strange. For me it is enough to use:
    src/main/resources
    true

    And use ${project.version} in version.properties file, which is then resource-loaded from any (e.g. Version) class... I don't want Maven to change (except for generate) my source files...

    regards
    Grzegorz Grzybek
    Right you are. And I think since I must create a version class that loads data from a unique path and filename (required to be classloader safe) and create a file that contains just this version data that this is about twice as much as I would need to be :-). Honestly, some things really are strange with Maven if you try to avoid using antrun. As another example just consider using a single version number in multiple subprojects. I spent around a day trying to figure out how to supply this through the parent project...either impossible or I just did not find it neither in the maven docs nor third party literature. Stuff like this should take 10 minutes to figure out. Or consider running xdoclet - multiple plugins available, all fail under one or the other circumstances (for example the one we used refuses to work with Maven 2.1). And the amount of code needed for any real world project quickly outgrows the code needed for ant. That said, you do get the dependency management, which is good especially in larger projects with lots of third party code.
  7. Re: Still too complicated[ Go to top ]

    Right you are. And I think since I must create a version class that loads data from a unique path and filename (required to be classloader safe) and create a file that contains just this version data that this is about twice as much as I would need to be :-).
    You're right :) I just do such things in webapps, where I must load a version number in multiple JSPs or Spring xml files and it works for me. Inserting the number in java files is a bit more complicated :) I remember resolving problems with ear + war + overlays...
    As another example just consider using a single version number in multiple subprojects. I spent around a day trying to figure out how to supply this through the parent project...either impossible or I just did not find it neither in the maven docs nor third party literature.
    Somewhere around version 2.0.7 it was possible to use ${anyVersion} placeholders for version number - it was set in parent POM - but I'm not even thinking about deploying such multimodule projects - usually my parent POM has versions like "1" and it contained dependencyManagement. Then child POMs referred to such parent by "simple" version from where they got their property version. Grzegorz Grzybek
  8. Strange. For me it is enough to use..
    And of course that works brilliantly when the version number contains a quote and the file you are filtering is a java file with its version number in a string. Likewise if your version number contains an ampersand and you happen to be filtering an xml file your in trouble Maven falls apart when you want to do anything its developers did not consider (and they did not consider a lot). Its just not a very flexible system. And in a world where there are no "standard projects" that's not a good thing
  9. That's the point[ Go to top ]

    Maven falls apart when you want to do anything its developers did not consider (and they did not consider a lot).

    Its just not a very flexible system. And in a world where there are no "standard projects" that's not a good thing
    Inflexibility is exactly the point. Maven has a definite opinion on the "best" methods. You may not always like or agree with them - but standardizations are always difficult. At the end we all look back and say: "Man, why didn't we do this years ago." Maven isn't interesting because it's perfect. It does some things well, and some things poorly. It only hits about 95% of use-cases - and those remaining 5% take up 80% of your time. This isn't news. But it must exist - precisely by your last point. There are not "standard projects"... but the goal is to change that. The problems with software development - and developers - intercommunicating should be solved. It's not an interesting or fruitful problem to invent a new build system for every project. And I'm sure you don't. I'm sure your project's ant scripts started out perfectly normal - copy and pasted from elsewhere - before they morphed to some chimeric mess lacking direction. Maven provides direction - built on the backs of thousands of build engineers and years of experience. Still not perfect - but getting there. Maven will NEVER hit 100% of use-cases, but as more people use it, that remaining 5% of missed cases will shrink... to 4%... then 3%... und so weiter... Assuming you didn't say TL;DR, here's a more philosophical bent about it: http://www.coderoshi.com/2007/07/showing-constraint.html
  10. Re: That's the point[ Go to top ]

    It's not an interesting or fruitful problem to invent a new build system for every project. And I'm sure you don't. I'm sure your project's ant scripts started out perfectly normal - copy and pasted from elsewhere - before they morphed to some chimeric mess lacking direction. Maven provides direction - built on the backs of thousands of build engineers and years of experience.
    That is the question. Ant served as a perfectly valid and flexible build system but for one thing - dependency management. Dependency management is important but it is also overrated. As long as you do not work in an environment where you tie together various libraries into a product on an ad hoc basis you will actually never really need it (it is convenient though). You will download whatever dependencies you need, check them in, have a working product and never look back :-). And the same that holds true for ant, holds true for Maven: You need an EAR file: Create a new project for it! You need to test the EAR file in a real scenario: Create a new project for it! You want to deploy your stuff to a server: You need 150 lines of code in Maven adressing some third party plugin that should be bound to a build phase you never heard or thought about. As a result of a multimodule project you will have a lot of totally meaningless artifacts in your repository, unless you leave the standard path.
  11. Re: That's the point[ Go to top ]

    Maven falls apart when you want to do anything its developers did not consider (and they did not consider a lot).
    This is exactly the problem. This isn't a tool that was developed outside in, but inside out. It isn't built on standard mechanism that has great flexibility to do anything, and widdles away at that to make things unusually simple. It did not take the 1 billion lines of code in one, "thing," and provide outs so that I can shorten it. Take shell scripting. I'm quite sure I can do file management in a shell script and do it effectively. If I find myself doing something repetitively or in a standard way, I can then delegate to an executable. If things don't work out, I can always fall back onto shell scripting. I know there are many types of shells, but this is just an illustration of that point. Maven2's antlib and ivy are great in that regard. If I don't like the way a library resolves, I can stuff it into a directory, and do mad and insane things. There are 2 ways that I can refer to jars on a filesystem, but sometimes, they aren't flexible enough, or wind up with more XML than I can shake a stick at. If anyone got convention and configuration mostly right, it's the spring framework people. I *can* use annotations, or autowiring, but if I don't want to, or can't, I can hold its hand and point a finger and exclaim, "No stupid. Do this."
  12. Re: That's the point[ Go to top ]

    In case you are not satisfied by Maven, do not hesitate to have a look (and help) at el4ant http://el4ant.sourceforge.net/ I consider as a flexible, white-box build system based on Ant. Ivy support is coming.
  13. I just tried maven 2.1 and was VERY impressed by how much faster the build is. I wiped out my ~/.m2/repository and rebuilt a large project and was very impressed by how fast it downloaded the dependencies. My team thinks that maven is the greatest thing to ever happen to Java and I personally can't wait to see what other improvements they've slipped in. Thank you and congratulations to the Maven team!
  14. Great[ Go to top ]

    I remember when I first heard about Maven: "WTF ? How could it be any better than Ant ?" Now, each time I come to a new project I just begin to Mavenize it. A great great tools, well designed. GC.
  15. Congrats to the Maven Team[ Go to top ]

    Parallel resolution of artifacts seems interesting