Maven getting closer to a 1.0 release?

Discussions

News: Maven getting closer to a 1.0 release?

  1. Maven getting closer to a 1.0 release? (43 messages)

    Maven, the Java project management and project comprehension tool, seems to be getting dangerously close to a full 1.0 release. After many beta releases, the Maven team has announced a Release Candidate. Hopefully this milestone shows that, after a few more bug fixes, we will see that final release that many people have been longing for.

    Maven's Goals

    Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with:

    - Making the build process easy
    - Providing a uniform build system
    - Providing quality project information
    - Providing clear development process guidelines
    - Providing guidelines for thorough testing practices
    - Providing coherent visualization of project information
    - Allowing transparent migration to new features

    Read Maven's features

    Download Maven Releases

    Go to the Maven Home Page

    How many of you are using Maven now? Waiting for Maven 1.0?

    Threaded Messages (43)

  2. At last![ Go to top ]

    Good news, almost as exciting as J2SE 1.5. :-)

    -John-
    C24
  3. Still has a long way to go[ Go to top ]

    Even though there are a lot of features in Maven, it still has a long way to go. Unfortunately, I think the Maven team has concentrated a little too much on creating a project that centers around a specific build process, mainly the project and directory structure of an open source project. To use Maven as a build tool in a corporate environment, you have to do a lot of custom configuration using a lot of undocumented features in property files and abstract plugin documentation. You also have to create a lot of custom Jelly scripts which take as much time to create as Ant scripts. Don't get me wrong, I believe that Maven will eventually overshadow Ant as the de facto build tool for Java and it addresses some holes left by Ant. I can tell by some of the discussion on the Maven list that the team is moving in the right direction towards addressing these needs. But I have serious doubts about whether or not the 1.0 release will be a product that is complete enough to start replacing Ant for projects that are not in single project environments.
  4. Undocumented properties?[ Go to top ]

    Can you tell me which properties you found that were undocumented?

    I'd like to clean those up.
  5. Ugh[ Go to top ]

    As many many people have found out, maven is an absolutely abysmal tool. I myself (and I know of others too) who will actively avoid or work around projects that use maven that disallow using standalone ant.

    The websites it spits out are eyesores, full of irrelevant information and not-so-subtle links back to maven's website. It's somewhat horrific that people STILL insist on using such a fundamentally flawed tool, despite the huge plethora of failings it boasts.
  6. well...[ Go to top ]

    Hani,

    i think this is simply evolution. if a project like this is fit for the real world, it will survive, otherwise it will become irrelevant.

    It's a bit trial and error. Personally, i am glad that there are creative people out there, willing to try and to err, i.e. to explore new or slighty different concepts of doing things.

    cheers
    joe
  7. And...[ Go to top ]

    Well, to say 'ugh' goes a bit too far I think ;-).

    Offering insight in a codebase and a project by test coverage reports, checking source for style errors is fine with me, as long as it's not goal an sich (to put it in German).

    I've been using Maven for one project, and it was quite a big one. I took the decision to try and use it, and afterwards I wasn't happy about it! To put it short: it slowed us down. All this was half a year ago and I haven't really seen improvement so far.

    But I agree, if this project is fit for the real world - including the commercial development world - it will survive.

    Until then, I'll use my own build system...

    Alef
  8. Exactly...[ Go to top ]

    As many many people have found out,

    > maven is an absolutely abysmal tool. I
    > myself (and I know of others too) who will actively avoid or work around
    > projects that use maven that disallow using standalone ant.
    >

    I absolutely agree. Maven is one of the best productivity-brake-suites
    I have ever seen. I haven't looked for a long time, but it when I looked
    it had the following top notch characterics that made me reconsider:

    - Jelly scripting language - if i want to mess with learning yet another scripting language i might use make in the first place.

    - Imposed directory structure - i want the tool to support whatever directory structure i choose rather than impose one on me.

    - Incredible stupid ideas - For example, the whole idea of fetching latest library versions your code depends on from the internet is one of the most idiotic ideas I have ever encountered. Sure it sounds good, unfortunately it will never ever work, especially if you rebuild in six month time and the code has moved or it has changed its interface altogether.

    - Hard to understand - that's not a problem, I am willing to learn. Unfortunately, once understood, it turned out to be hard to extent as well.

    I turned back to ant immediately.
  9. Exactly...[ Go to top ]

    - Imposed directory structure - i want the tool to support whatever directory structure i choose rather than impose one on me.


    Can't you define your own structure? I know if comes out of the box with some directory assumptions, but I think you can control these.

    > - Incredible stupid ideas - For example, the whole idea of fetching latest library versions your code depends on from the internet is one of the most idiotic ideas I have ever encountered. Sure it sounds good, unfortunately it will never ever work, especially if you rebuild in six month time and the code has moved or it has changed its interface altogether.

    Not sure I understand what you mean here. What code moves? What code changes interface? Your code our the code you depend on?
  10. Exactly...[ Go to top ]

    Maven is one of the best productivity-brake-suites

    > I have ever seen. I haven't looked for a long time, but it when I looked
    > it had the following top notch characterics that made me reconsider:
    >
    > - Jelly scripting language - if i want to mess with learning yet another scripting language i might use make in the first place.
    >

    For most cases you never have to write any custom jelly script at all.
     
    > - Imposed directory structure - i want the tool to support whatever directory structure i choose rather than impose one on me.
    >

    Actually there is no restriction from Maven. You can choose whatever directory structure whereever...
    However it helps from a J2EE perspective to have them in a directory-subdirectory format. It simplifies the scripts by using the Maven "reactor".
    After all, the artifacts in a EAR have a hierarchy and dependency too.


    > - Incredible stupid ideas - For example, the whole idea of fetching latest library versions your code depends on from the internet is one of the most idiotic ideas I have ever encountered. Sure it sounds good, unfortunately it will never ever work, especially if you rebuild in six month time and the code has moved or it has changed its interface altogether.
    >

    That shows how much have you tried Maven out.
    The "whole idea" of fetching libraries from the net is the default behavior and has to be overridden with remote or local repositories. Create your repository, set the version depedency and do the continous integration. Its that simple.


    I dont understand why people complain so much about Maven. Sure it was a bit tough to learn but it has been smooth sailing for me ever since.

    Cheers,
    Srikanth
  11. Exactly...[ Go to top ]

    - Incredible stupid ideas - For example, the whole idea of fetching latest library versions your code depends on from the internet is one of the most idiotic ideas I have ever encountered. Sure it sounds good, unfortunately it will never ever work, especially if you rebuild in six month time and the code has moved or it has changed its interface altogether.

    > >
    >
    > That shows how much have you tried Maven out.
    > The "whole idea" of fetching libraries from the net is the default behavior and has to be overridden with remote or local repositories. Create your repository, set the version depedency and do the continous integration. Its that simple.

    I think it was about "SNAPSHOT", looks like maven ignores local repository for some of jars and sometimes maven breaks itself after download, but I am not sure about all beta versions and I can't tell the "bad" version (I need to use a few maven versions as workaround for broken features in "beta x"). I have found workarounds for all my problems, but I am afraid to download a new version :)

    >
    >
    > I dont understand why people complain so much about Maven. Sure it was a bit tough to learn but it has been smooth sailing for me ever since.
    >
    > Cheers,
    > Srikanth
  12. Not![ Go to top ]

    Jelly scripting language - if i want to mess with learning yet another

    > scripting language i might use make in the first place.

    Like Ant when it first came out?

    > Imposed directory structure - i want the tool to support whatever directory
    > structure i choose rather than impose one on me.
    Almost all the directory structure can be overridden with property settings.

    > Incredible stupid ideas - For example, the whole idea of fetching latest
    > library versions your code depends on from the internet is one of the most
    > idiotic ideas I have ever encountered. Sure it sounds good, unfortunately it

    If you are willing to depend on a 'SNAPSHOT' of a library, that's your call as a user of Maven. It certainly doesn't force you to do it. We actively discourage it even.

    > Hard to understand - that's not a problem, I am willing to learn.
    > Unfortunately, once understood, it turned out to be hard to extent as well.

    Hard to extend? How hard is it to Write your own plugin ?

    > I turned back to ant immediately.
  13. Hi Hani

    I agree on some of your critic, but I think that you are being way to harsh. Not every developer is smart enough or have enough experience to structure their project properly using ant. Dealing with inter-project dependencies is a bitch if you are a freshman developer. The complexity of the projects at the company I work at increased markedly during the last year as more complex integration solutions where deployed. A given project can have several dependencies to other projects causing no end to the horrors of deploying and maintaining the end result.

    Sure everything can be done in ant, but just as test-driven development requires a high level of knowledge, discipline and willingness to change your habits properly written build scripts using ant for complex systems is a art. Maven is a good compromise between incompetent developers and highly skilled and experienced developers as your self.

    Living in the "real" world, having to deal with everything from a re-educated truck driver to the hotshot java developer I think that Maven has its place in most organisations that need a bit of structure in their codebase as well as proper management of dependencies. I know our organisation does.

    And yes the standard web site sucks, but hey nobody forces you to use it :)

    Christian
  14. And yes the standard web site sucks, but hey nobody forces you to use it


     Isn't it especially ironic that Bile Boy Hani complains about Maven's plain-vanilla look while at the same time using a plain-vanilla look for his Bile Blog.

      Hani, why not add a touch of personality to your Blog universe and practice what you preach, hypocrite?

      - Gerald
  15. Repetition?[ Go to top ]

    I looked at Maven quite a long time ago as a means of generating documentation for a project I was working on (Javadoc, developer list, dependancies etc), but I couldn't understand why the Apache group were creating a rival to Ant rather than adding project management features to it, i.e. a suite of additional tasks specifically aimed at maintaining the project.

    It disappoints me to see that they are willing to waste resource like this rather than simply extending *the* most used tool in the Java world after Javac!
  16. Repetition?[ Go to top ]

    <quote>
    but I couldn't understand why the Apache group were creating a rival to Ant rather than adding project management features to it, i.e. a suite of additional tasks specifically aimed at maintaining the project.
    </quote>

    Agree with you. You can add additional Ant tasks to do what Maven offers you sofar.

    Lofi.
  17. Repetition[ Go to top ]

    Show me how to do a generic postGoal on an ant target as can be done with Maven.
    Now make it generic and accessible for the average user.
  18. Maven and Ant[ Go to top ]

    I tried Maven (after having some discussions with a Maven's developer in TSS)... It looks promising but surely not for beginners... There are a lot of stuffs to configure before you can run it for the first time.

    I think, Maven forgets the KISS principle. Ant is much more easier to use. I prefer to have a collection of Ant templates:

    Build:
    build-javadoc.xml: for building JavaDoc
    build-jdepend.xml: to see the dependencies
    build-format.xml: to code-formatted the whole src codes
    etc...

    Execution:
    start-jonas.xml: run JOnAS EJB container
    start-junit.xml: run JUnit user interface
    etc...

    If you are using NetBeans, the integration with Ant is marvelous! Mount your directory, go to the ant script you want to run, press F6, that's it! Eclipse 2.x only supports !one! Ant session and this is not good (if you need to run many Ant scripts on the same time). I think in Eclipse 3.x they support more than one session.

    And don't forget, what you can do with Maven, can also be done easily with Ant ;-)

    Regards,
    Lofi.
    http://sourceforge.net/projects/ejosa
    http://sourceforge.net/projects/openuss
  19. I tried Maven (after having some discussions with a Maven's developer in TSS)... It looks promising but surely not for beginners... There are a lot of stuffs to configure before you can run it for the first time.

    >

    The main problem with Maven today is the lack of documentation which makes it harder to figure out how to set up a project. Had there been enough documentation and sample code, nobody would be complaining.

    There was a presentation from Vincent Massol at the Serverside symposium and the ppt and a sample project was available. Search google with the right key words and you are bound to find it.
    Once you get the sample, there will be no looking back.

    > I think, Maven forgets the KISS principle. Ant is much more easier to use. I prefer to have a collection of Ant templates:
    >

    Maven follows the KISS principle. It may sound strange for readers on this forum, but the fact that it enforces one project, one artifact which makes the build scripts simple.

    If you compare Ant to C, then Maven is like Java.
    Sure people began by complaining about the lack of power in Java visa vis C, lack of pointers, access to devices, restricted sandbox etc. but things settled down eventually. I think people will realize Maven's value soon. By forcing you to build in certain way, Maven brings simplicity and maintainability to the scripts. Sure Ant give you enormous power, but at a cost.

    Ant makes you think in terms of files, copying files . Maven thinks in terms of repositories, artifacts with the right version etc...

    Bottomline : Small projects WILL NOT realize any value out of Ant. (It is much like writing a elaborate custom framework for a project to be delivered in 3 months) It is too much of overhead. However there is a lot of ROI for medium to large projects (or long running ones)...
    Different courses, Different horses Thats the moral of the story

    I have been working on a J2EE project that has been running for more than three years and I wish Maven was there when I started on this project.


    >
    > If you are using NetBeans, the integration with Ant is marvelous! Mount your directory, go to the ant script you want to run, press F6, that's it! Eclipse 2.x only supports !one! Ant session and this is not good (if you need to run many Ant scripts on the same time). I think in Eclipse 3.x they support more than one session.

    It is a matter of time, when the IDEs will support Maven. Until then

    Cheers,
    Srikanth

    >
    > And don't forget, what you can do with Maven, can also be done easily with Ant ;-)
    >
    > Regards,
    > Lofi.
    > http://sourceforge.net/projects/ejosa
    > http://sourceforge.net/projects/openuss
  20. Sorry. Typo in my last posting..

    I meant to say -
    Small projects WILL NOT realize any value out of Maven

    Instead , I said
    Small projects WILL NOT realize any value out of Ant

    It is corrected below.

    Cheers,
    Srikanth

    > > I tried Maven (after having some discussions with a Maven's developer in TSS)... It looks promising but surely not for beginners... There are a lot of stuffs to configure before you can run it for the first time.
    > >
    >
    > The main problem with Maven today is the lack of documentation which makes it harder to figure out how to set up a project. Had there been enough documentation and sample code, nobody would be complaining.
    >
    > There was a presentation from Vincent Massol at the Serverside symposium and the ppt and a sample project was available. Search google with the right key words and you are bound to find it.
    > Once you get the sample, there will be no looking back.
    >
    > > I think, Maven forgets the KISS principle. Ant is much more easier to use. I prefer to have a collection of Ant templates:
    > >
    >
    > Maven follows the KISS principle. It may sound strange for readers on this forum, but the fact that it enforces one project, one artifact which makes the build scripts simple.
    >
    > If you compare Ant to C, then Maven is like Java.
    > Sure people began by complaining about the lack of power in Java visa vis C, lack of pointers, access to devices, restricted sandbox etc. but things settled down eventually. I think people will realize Maven's value soon. By forcing you to build in certain way, Maven brings simplicity and maintainability to the scripts. Sure Ant give you enormous power, but at a cost.
    >
    > Ant makes you think in terms of files, copying files . Maven thinks in terms of repositories, artifacts with the right version etc...
    >
    > Bottomline : Small projects WILL NOT realize any value out of Maven. (It is much like writing a elaborate custom framework for a project to be delivered in 3 months) It is too much of overhead. However there is a lot of ROI for medium to large projects (or long running ones)...
    > Different courses, Different horses Thats the moral of the story
    >
    > I have been working on a J2EE project that has been running for more than three years and I wish Maven was there when I started on this project.
    >
    >
    > >
    > > If you are using NetBeans, the integration with Ant is marvelous! Mount your directory, go to the ant script you want to run, press F6, that's it! Eclipse 2.x only supports !one! Ant session and this is not good (if you need to run many Ant scripts on the same time). I think in Eclipse 3.x they support more than one session.
    >
    > It is a matter of time, when the IDEs will support Maven. Until then
    >
    > Cheers,
    > Srikanth
    >
    > >
    > > And don't forget, what you can do with Maven, can also be done easily with Ant ;-)
    > >
    > > Regards,
    > > Lofi.
    > > http://sourceforge.net/projects/ejosa
    > > http://sourceforge.net/projects/openuss
  21. Maven == C++, Ant == Java[ Go to top ]

    <quote>
    If you compare Ant to C, then Maven is like Java.
    Sure people began by complaining about the lack of power in Java visa vis C, lack of pointers, access to devices, restricted sandbox etc. but things settled down eventually. I think people will realize Maven's value soon. By forcing you to build in certain way, Maven brings simplicity and maintainability to the scripts. Sure Ant give you enormous power, but at a cost.
    </quote>

    I don't think so. For me Maven is like C++ (many stuffs to setup, complicated to extend) and Ant is like Java (easy to setup and to extend) ;-)

    I really agree with the standardization of the directory structure and I also did this in all my projects but you can also reach this in Ant.

    Lofi.
  22. Maven == C++, Ant == Java[ Go to top ]

    It looks that way to me, too. By using antmerge I have centralized master build scripts and any number of individual project build scripts that "extend" the master. This gets me the consistency (and small individual build files!) that I need. Oh, it's not perfect - I'd love for Ant to have a built-in mechanism for a true hierarchy of build files - but it seems to be as capable as Maven with alot less hassle.

        -Mike
  23. Maven == C++, Ant == Java[ Go to top ]

    <quote>
    By using antmerge I have centralized master build scripts and any number of individual project build scripts that "extend" the master.
    </quote>

    hey, this is a good idea. I'll check more on antmerge.

    Thanks for the tip.

    Lofi.
  24. Maven == C++, Ant == Java[ Go to top ]

    \Lofi\
    hey, this is a good idea. I'll check more on antmerge.

    Thanks for the tip.
    \Lofi\

    No problem. antmerge is a bit quirky in places, but once you get past the quirks it works pretty well.

       -Mike
  25. antmerge[ Go to top ]

    Excellent reference Mike.

    Now I remember why I used to come here more often.

    Jason
  26. ant + xslt == whatever you want[ Go to top ]

    Our team has come to quite flexible approach. We use custom XML files to define metadata (e.g. module dependencies) and XSLT transformation (one for all projects) to obtain ANT script (it's XML after all) that will do all CVS checkouts, compilation, builds, etc. etc. With the power of XSLT we might really do whatever we need, without ever extending ANT with custom targets.

    It still far from excellence because it was and still is developed in 'ad hoc' mode. But now we are supporting ~30 modules (in CVS sense) and ~10 different products built from these modules, with all the versioning stuff.
  27. ant + xslt == whatever you want[ Go to top ]

    Our team has come to quite flexible approach. We use custom XML files to define metadata (e.g. module dependencies) and XSLT transformation (one for all projects) to obtain ANT script (it's XML after all) that will do all CVS checkouts, compilation, builds, etc. etc.

    That's a perfect example of a model driven domain, in this case the domain of project building. XSL is a great way to focus on simple declarative models and generatively apply and reuse the best practices of coding.

    With the power of XSLT we might really do whatever we need, without ever extending ANT with custom targets.

    And if a project ever needs special build features, the XSL can generate shell scripts, Java, even custom Ant tasks. But Maven has better XSL support than Ant, since Maven is scripted with Jelly, which supports XSL pipelining.
  28. ant + xslt == whatever you want[ Go to top ]

    This is also the approach we take with our internal build system. That being said, now that we're supporting ~60 CVS modules, and ~20 projects built from those modules, we're finding it difficult to keep up. For one, each project has its own oddities, and trying to deal with those oddities in a templated build system can be difficult. Do you modify the template to account for those oddities? Do you ask the development team to adhere to the constraints of your current template? Do you create a new template (as well as the meta-data to associate to that new template)?

    There are plenty of ways to address the questions above (for example, the pre and post processing capabilities in Maven). The problem is that our team is stretched too thin to continue development on a homegrown system (and keep it up to snuff with our development needs). Maven strikes me as an intriguing replacement, and a way to leverage the open source where it really makes sense - in infrastructure investments.
  29. Project build script nirvana[ Go to top ]

    Up to Maven beta 6, that's how maven was built.

    We then hit the wall. There's so much that can't be done this way.
  30. Maven and Ant[ Go to top ]

    And don't forget, what you can do with Maven, can also be done easily with Ant ;-)


    I disagree. If you follow the certain steps for eg, a certain kind of directory hierarchy etc.., What you can do with 25 lines of Ant code (sometimes even more) can be done with one or two lines to Maven plugin. This is my experience.

    Maven may not be suitable for every Java/J2EE project out there. That is not the goal either. But a vast majority of J2EE projects can use Maven and simplify their lives.

    Cheers,
    Srikanth
  31. Maven and Ant[ Go to top ]

    <quote>
    I disagree. If you follow the certain steps for eg, a certain kind of
    directory hierarchy etc.., What you can do with 25 lines of Ant code
    (sometimes even more) can be done with one or two lines to Maven plugin.
    This is my experience.
    </quote>

    therefore you can make your own Ant extension in Java ;-) If you think
    that you will need this feature again and again, you can write it as an
    Ant extension.

    Don't understand me wrong. I'm not against Maven. In the beginning I'm
    very exited about the main ideas of Maven (directory structure, POM,
    repository). But in the details it fails the KISS principle, examples:
    - Why do I need to use Jelly script?
    - Why do I have to setup many stuffs before I can begin?
    - Why is that so complicated to setup your own repository?

    Every good product (not only build and execution system) supports
    the users in different kind of abstraction level:
    - As a beginner you just want to build your system, that's it.
    - As an expert you will want to optimize, extend your build system.
    The product should also support you to evolve from beginner's way
    to the experts' way in a smooth transition. Ant offers this but Maven
    not. It's just too complicated for beginners like me ;-)

    Regards,
    Lofi.
  32. Maven goals[ Go to top ]

    Although i understand the goals of Maven, i don't really understand
    why they decided to build a separate build system when the
    goals are accomplishable using existing tools.

    For example one of the main goals of Maven is 'Providing a uniform
    build system'. I guess by this they mean enforcing a set
    project directory structure and set of xml configuration files and
    so forth. Isn't this goal just as easily accomplished by coming
    up with a standard for how to organise an ant (or make) project?

    Sure standards for project structure are a good idea, but why
    on would you want to incorporate them into the build system software
    itself? There is never going to be a structure that suits all
    projects, for very small projects the Maven project structure is
    complete overkill, and for large projects Maven is unlike to be
    flexible enough.

    Another goal of Maven is to make projects simple to understand,
    so why use arcane Jelly XML scripting in your build system (how
    many developers already know that?), not to mention a bunch of other
    poorly documented Maven specific XML files. Setting up your
    first Maven project is certainly not a simple task.

    As for the other functionality of Maven, all the web
    site building functionality, sub-project dependencies, code metrics
    could easily be done in ant by calling tasks or standalone
    java programs. Many of this extra functionality is only useful
    for large scale open source projects so are not necessary
    features for a general-purpose build system.
  33. Precisely![ Go to top ]

    Yep, that's the problem with maven. The only people it will keep are those who jumped onto the bandwagon early on, and lack the courage to leave it.

    For small projects, it's far too much effort, and for large projects, useless. The IDEA guys even tried to use it for a couple of months. In the end they gave up because it simply wasn't good enough for them, and just didn't do the things they needed it to do.

    So despite all this 'power' it supposedly provides, you can still do a hell of a lot more with plain old ant files.
  34. I can understand where everyone is coming from in criticising Maven, but I've actually found it really helpful. It did take a long time to get up to speed with, and becoming proficient in Jelly is a pain. But the concept is a good one.

    Basically, I see Maven as a plugin system for Ant. It appeals to me in the way XDoclet and MDA (aka code generation, such as with Middlegen or AndroMDA). It allows me to set up templates for different aspects of the build process. This keeps everyone in the dev team working the same way. I also find the strict enforcement of the directory structure helpful; again, it keeps the whole team working together.

    Before I used Maven I found myself constantly cleaning up hacked build.xml files. Every project was done a bit differently, depending on how the developers were. Now I have to ocassionally tweak the Maven plugins, but it ends up being a lot less work.

    When evaluating Maven I also looked at Centipede, but steered away because it looked like it wasn't getting much development attention. Can anyone comment on the current state of the project?
  35. I used Maven for about a year, and well I do agree allot of this criticism is warranted.

    Firstly I think one thing that did not help Maven was moving from an Ant style build process to a Jelly defined one. I was using Ant myself and found the initial releases a total mess that resembled spaghetti junction, later I think it improved. But still it takes allot of greps and finds to gauge percisely where to configure and change things. I'm sure many of the early users remember their first encounters with Maven,in not a particularly positive way.

    I've never rated JDepend so I'll not go and start bashing it again.

    But all of the other tools are relatively helpful, and provides a nice centtral point of reference. I'm not totally happy with the imposed directory structure, but that said its a good enough start and provides a good point of reference for those who actually do intend to provide some documentation with their project.
  36. Enforced directory structure[ Go to top ]

    Which directory structure can't you configure?
  37. Enforced directory structure[ Go to top ]

    Which directory structure can't you configure?
    Disclaimer: I like Maven a lot and use it.

    Response: I can't have my unit test source and production code source in the same tree. I asked about this on the maven list (too lazy to put link), and was beaten into submission (by Jason Van Zyl) for even suggesting such anathema. That is the one bad taste I have for maven. In many situations, you don't HAVE the option to reorganizing the dir structure just to use maven.
  38. I Want My Own Server Side Forum[ Go to top ]

    Yep, that's the problem with maven. The only people it will keep are those who

    > jumped onto the bandwagon early on, and lack the courage to leave it.

      Hani, are you now working on getting your very own Server Side forum with your contrarian open-source-bashing let's-all-buy-BEA-and-hug-Sun opinions that go unnoticed in your linkless self-contained Bile Blog universe?

      - Gerald

    PS: Hani, if you need help on how to add links to your website, let me know.
  39. Precisely![ Go to top ]

    Yep, that's the problem with maven. The only people it will keep are those who jumped onto the bandwagon early on, and lack the courage to leave it.


    Well, if Hani is bitching about it, it can't be that bad ;-)

    We actually just began an effort to incorporate Maven into our build structure. We finally reached a point where we have enough seperate projects going on that we:

    a) Need a consistent project structure and build process
    b) We need to be able to break out our common code into modules and version them easily

    We have been doing both, but not perfectly and not without some "manual" intervention. We needed to streamline our home-grown process.

    I have glanced at Maven several times in the past and it seemed to be the right candidate. It has *most* of the processes we follow out of the box. It is also nice to be able to build common modules and "publish" them to a common repository with little effort. Having Maven manage third party JAR dependencies (Hibernate, Log4J, etc) is pretty cool, and it makes the code repositoty very lightweight - no JAR files to check in, Maven gets them for you!

    As for the docs in generates - I don't really care about those right now. Javadocs for the common modules are nice, but I can get those with Ant. And since I don't care to have them, I don't create them - no big deal.

    Maybe I will be singing a different toon in a couple of weeks. But so far, I'm pleased.

    Ryan
  40. Precisely![ Go to top ]

    I don't understand why some people are trying to compare Maven func. to Ant build task. I'm using Maven not for it build quality, but for the project management ability. I'm looking of them as just another task to list of plug-ins.


    > a) Need a consistent project structure and build process
    > b) We need to be able to break out our common code into modules and version them easily
    >
    > We have been doing both, but not perfectly and not without some "manual" intervention. We needed to streamline our home-grown process.
    >

    Precisely!

    I don't hear anything about the local and remote repository, which is the main concept around the Maven.
    If you have a lot of different projects and there exist some references between them That you depend on. And after time try to back trace the versions(or use concrete version in a new project) .... I think Ant can't help you. That is my experience.

    I think that Maven does not exclude Ant, There are different in concepts.

    G.
  41. Jelly and Ant[ Go to top ]

    Another goal of Maven is to make projects simple to understand,

    > so why use arcane Jelly XML scripting in your build system (how
    > many developers already know that?), not to mention a bunch of other

    Lots of developers already know how to write Ant scripts. Jelly builds on top of Ant, so all the developers that can write Ant scripts can write Jelly scripts too.

    > poorly documented Maven specific XML files. Setting up your
    > first Maven project is certainly not a simple task.
    Opinions are like...
  42. Maven presentation and sample code[ Go to top ]

    In one of my earlier postings, I mentioned the main problem with Maven is the lack of documentation, tutorials and sample code to look at.

    There is a good presentation by Vincent Massol for building J2EE applications with Maven at

    http://www.pivolis.com/pdf/J2EE_projects_Maven_V1.1.pdf

    The presentation itself does not convey much. It has to be referred in the context of the sample code. The sample code is available at

    http://blogs.codehaus.org/people/vmassol/archives/everest.zip

    For those who have been excessively complaining, please look at the sample code, go thru the presentation and if that helps you change your mind well and good. Otherwise it is back to square one.

    Cheers,
    Srikanth
  43. Valiant effort[ Go to top ]

    I reckon Maven is a valiant effort for producing a structure in which modular JAVA can be produced.

    If any of you have tried writing your own Imake files or tried doing it all on your own with Ant, then you know what a nightmare it can be. So any attempt to make Java development a bit more professional should be applauded not knocked just because people have their own personal favourite ways of doing things.
  44. Valiant effort[ Go to top ]

    So any attempt to make Java development a bit more professional should be applauded not knocked just because people have their own personal favourite ways of doing things.

    Indeed the list of serious projects powered by Maven is impressive, including 21 Apache projects and about half a dozen dot com projects.