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?

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

-John-
C24

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.

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

I'd like to clean those up.

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.

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

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

> 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.

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?

> 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

> >
>
> 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

> 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.

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

 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

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!

<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.

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.

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

>

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

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

<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.

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

<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.

\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

Excellent reference Mike.

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

Jason

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.

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.

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.

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.

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

<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.

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.

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.

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?

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.

Which directory structure can't you configure?

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.

> 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.

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

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.

> 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...

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

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.

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.