Discussions

News: Maven 2.0.5 Released

  1. Maven 2.0.5 Released (56 messages)

    The Apache Maven team has announced the release of Maven 2.0.5. As part of their announcement, they predict an easy upgrade path for those using the current version. Maven is a software project management and comprehension tool. Mavin's design is based on the concept of a project object model (POM). It allows one to manage a project's build, reporting and documentation from a central place. The team expects that those upgrading to this version should not encounter any difficulties. There have been 96 issues closed with this release. Also included is the capability to to insert license and legal notices into all artifacts to be distributed. In addition, Mavin releases will be placed in a staging repository where they will be released after an approval process. This release only includes the core. The release of upgraded plugins will occur over time. The plugins information list will be updated as these pluging are released. You can find more information on the Maven project web site as well as from the Maven user's mailing list and Mavin blogs.

    Threaded Messages (56)

  2. Re: Maven 2.0.5 Released[ Go to top ]

    Queue Hani with the obligatory comment disparaging the spastic f_ckwits responsible for the abomination that is Maven.
  3. Seems like 90%+ of the time I get a project from somewhere and its supposed to be as "easy" as "mvn clean run:jetty" or something like that, its not. Maven only seems to work if you mirror all the repositories locally and never delete any old or alternate versions, and if you have to do that, what's the point?
  4. Well, we've considered switching to Maven some 1/2 year ago... and sticked with Ant as didn't see a point in Maven's repos. IMO Maven is useless for most of the projects.
  5. Dependency resolution is of course only one feature of Maven. Even that works out quite nicely for us. We have numerous projects with various dependencies on each other. Maven's versioning and dependency resolution simplifies our development process.
  6. didn't see a point in Maven's repos. IMO Maven is useless for most of the projects.
    Do most projects have dependencies ? Yes ? so its useful then. How many times have you download a project and got yet another copy of log4j.jar? How many copies do you need ? The majority of developers utilise more than one piece of software and each has its own list of deps, and hence you get overlap. This is why there is a repo.
  7. We also have evaluated Maven, but have not adopted it. The reasons for it are multiple. Really bad and incomplete documentation, plugins behaving badly and no real common configuration for them, multimodule projects still are a nightmare (even in M2), maven tries to provide structure - which is good - but feels like a straitjacket. Futhermore development of Maven and plugins, as well as bugfixes take far too long. We decided to stick to ANT and Ivy, and have created a solid set of macros and scripting around it. We've also added the various reports and made sure they all look 'the same', these reports work whether in single or multi module and also for aggegrates. For us this works out really well and we like the control we have over this toolbox.
  8. Well, we've considered switching to Maven some 1/2 year ago... and sticked with Ant as didn't see a point in Maven's repos. IMO Maven is useless for most of the projects.
    We considered switching to Maven some 3 years ago.... we've stuck with Maven ever since as the whole tool including the repos is great. IMO Maven is excellent for most projects.
  9. Well, we've considered switching to Maven some 1/2 year ago... and sticked with Ant as didn't see a point in Maven's repos. IMO Maven is useless for most of the projects.
    Well where I am, it's being used by most projects. I think you should reviewing the features of Maven once more and try to grasp to the philosophy of the project. I've been using Maven since it's inception and I find it to bring more features and added value in comparaison to Ant. That being said, I'm not saying Ant is worthless, I'm just saying that you should reconsider Maven. a++ C├ędric
  10. Another vote in support. I was a massive Ant fan, and didn't see the need for Maven - but in an environment where we have 30-40 individual componentised sub-projects you really start to appreciate the standardisation on structure (and the functionality it gives you for free). Its also allowed us to fully componentize our system, by versioning discrete bits of functionality and then managing the dependencies between components - something that is just not practical using Ant
  11. I love Maven! I was a huge fan of ant, as well, and somewhat like other posters, I had multiple independant but correlated projects. It's one thing to use maven to acheive integration between your model, view, and services layers on one project. Worth it, of curse, but not by much. It's when you start using company wide libraries consistantly that the payoff really hit us. Now developers on other projects are less timid about pulling down already available code. It's inviting. Why not, after all, since all you have to do is declare a dependency (not manage, find, or maintain it. Just declare it.) Of course there is the beauty of not having to figure much out, of curse, to get going on a project. I'd use maven for it's archetypes and then generate an ant file, were I cornered with ant. Congrats on the new release! Joshua Long
  12. Seems like 94% of the time I get a project from somewhere as its support to be as "easy" as "mvn", it surprisingly is! Maven always seems to work and you can mirror your repositories locally for performance or if you need to work offline. you can even delete old or alternate versions when it's unlikely that projects with those dependencies will be needed again or you can keep them around because the point is that your various projects and their various branches may depend on different versions of the software.
  13. Seems like 90%+ of the time I get a project from somewhere and its supposed to be as "easy" as "mvn clean run:jetty" or something like that, its not. Maven only seems to work if you mirror all the repositories locally and never delete any old or alternate versions, and if you have to do that, what's the point?
    Try "mvn clean jetty:run" instead Easy!
  14. Perfect[ Go to top ]

    My experience has been quite the opposite. Maven helped us to achieve higher levels of software quality. Now, we have a common build process, we have a central component repository, we have a set of reports that gets automagically updated every time a build (automated) is created, etc. Ok, the reports could be generated by using each of the tools and by creating proper ant scripts, but using Maven is so much easier...
  15. Elmira givz +3.14[ Go to top ]

    My experience has been quite the opposite. Maven helped us to achieve higher levels of software quality. Now, we have a common build process, we have a central component repository, we have a set of reports that gets automagically updated every time a build (automated) is created, etc. Ok, the reports could be generated by using each of the tools and by creating proper ant scripts, but using Maven is so much easier...
    Yessum - tiz troo! +3.14
  16. Can only agree[ Go to top ]

    using some of the report myself availably at : http://edemocrazy.sourceforge.net/project-reports.html To bad yDoc isn't open source since it's extends the javadoc with uml diagrams. Good way of getting automated documentation of the code.
  17. Re: Perfect[ Go to top ]

    Agreed. Maven lets me focus on writing software and not the build. For those who had bad experiences early on with Maven 2, let me say: try it again. Some of the early releases where a little rough. I too a lot of time cursing Maven at one point. But its quite solid now and no longer gets in the way of your software development.
  18. Re: Perfect[ Go to top ]

    Agreed. Maven lets me focus on writing software and not the build.
    Come on Dan, you don't fool us, when have you ever written any software? I thought your stuff was just a SOAP stack and everything wrote itself through web services, I must have missed the point. :-) On a more serious note I've not moved to T+0.0.5 but I will, I like Maven, it has it strangeness but it does provide an excellent base for projects. -John-
  19. POM reader[ Go to top ]

    My experience has been quite the opposite. Maven helped us to achieve higher levels of software quality. Now, we have a common build process, we have a central component repository, we have a set of reports that gets automagically updated every time a build (automated) is created, etc. Ok, the reports could be generated by using each of the tools and by creating proper ant scripts, but using Maven is so much easier...
    I don't miss Ant. Productivity and reuse is so much higher with Maven2. One may have a slight learning curve and need to refactor projects into maven dir structure but it is so worth it.
  20. maven2 is useful ..[ Go to top ]

    Maybe not for all projects, but for most that I work on it's a huge help. Esp. with Tapestry. Think 1 1/2 hours of miserable pain doing a release vs. about 5 minutes...
  21. Re: POM reader[ Go to top ]

    I don't miss Ant.
    Nice as Ant by itself is, I certainly do not miss having to figure out exotic build scripts every time I want to check out an open source project now that many of them use maven.
  22. IVY: dependency management for ant[ Go to top ]

    If you are happy with ant and just would like to get some dependency management: Try Ivy: http://incubator.apache.org/ivy/ (it can use maven repos too)
  23. Agree[ Go to top ]

    Ivy is what maven is not and should be. I tried to use maven2 for a past project: it was a nightmare! Now we are returned to use Ant, it is more productive than maven. Here my disappointment about maven: - Maven repository is not so easy to use and manage; An old library is still in use or not? Maven is not easily and well done as .rpms! - Maven compilation is too slow even if I have all the libraries in local; The same project compiled with Ant is very very faster! - Some boring bugs encountered that are too hard to work-around; In particular in the deployment steps (assembly:assembly, many problems with it!). - No tool to easily install locally some jars; How can I install in my repository all Hibernate 3.2.2 libraries in 10 minutes (if it is not still present in the ibiblio repo)? With a colleague of mines we developed a GUI to easily examine and install jars with the correct artifact , name and the version.... that's ok, but without this little GUI application, maven is not usable for me (and my colleague!)! Why there is not an easily application to install new complex libraries? For example, suppose you have a proprietary library "Alfa", of the foo.com company, Alfa is in version 1.2.3, and is composed by over 20 different jars, free and not. Ok, how can I install Alfa in my own repository in 10 minutes? No way with apache maven...... Without our little and simple application it is impossible!; - Why log4j and many Apache SW (like Apache Commons) are stored as (Artifact,Name) = (log4j,logj4) (Artifact = name library, Name = name library)? And not as:(org.apache, log4j)? I mean, why the artifact of log4j is "log4j" and not (I think more logical) something like: "org.apache"? Another example: asm: why asm is stored as "asm - asm"? And not something as "org.objectweb - asm" ? In this way, I have in my repository, at the first level, a hell of directories! It should be rethinked... In conclusion, now I use Ant, with and without Ivy , it depends of the project. Maven is a lost opportunity to make a good and universal make-process for large java projects. Bye. Michele
  24. Re: Agree[ Go to top ]

    How can I install in my repository all Hibernate 3.2.2 libraries in 10 minutes (if it is not still present in the ibiblio repo)?
    The Hibernate 3.2.2.ga download posted on hibernate.org on 1/24/2007 and on ibiblio.org/maven2/org/hibernate on 2/8/2007. Since hibernate doesn't use maven to build you don't get the benefit of SNAPSHOT builds. Some lag time but not much. I don't think maven is for you if you are working with alpha/beta library code. Again, SNAPSHOTs make it supremely easy to work with pre-GA but your dependencies need to be using maven. Codehaus is good about exposing SNAPSHOTS. Also I use Jetty for development and I point to it's SNAPSHOT.
  25. Re: Agree[ Go to top ]



    The Hibernate 3.2.2.ga download posted on hibernate.org on 1/24/2007 and on ibiblio.org/maven2/org/hibernate on 2/8/2007. Since hibernate doesn't use maven to build you don't get the benefit of SNAPSHOT builds. Some lag time but not much. I don't think maven is for you if you are working with alpha/beta library code.
    My example of the "Alpha" project was not intended as "alfa/beta" software, I was only trying to expose a problem with Maven: how can I install in my repo a "private" software (not public, not Open Source) in 10 minutes? It is extremely difficult to do that. One of the most important missing features of maven is the way to install a library in a simple and quickly way. Some months ago I wrote my code using the 3.0.0 version of Hibernate, but in the ibiblio there was still a beta version, thus I was obliged to write an "installer" that helped me to install hibernate in my repository in 10 minutes guessing the jars' name. Moreover I was working with Oracle: Oracle drivers, Oracle BPEL jars, Oracle TopLink, that are not in ibiblio! How maven can help me in this case? I think you should be able to use maven even if you are using code not built in the same fashion. Finally, I think the maven idea is very good, Convention-over-Configuration idea is very good, maven standardization of the source tree, is very good. But the implementation is not so good! Bye. Michele
  26. I was only trying to expose a problem with Maven: how can I install in my repo a "private" software (not public, not Open Source) in 10 minutes?
    mkdir -p $MAVEN_REPO/project/jars cp myjar.jar $MAVEN_REPO/project/jars/ My that took all of .... ermmmm 10 secs typing. Hell it would take you longer to do it in an Ant script and test your script. Use of license-restricted jars is fine when you have a local repo in your company. You install them once and thats it. Not that hard. Just trying to find an excuse not to use Maven ? If you dont want to use it dont. You dont need to justify yourself to us, but please dont invent reasons. It's easy to be negative about products, we can all do that.
  27. Have you never heard of the magical commands? install:install-file or deploy:deploy-file which take less than 5 minutes to deploy any jar. I will agree that it's can be painful when you have to deploy LOT of proprietary libraries with interdependencies but it's an operation you only have to do one time and it's really worth it IMO.
  28. Guys, I think I'm not negative over products like maven. I did not understand why I have to justify myself... I introduced Maven2 in the company where I work ("Ehi Mike, what is Maven? A rock band?"). I spent many words (and many emails) with my boss about the benefit of maven. We built an internal networked repository that works well! We developed a program to populate our repository using maven-embedder and maven-cli (much better than scripts or mkdir!). Moreover we encountered some bugs that were difficult to work-around and some behavior we did not agree. IMO maven idea is not good but excellent! but the product has some drawbacks that are important for me; I hope next maven versions will improve the product. I think Ivy is better because does the same things in a simpler way. That's all! Bye! Michele
  29. install jar in local repository[ Go to top ]

    command to upload a jar to local rep: mvn install:install-file -Dfile=lib\myJar.jar -DgroupId=myJar -DartifactId=myJar-no-joda -Dversion=1.0 -Dpackaging=jar you can create a script if to install multiple jars
  30. Tips for using your own jar files[ Go to top ]

    This is one of my pom.xml dependencies: lowagie lowagie 1 system ${basedir}/src/main/webapp/WEB-INF/lib/lowagie.jar Note that I can't find lowagie.jar in any maven repos published on the web. I download lowagie.jar from private place and copied it to my local webapp of project: ${basedir}/src/main/webapp/WEB-INF/lib/lowagie.jar I think you can do with your toplink jar files. Okay?
  31. Broken links[ Go to top ]

    The first two links don't seam to be working.
  32. Proper links this time[ Go to top ]

    Full Release Notes Maven Blogs the maven-user mailing list
  33. Links fixed[ Go to top ]

    The Maven links in the original post have been fixed. Nitin
  34. After installing Maven 2.0.5, the zip file extracts to maven-2.0.5 directory; 'mvn --version' displays 2.0.4 instead of 2.0.5. Is this a known bug ? or I installed a incorrect zip file ? Thanks P. Belathur
  35. Mine says: D:\>mvn -version Maven version: 2.0.5 I guess you have and old v. lurking in your PATH somewhere.
  36. What about continuum and archiva?[ Go to top ]

    The documentation on Maven continuously references both of these projects. Continuum is really nice when used in conjunction with Maven2. In fact, I'd go so far as to say it's awesome. But there are defects and it doesn't seem to be actively worked on. Archiva is basically non-existent. There's a beta release, but it's really buggy, the documentation is poor and also seems to be not actively worked on. Maven is generally a really decent tool. The web site upgrade was promising, but I find it much harder to find information there now than it used to be. I fear that since Maven devs went corporate they've all disappeared or are busy doing custom work for clients and have left the project to flounder.
  37. I can speak for myself in that I have definitely not gone corporate. As the founder of Maven I indeed helped to found Mergere but I no longer work there. I personally feel I can do better work outside the context of Mergere. There are still some very committed Maven folks at Mergere but it's simply not the way I work. Since leaving I've been trying to get people more involved with things like the Maven sandbox, getting more people involved in Mojo project (a sister project at Codehaus), making the integration testing better, working on projects like Maven Enterprise and finally working toward the 2.0.5 release. Continuum is actually quite decent and the devs are trying to get 1.1. out. But Archiva is not beta, it's barely alpha and is under going some serious refactoring and is not ready for prime time use. I have removed the verbiage on the Maven home page that makes it look like it is. I plan to do something involving Maven in the near future but it will certainly be on a smaller scale and self-sustaining.
  38. WTP and Maven[ Go to top ]

    The only thing that is holding most of our projects from migrating to maven 2 is we rely heavily on WTP for eclipse, and the current codehaus maven plugin doesn't support the WTP server plugin / WEB-INF/lib publishing ability.
  39. Re: WTP and Maven[ Go to top ]

    The only thing that is holding most of our projects from migrating to maven 2 is we rely heavily on WTP for eclipse, and the current codehaus maven plugin doesn't support the WTP server plugin / WEB-INF/lib publishing ability.
    Use this: http://blogs.unixage.com/blojsom/blog/adam.kruszewski/eclipse/2006/05/02/Maven2-Eclipse-plugin-with-latest-WTP-from-callisto-update-site.html It may help you.
  40. maven love and hate[ Go to top ]

    Since I had to use maven at a previous job, I have to say that maven blows for anything remotely complex. If a project is simple and you don't have to worry about lost of releases, and doing all sorts of QA testing, then it's probably ok. I love to hate maven because unlike other repositories, maven repo blows and only works in the simplest cases. It's possible to make maven work for complex cases, but the over head becomes a full time job. The cost of maven gets to the point where the entire development team has to rely on the build guy to make sure it all works. If it doesn't everyone becomes unproductive. Apache has produced some good software, but maven isn't one of them. my really bias 2 bits peter
  41. Re: maven love and hate[ Go to top ]

    Since I had to use maven at a previous job, I have to say that maven blows for anything remotely complex. If a project is simple and you don't have to worry about lost of releases, and doing all sorts of QA testing, then it's probably ok.

    I love to hate maven because unlike other repositories, maven repo blows and only works in the simplest cases. It's possible to make maven work for complex cases, but the over head becomes a full time job. The cost of maven gets to the point where the entire development team has to rely on the build guy to make sure it all works. If it doesn't everyone becomes unproductive. Apache has produced some good software, but maven isn't one of them. my really bias 2 bits

    peter
    Son, yuh needs tuh move on and find a new kareer - maven 2 (a.k.a. mvn) is so dang easy even Ize kin yooz it tuh make and manage complex builds. Mah guess iz yooz one of them folks thats don't read thuh manual fer anythin - just start pressin buttons and seez whut happens - so fiddlesticks on yoo! You waskal, you!
  42. Re: maven love and hate[ Go to top ]

    Since I had to use maven at a previous job, I have to say that maven blows for anything remotely complex. If a project is simple and you don't have to worry about lost of releases, and doing all sorts of QA testing, then it's probably ok. I love to hate maven because unlike other repositories, maven repo blows and only works in the simplest cases. It's possible to make maven work for complex cases, but the over head becomes a full time job. The cost of maven gets to the point where the entire development team has to rely on the build guy to make sure it all works. If it doesn't everyone becomes unproductive. Apache has produced some good software, but maven isn't one of them. my really bias 2 bits peter
    Son, yuh needs tuh move on and find a new kareer - maven 2 (a.k.a. mvn) is so dang easy even Ize kin yooz it tuh make and manage complex builds. Mah guess iz yooz one of them folks thats don't read thuh manual fer anythin - just start pressin buttons and seez whut happens - so fiddlesticks on yoo! You waskal, you!
    LOL, if only it was a simple as that. I inherited a complex deployment and build that used maven. I won't bother going to all the details about how and why it was complex. I'd sooner forget the ugly mess that it was. Since the entire build, deploy and test process used maven plugins with Websphere, it was a nightmare. To be "slightly" fair, when we used jboss, it was pretty easy. With websphere, it became a horrendous nightmare. consider this, what happens if the applications you test change rapidly, and the developers are around the world? Often you won't get notified of changes, nor will you know what changed until the build explodes. better yet, there are so many changes every day that it takes 4-5 hours to review all the changes. So yeah, maven can work for tiny and simple projects, but not anything remotely complex. Linux repositories for the most part work great. maven's biggest headache and weakness is the repository. It's probably bad form to criticize maven, since I'm an apache committer. don't get me wrong, maven does do some nice things and it can make life easier with webapps. with websphere and complex ejb's, I think it ends up being a far bigger overhead than necessary. maven isn't really horrible, but I just can't resist making fun of it. peter
  43. Re: maven love and hate[ Go to top ]

    My experience with Maven 2 has been lightyears ahead of Maven 1. However, I'd still say you need to start with a clean sheet. You can't have a complex build and move to Maven all in one go. Maybe Merge can, but no one on the outside should even think about it! I started using Maven 2 on some secondary projects, outside of Apache, to learn the ropes, especially with respect to multi-project. then I started Tapestry 5 with a fresh code base, organized Maven-style. I still, to this day, have to do a lot of experimenting 80% of the time, Maven is a godsend. 20% of the time, it feels like you are appeasing a petty god. Or as Dilbert puts it (http://dilbert.com/comics/dilbert/archive/dilbert-20070215.html), like "fifteen drunken monkees with a jigsaw puzzle". But the benefits are also pretty large once things are working and stable. I was able to set up continuous integration for Tapestry literally in a few minutes (a tribute to both Maven and Bamboo). Other people can build Tapestry straight from SVN no problem, which was never possible with any iteration of my home-grown Ant scripts. It also provides a uniform and useable generated site. The wiki-ish APT format for documentation lets you focus on content not markup, so I've generated much more documentation that way than I did with, say, Forrest's XDOC format. Bad side: someone releases a new version of a plugin somewhere that breaks your build and you have to experiment to find a working version (usually with a number like 0.97-alpha-3-SNAPSHOT). Finally, even with multi-project and POM inheritance, Maven requires a huge amount of repetition. POMs are very, very verbose and repetative. My wife asked me, "so if Maven is like that why do you use it?" A large part of the answer is the network effect. The other reason is a riff on the Winston Churchill quote ("It has been said that democracy is the worst form of government except all the others that have been tried.") ... Maven is the ugliest, wierdest, most confusing, most under documented, most XML heavy, most frustrating build system out there and is still better than the alternatives. For Java.
  44. Re: maven love and hate[ Go to top ]

    @Peter lin Looks like you got the 2 worst part in javaland: - Maven - WebSphere in the same project - ugh
  45. Re: maven love and hate[ Go to top ]

    @Peter lin

    Looks like you got the 2 worst part in javaland:
    - Maven
    - WebSphere
    in the same project - ugh
    And I guess in 1-2 years time as Maven get more mainstream and mature I'll start to appreciate it more and more. Currently coming from ant where you are in control to Maven is very frustrating when something breaks in Maven. WebSphere on the other hand is still ...... to work with as a developer.
  46. Re: maven love and hate[ Go to top ]



    Currently coming from ant where you are in control to Maven is very frustrating when something breaks in Maven.

    ......
    +1
  47. Re: maven love and hate[ Go to top ]

    Since I had to use maven at a previous job, I have to say that maven blows for anything remotely complex. If a project is simple and you don't have to worry about lost of releases, and doing all sorts of QA testing, then it's probably ok.

    I love to hate maven because unlike other repositories, maven repo blows and only works in the simplest cases. It's possible to make maven work for complex cases, but the over head becomes a full time job. The cost of maven gets to the point where the entire development team has to rely on the build guy to make sure it all works. If it doesn't everyone becomes unproductive. Apache has produced some good software, but maven isn't one of them. my really bias 2 bits

    peter


    Son, yuh needs tuh move on and find a new kareer - maven 2 (a.k.a. mvn) is so dang easy even Ize kin yooz it tuh make and manage complex builds. Mah guess iz yooz one of them folks thats don't read thuh manual fer anythin - just start pressin buttons and seez whut happens - so fiddlesticks on yoo!

    You waskal, you!


    LOL, if only it was a simple as that. I inherited a complex deployment and build that used maven. I won't bother going to all the details about how and why it was complex. I'd sooner forget the ugly mess that it was. Since the entire build, deploy and test process used maven plugins with Websphere, it was a nightmare. To be "slightly" fair, when we used jboss, it was pretty easy. With websphere, it became a horrendous nightmare.

    consider this, what happens if the applications you test change rapidly, and the developers are around the world? Often you won't get notified of changes, nor will you know what changed until the build explodes. better yet, there are so many changes every day that it takes 4-5 hours to review all the changes. So yeah, maven can work for tiny and simple projects, but not anything remotely complex.

    Linux repositories for the most part work great. maven's biggest headache and weakness is the repository. It's probably bad form to criticize maven, since I'm an apache committer. don't get me wrong, maven does do some nice things and it can make life easier with webapps. with websphere and complex ejb's, I think it ends up being a far bigger overhead than necessary. maven isn't really horrible, but I just can't resist making fun of it.

    peter
    In our environment we've gotten around this by using Continuum alongside Maven...doing hourly builds Jeff
  48. Re: maven love and hate[ Go to top ]

    Interesting. In my experience, maven was a blessing for our projects. Before using maven2, our organization was simply unable to embrace 'plugin/component' style of development. That is, whatever you create, build it in a such a way that can be reused in other projects. And why's that ? Because with Ant everyone was reinventing the wheel with their own scripts (you know the mentallity .. I can do it better) and each project was structured differently, had different build&deploy scripts and maintanance was living hell. With few projects you can get away with ant, but when you have many projects which produce libraries/applications that are used interchangeably on many client's sites, maven2 is the only way to go to keep you sane.
  49. Re: Maven 2.0.5 Released[ Go to top ]

    I recently went through the exercise of migrating a number of applications from ANT to Maven. All of these applications were developed independently but are now maintained by one team. Maven strongly encourages consistency across projects. In every project the Java code is in the same directory, so are the JSPs, HTML files, property files, etc. It makes navigating projects a breeze since one you are familiar with the structure of one project you are familiar with all of them. The build process is also standard. With ANT the targets to run are dependent on what the developer creating the script decided it would be called. With Maven it pretty much is "mvn install" across the board. In addition to standardizing directory structure and the build process, Maven's dependency resolution is awesome. No more hunting down dependencies around the web, or having multiple copies of a dependency like a poster above said. I was very surprised to see negative comments about Maven on this thread. I thing Maven is light years ahead of ANT.
  50. Re: Maven 2.0.5 Released[ Go to top ]

    I was very surprised to see negative comments about Maven on this thread. I thing Maven is light years ahead of ANT.
    I know I'll get feedback like: "Why are you reinventing the wheel?", but I'm going to take my chances. Consistency across projects has only so much to with Maven. A similar effect can be achieved by creating an ANT reusable set of macros and scripting around it. We also can use "ant Install", in this case kicking off an ANT macro that figures out what to build, in what order and where to store it. In the process it uses Ivy for library and project dependencies. Convention-over-Configuration and sensible defaults is a good idea but it's not only possible in Maven. I've already commented as to why we didn't adopt Maven, but obviously the ideas behind it are sound. I just don't like the "execution" part of them.
  51. Re: Maven 2.0.5 Released[ Go to top ]

    Did somebody say ant macros ? I'm gonna call B.S. on this one. Most macros do very little good when you have to use them very often or have too many of them to build a coherent picture of your system. Witness the macro approach we used before maven : http://svn.apache.org/viewvc/hivemind/hivemind1/branches/branch-1-1/hivebuild/ vs. The maven2 approach: http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/pom.xml?view=markup
    I was very surprised to see negative comments about Maven on this thread. I thing Maven is light years ahead of ANT.


    I know I'll get feedback like: "Why are you reinventing the wheel?", but I'm going to take my chances. Consistency across projects has only so much to with Maven. A similar effect can be achieved by creating an ANT reusable set of macros and scripting around it. We also can use "ant Install", in this case kicking off an ANT macro that figures out what to build, in what order and where to store it. In the process it uses Ivy for library and project dependencies.

    Convention-over-Configuration and sensible defaults is a good idea but it's not only possible in Maven. I've already commented as to why we didn't adopt Maven, but obviously the ideas behind it are sound. I just don't like the "execution" part of them.
  52. Re: Maven 2.0.5 Released[ Go to top ]

    Did somebody say ant macros ? I'm gonna call B.S. on this one. Most macros do very little good when you have to use them very often or have too many of them to build a coherent picture of your system.

    Witness the macro approach we used before maven :

    http://svn.apache.org/viewvc/hivemind/hivemind1/branches/branch-1-1/hivebuild/

    vs. The maven2 approach:

    http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/pom.xml?view=markup
    Yup you've created a mess before using ANT, that much can be told from browsing subversion ;-) However this is nowhere near as structured and clean as the ANT/Ivy build system we've setup. We have only one super ANT file, containing the macro's we need. Each project gets its own build.xml, inheriting from the super ANT file and providing some build "hooks" that are called from from the "main" targets. Most of the time, these hooks don't need to be "implemented" as the default behavior of the super ANT is good enough.
  53. Shocking...[ Go to top ]

    As part of their announcement, they predict an easy upgrade path for those using the current version.
    One may like Maven or not (I am not a big fan), but a sentence like this gives me the creeps. Mate: Upgrading from 2.0.4 to 2.0.5 (maintenance version number!) should take exactly zero effort!
  54. development under maven[ Go to top ]

    I must say that as a developer I have come to know maven as a factor that will at times seriously hamper my day to day work (which takes place inside eclipse). I appreciate the concepts behind maven (componentization, versioned dependencies, atomatic retrieval), but as most IDEs have their own concept of projects and dependencies, conflicts will arise, and if the integration (e.g. eclipse maven plugin) is not perfect, you pay a high price over time. That needs to be considered and evaluated IMO. I have to mention that our project consists of roughly a dozen projects, with POM inheritance and all
  55. Re: development under maven[ Go to top ]

    It's interesting to hear about problems with Websphere or Eclipse not working well with maven. I would call it a development smell to rely on a GUI tool or proprietary package to do something that should be executed at the command line or according to the JEE spec. WSAD is nice but why get sucked into its dependency vortex.
  56. Re: development under maven[ Go to top ]

    It's interesting to hear about problems with Websphere or Eclipse not working well with maven. I would call it a development smell to rely on a GUI tool or proprietary package to do something that should be executed at the command line or according to the JEE spec. WSAD is nice but why get sucked into its dependency vortex.
    It's not about packaging but generating a valid IDE project. I agree with him, this is the most difficult aspect of Maven when you don't use Vanilla Eclipse.
  57. Re: development under maven[ Go to top ]

    I would call it a development smell to rely on a GUI tool or proprietary package to do something that should be executed at the command line or according to the JEE spec.
    hmm, lets accept that everyone has their own preferences with regard to smell. I personally am not willing to discuss the usefulness of modern-day IDEs. Reminds me of the guy that told me a while ago that graphical debuggers were uncool, and real developers would stick with printf. In the end its all about productivity, I think thats the point where we should all meet. Also, I am not aware that the JEE spec requires functions to be executed at the command line.