It's not a secret anymore!*
The moose likes Ant, Maven and Other Build Tools and the fly likes Maven: What's the big deal? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » Ant, Maven and Other Build Tools
Bookmark "Maven: What Watch "Maven: What New topic
Author

Maven: What's the big deal?

Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

I've got a new project coming up and one of the engineers is wanting us to start using Maven. I've been looking at it for a few days and trying to set something simple up but its very frustrating. And from the looks of the community everyone has the exact same issues. Yet, folks still swear by it.

Can anyone explain to me how the frustrations with getting a Maven project setup is worth the reward? Aside from managing JAR dependencies (which quite frankly I don't find all that worth while) and a common project structure (which quite frankly I find unproductive) I don't see any benefits. Ok, well, I guess I just don't see it at all. What's the big deal with Maven?


GenRocket - Experts at Building Test Data
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41629
    
  55
I'll second that I don't see what the big deal is, especially since it's so easy to set up an Ant build with all the bells and whistles. And I actually hate it for apparently requiring downloading megabytes of open source libraries that I have installed locally already. I deleted Maven the first time I noticed it doing that; it's just too easy to copy and adapt one of the existing Ant build files.
[ December 17, 2007: Message edited by: Ulf Dittmer ]

Ping & DNS - my free Android networking tools app
Guy Allard
Ranch Hand

Joined: Nov 24, 2000
Posts: 776
I have used both. Stick with Ant. It is the better of the two. Maven is opaque, Ant is clear.

Having said that, I know a lot of people in the real world will disagree: many large open source projects are using Maven.

Guy
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Guy Allard:
Having said that, I know a lot of people in the real world will disagree: many large open source projects are using Maven.

Guy


And that is who I'd like to hear from. I keep thinking I am missing something. Maybe Maven fans can tell me what that is.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Gregg, you are way ahead of me. It's been years, and I still haven't figured out why anyone would prefer Ant over make, let alone Maven. Seriously.


[Jess in Action][AskingGoodQuestions]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Ernest Friedman-Hill:
Gregg, you are way ahead of me. It's been years, and I still haven't figured out why anyone would prefer Ant over make, let alone Maven. Seriously.




I do like Ant. And in fact I actually like Gant (Groovy + Ant) when things tend to get a bit more complicated than what I like to express in XML.
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Things I like about Maven -

1.) Maven downloads all dependences for any Maven project and puts them in a known location. Sure, you can do this in Ant, but *you* have to do it... most Ant scripts assume that dependencies are in a subdirectory (usually /lib or similarly named) internal to the project - meaning each project has it's own copy of junit.jar, spring, jakarta commons, etc.

2.) Maven makes it obvious exactly what version of a dependency you are using - you don't have to guess or look in the Jar Manifest to figure out what version of JUnit (or whatever) you have included in your project.

3.) Standard project structure - a ton of people hate Maven for this, but at least it enforces some useful things - keeping resources segregated from source code, parallel test directories (no package structure starting with "test" that gets filtered out somewhere in Ant if you're doing a production build...)

4.) With Ant you describe a build by telling it "how" to do pretty much everything. With Maven you tell it "what" to do and provide some configuration options. If you want to add Cobertura support to your build process - Maven: Add a report tag for Cobertura with some configuration options, add cobertura to the reporting task, mvn site -> you have Cobertura reports. With Ant: download Cobertura, put it somewhere, add it to some classpath in Ant - but only when doing tests, integrate it into testing task (specifying directories, classpath, command-line options, etc.), Ant <your task name> -> Cobertura report.

5.) Now some people want to use Clover instead of Cobertura for coverage reports... Maven: add Clover report tag with config options, add Clover to reporting task, create a profile to select between Cobertura and Clover, mvn site -> Clover reports. Ant: download Clover, put it somewhere, add some proprty to figure out if the user wants Cobertura or Clover coverage, add it to some classpath in Ant - but only when doing tests - and not when doing Cobertura tests, integrate it into testing task (specifying directories, classpath, command-line options, etc.) - but only when not doing Cobertura testing, Ant <your task name> -> Clover report.

Things I don't like about Maven -

1.) Maven has a steep learning curve.


2.) Maven is really great for some projects, and not so great for others. Need to integrate with another project - but one that's not also built in Maven - you can do it, but it's a pain. Want to do integration tests - you can do it, but it doesn't fit well with the Maven model...


3.) There are some errors that have needed to be fixed forever, but are still out there. I think this is a symptom of two things - a.) Maven tries to be so much (it's a project management structure, it's a build system, it's a dependency specification system, it's a IDE plugin, it's a dessert topping, it's a floor wax...) and b.) there being way too many Maven subprojects - so the error gets passed around a lot until it's found which project's "fault" it is...

4.) Offline mode needs to work better.


-Nate
Write once, run anywhere, because there's nowhere to hide! - /. A.C.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Thanks Nathan. Now this is what I am looking for. Some comments related to your points:

1.) Don't you have to tell Maven where to get all these dependencies? You have to add repositories for projects (well, some). And then you have to create the POM for you project and say I want this and this and this and this. When it is time for a new project you create another POM or copy your existing POM and make modifications. Now, assuming you require most of the same dependencies how does this save you when you can just copy from one project to another everything you need? Not to mention the ramp up time trying to get Maven working in the first place.

2.) I don't have to guess either. Most JAR's are named with the version. If not, I simply rename them. And again, copy from one project to another. Or I can go download the latest on. Or I guess I can go back into my POM and tell Maven which one to go get. Chances are this is 1 or 2 JAR's. It's not that a deal to grab what I need, IMHO.

3.) My only argument here is that I don't care for that project structure. I've heard/read you can modify this but its a real pain.

4.) Good points here. However, assuming you did it once for a project, again, not that difficult to copy and paste some stuff. Ant build files are easy to move around. Maybe my projects just aren't as complex?
Guy Allard
Ranch Hand

Joined: Nov 24, 2000
Posts: 776
Originally posted by Gregg Bolinger:


And that is who I'd like to hear from. I keep thinking I am missing something. Maybe Maven fans can tell me what that is.



Did not say I was a Maven fan. Just that many use it.

Poke around at Apache, and look at the build systems being used. I just spent 3 minutes there and see:

. Active MQ
. Geronimo
. MyFaces

and surely there are more. Look at the developers' mailing lists, I imagine they have discussed it.

Guy
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Guy Allard:
Poke around at Apache, and look at the build systems being used. I just spent 3 minutes there and see:

. Active MQ
. Geronimo
. MyFaces

and surely there are more. Look at the developers' mailing lists, I imagine they have discussed it.

Guy


So are you saying that because Apache projects use it it must be good? Or just that I may find more info on why it is being used on those mailing lists? If its the former then I have to strongly disagree. Wide spread usage doesn't equate to a good product. Look at Struts.
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Originally posted by Gregg Bolinger:
Thanks Nathan. Now this is what I am looking for. Some comments related to your points:

1.) Don't you have to tell Maven where to get all these dependencies? You have to add repositories for projects (well, some). And then you have to create the POM for you project and say I want this and this and this and this. When it is time for a new project you create another POM or copy your existing POM and make modifications. Now, assuming you require most of the same dependencies how does this save you when you can just copy from one project to another everything you need? Not to mention the ramp up time trying to get Maven working in the first place.


You don't tell Maven where to get a dependency on the dependency itself. Normally, dependencies download from the public Maven repository on ibiblio - but if your project uses libraries that aren't in the public repository, you'll need to create a project repository to host these. You just add the repository to the project, and Maven will search in this order - local repository (on disk), public repository (on ibiblio), project repository (wherever you define it). You can also override the public repository if you want to host all the dependencies yourself for some reason.

You also don't necessarily copy and paste your buildscripts between projects (as you would with Ant). If the projects are actually related, you can make project inheritance hierarchies, and have subprojects inherit dependencies, repository definitions, etc. from a parent project.

Originally posted by Gregg Bolinger:

2.) I don't have to guess either. Most JAR's are named with the version. If not, I simply rename them. And again, copy from one project to another. Or I can go download the latest on. Or I guess I can go back into my POM and tell Maven which one to go get. Chances are this is 1 or 2 JAR's. It's not that a deal to grab what I need, IMHO.


But you're handling the versioning instead of it automatically being done by your build system... (Though truthfully - you still have to do this in Maven if you have a dependency outside of the public repository.) And if you only have 1 or 2 Jars you depend on, then dependency management really isn't that big of an issue.

Originally posted by Gregg Bolinger:

3.) My only argument here is that I don't care for that project structure. I've heard/read you can modify this but its a real pain.


But what don't you like about the project structure? What directory structure would you use?
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Gregg Bolinger:
2.) I don't have to guess either. Most JAR's are named with the version. If not, I simply rename them. And again, copy from one project to another. Or I can go download the latest on. Or I guess I can go back into my POM and tell Maven which one to go get. Chances are this is 1 or 2 JAR's. It's not that a deal to grab what I need, IMHO.


Our team uses the convention that the version is encoded in the cvs comment of the jar-file. And this is actually enforced by our Ant script.

This makes it really easy to update a jar file - just overwrite the existing jar file and commit with the appropriate comment. No build script or other classpath adjustment needed. And using Eclipse, you can easily look up the currently used version using the history view.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Ilja Preuss:


Our team uses the convention that the version is encoded in the cvs comment of the jar-file. And this is actually enforced by our Ant script.

This makes it really easy to update a jar file - just overwrite the existing jar file and commit with the appropriate comment. No build script or other classpath adjustment needed. And using Eclipse, you can easily look up the currently used version using the history view.


Good point except Maven folks say that JAR files don't belong in version control. They belong in a maven repository.
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24183
    
  34

Originally posted by Gregg Bolinger:


Good point except Maven folks say that JAR files don't belong in version control. They belong in a maven repository.


Yup. No sense using your own VCS when you can use something more complex, possibly not even under your own control!
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Do you check each version of the JDK you build your project under into version control control too? ( I do realize some people probably *do* do this...) So why should third party libraries go there?

A Maven repository is being used as the "version control" for your dependencies - and your normal version control system is being used for version control of the code you write.

Also, Maven can be completely "under your control" - just make your own repository, and override the default repository setting to only use yours.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Nathan Pruett:
Do you check each version of the JDK you build your project under into version control control too? ( I do realize some people probably *do* do this...)


Good question. To the extent that it's actually possible it could be worth a try.

Fortunately, the JDK doesn't change as often as third party libraries.


So why should third party libraries go there?

A Maven repository is being used as the "version control" for your dependencies


So with Maven you get your JDK from the Maven repository?

your normal version control system is being used for version control of the code you write.


What's so abnormal about third party libraries that you need a separate repository for them?

Also, Maven can be completely "under your control" - just make your own repository, and override the default repository setting to only use yours.


Well, to me that still sounds more complicated than just checking the third party libraries into the normal version control repository. Especially since I can't remember ever having encountered a problem that was caused by this practice...
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

+1 for Ilja's points.

Ok, so what is this I hear about the fact that you shouldn't check large files into version control? I spoke with a guy the other night that never mentioned the "best practice" of using Maven for JAR's but it was more of a file size issue. Is this something that carried over into SVN from CVS that may no longer be an issue?
Eric Nielsen
Ranch Hand

Joined: Dec 14, 2004
Posts: 194
I'm not a Maven expert, nor an Ant nor Make one.

Lately I've been using Maven and bounce between being very happy and very frustrated with it.

Things I like:
It handles the transitive dependence. I'm much happier needing to say my app requires Foo, Bar, and Baz libraries and not needing to know what jars Foo,Bar, and Baz needs to accomplish their own goals. Of course with a lot of the modular infrastructure components like Spring, Struts, or Hibernate you still often end up having to list 2-3 top-level components within each set to get the different pieces you need, but its still nicer than having to list all 15-20 components.

I like the way it handles adding dependencies that are only needed for testing executions. It feels simple and clean to me; though I'll admit that i don't really know how the other approaches would handle it.

I like that, out of the box, it has a relatively decent emphasis on unit-testing. Admittedly you could get the same in Ant/Make by starting from some already fleshed out build script, but then you'll need either fine an appropriate existing build script or learn to assemble your own.

I like that it gives a shared reference point to communicate build issues. I find it easier to compare different POMs and see how they are configured, than to compare different make files. Much of this is probably due to the standardized directory structure

I like the ease of generate/deploying reports on the code.

Things I'm frustrated with:
Integration or Acceptance Testing is just not well handled at present. I have seen that they are working on adding it to the standard directory layout/build lifecycle rather than the current hacks. I'm not sure if their plans will really help with some of my problems (stuff like wanting a separate coverage report for Acceptance vs Unit tests and for a failing acceptance test to not cancel the site build as it does now). I use the single module approahc so IT/UT live in the same test source tree, in a different package, with includes/exclude rules setup to run their tests in the different lifecycle phases, with the cargo-maven2-plugin used to deploy the war file and startup a container, etc.

I don't like the non-report based tools for generating the developer's site. (Don't find any of their mini-languages more useful than just plain old HTML for that)

I don't like some of the trickiness in figuring out how to get some of build/reporting plugins to work well together. Some of this is more annoyances -- I think its stupid to have to tell about 1/2 the plugins that I'm using a 1.5 JDK... Seems like that should be set at a higher level and bubble down as needed. Some of it is figuring out how to get a code coverage tool to a) put its instrumented classes somewhere different, b) put its reports somewhere different, and c) pick the right test runner to use, etc and just all the other "why doesn't it just work" type problems people run into when trying to tweak their build a little bit more.

I don't thing they've found the right balance of silence/noise in the build output, though I suspect a lot of this is under my control, I just haven't found it yet..... There's a ton of cruft I don't care about -- I don't like see that its "downloading" four files from my local repository on every fricken build. I don't like seeing all the cruft associated with my application's startup/deployment (ie the log spew that Spring/Hibernate generate when they parse their configuration type files). I find the test failure output to be next to useless from Maven... either need to go back and run the test directly through my IDE, or generate the site site eploy goal to get useful diagnostic information.. normally I'm never running Maven with a failing test so its not a big deal, but when it doesn't happen its just annoying....
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30392
    
150

Originally posted by Gregg Bolinger:
Ok, so what is this I hear about the fact that you shouldn't check large files into version control? I spoke with a guy the other night that never mentioned the "best practice" of using Maven for JAR's but it was more of a file size issue. Is this something that carried over into SVN from CVS that may no longer be an issue?

It might depend on how large the file is and how much space is on the server. We check jars into CVS, but wouldn't check in a 1 gig data dump. And there's certainly jars in JavaRanch's SVN repository .


your normal version control system is being used for version control of the code you write.

Why does it matter whether someone on my team/company wrote a component jar or someone wrote an open source one? It's still a reusable jar not owned by my app.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Dan Dyer
Greenhorn

Joined: Dec 22, 2007
Posts: 1
You may find this interesting:

http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Dan Dyer:
You may find this interesting:

http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design


That's awesome! Thanks for the link Dan.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

This is another blog I completely agree with. I don't even think it needs to apply solely to Agile development.

All third party and common components must be in the version control system - preferably with the application. This is a bit controversial because it seems wasteful and redundant but we're looking for a different kind of efficiency. Home grown common code can be managed the same as third party components or compiled every time just like your application code.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Gregg Bolinger:

Ok, so what is this I hear about the fact that you shouldn't check large files into version control? I spoke with a guy the other night that never mentioned the "best practice" of using Maven for JAR's but it was more of a file size issue. Is this something that carried over into SVN from CVS that may no longer be an issue?


If I remember correctly, large *binary* files are really a "problem" with CVS. We still do it, though - hard disk space is just so cheap these days...

SVN handles this better: http://subversion.tigris.org/faq.html#binary-files
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Originally posted by Dan Dyer:
You may find this interesting:

http://fishbowl.pastiche.org/2007/12/20/maven_broken_by_design


So are YUM, Portage, and RubyGems also "broken by design"?

Responsiveness - the first time you use Maven to build, yes it takes a long time.
We have a joke around the office, when a new hire is setting up their development environment for the first time. �Now we go to lunch while Maven downloads the Internet.�
LOL - do you say the same thing while the new hire is downloading the JDK and Eclipse and synching up with the repository?

Reliability - I'd agree here, if you were actually using "1-n repositories" to do your build. Limit that to 2 repositories (local and project) (or 3 - local, project and public) and it's not too bad.

Repeatability - I do agree with the last part here - Maven shouldn't update plugins willy-nilly. But with a project repository, "dependencies disappearing from the internet" shouldn't be an issue.

I'm mostly posting as devil's advocate here. I'm more of the opinion of Eric Nielsen - Maven does some things that I really like, but there are some things that are really annoying about it. The same as with Ant. I just don't get why some people hate Maven - or are adamant that dependencies are stored in a source code repository versus a Maven repository.

One issue I can see is that the benefits Maven provides would be very helpful for an open source development shop or hosting service, but wouldn't be as helpful for in-house development with a few projects under development and other projects mostly being legacy "bug fix" sort of projects. Most places I've worked have been the second - what about all of you?
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30392
    
150

Originally posted by Nathan Pruett:
LOL - do you say the same thing while the new hire is downloading the JDK and Eclipse and synching up with the repository?

Why would each new hire have to download these? I'd want to know everyone has the same version and download them once (per release or significant bug fix.)
Nathan Pruett
Bartender

Joined: Oct 18, 2000
Posts: 4121

Originally posted by Jeanne Boyarsky:

Why would each new hire have to download these? I'd want to know everyone has the same version and download them once (per release or significant bug fix.)


OK, ok.... Instead of "download" - copy off a network drive and install. But if you have a project repository set up on your local network, this is what Maven's doing for dependencies too.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Nathan Pruett:

OK, ok.... Instead of "download" - copy off a network drive and install. But if you have a project repository set up on your local network, this is what Maven's doing for dependencies too.


The question remains: why setup up an additional Maven repository when the version control repository can already do what you need?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16022
    
  20

Originally posted by Ilja Preuss:


The question remains: why setup up an additional Maven repository when the version control repository can already do what you need?


Well actually, it can't. A Maven repository is expected to present a certain structure and set of support files, easily representable on a bog-standard Apache-style web site. There's more in the Maven metadata than just version info. Plus, you get almost zero benefits from using a VCS, since each version of a Maven object has a distinct filename - it's not just "generation x.y.z" of a base object.

On the other hand, I agree. It's a nuisance, if for no other reason that you need to maintain Yet One More set of files under your infrastructure support system instead of dimply dumping them into Version Control.

I suspect that a clever person could probably front CVS, SVN or some similar VC system, especially someone looking to do a Linux userspace file system project. For all I know, some work has even been done.


Customer surveys are for companies who didn't pay proper attention to begin with.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Ilja Preuss:


The question remains: why setup up an additional Maven repository when the version control repository can already do what you need?


Oddly enough I can't get a good answer for this from anyone. All I ever get is what has been said and "Because JAR's don't belong in version control". But no one has really said why they don't. In fact, over the weekend I was working with a guy who isn't using Maven but still keeps his JAR files separate from version control. And when I wanted to work on his project he told me to go download all the JAR's I need. WHAT? :roll:

I at the very least talked him into checking the JAR files into a separate repository location so that I could get them easily. Of course, I also get 200 jar files I don't need because he uses one location for all his projects.

I argued with his about it quite a bit. I think at this point it has become more philosophical than material and its the same as arguing over project directory structure. Everyone does it different. As a developer you just have to be willing to change when someone else is in charge of that aspect of the project. In the end I can still develop and build the project. It was just more trouble than needed to get it going in the first place.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Who says jars don't belong in version control? We have an Eclipse project named "Jars" where we stash all the jars we use for our various projects. For example we have four different versions of Log4J in there, put in there at different times. And they go into CVS because that's how we get different machines to share software components.

It's true that the jars never change, so putting them in CVS might seem odd to people who are excessively literal-minded. But to me it makes much more sense to keep all the software components in one place rather than banning one group for... whatever those other people's reasons might have been.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Paul Clapham:
We have an Eclipse project named "Jars" where we stash all the jars we use for our various projects.


And even that seems silly to me. So to work on an existing project I have to fetch resources from 2 different places? Why can't the JAR files be packaged in version control with the project?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Originally posted by Gregg Bolinger:
Why can't the JAR files be packaged in version control with the project?
They are. That's the second step. The first step is to have a repository of jars to choose from, and the second step is to copy selected jars into the projects where they belong.

I think you and I are pretty much agreeing here. When I set up a project I'm going to configure it with the various jars that it needs. That only needs to be done once in most cases.

Edit: Just to clarify. The second step is to put entries in the build path of the project that refer to the jars in the Jars project. We don't actually copy the jars into other projects.
[ January 02, 2008: Message edited by: Paul Clapham ]
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Originally posted by Paul Clapham:
They are. That's the second step. The first step is to have a repository of jars to choose from, and the second step is to copy selected jars into the projects where they belong.

I think you and I are pretty much agreeing here. When I set up a project I'm going to configure it with the various jars that it needs. That only needs to be done once in most cases.

Edit: Just to clarify. The second step is to put entries in the build path of the project that refer to the jars in the Jars project. We don't actually copy the jars into other projects.

[ January 02, 2008: Message edited by: Paul Clapham ]


Well, then we really aren't agreeing. I can come to terms with a company have a central repository of JAR files to choose from rather than hitting the web everytime. But I would go grab the ones I need, copy them into my project in some lib directory or sorts and then version them up with the rest of the project.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16022
    
  20

I've taken to adding a project named "lib" to my Eclipse workspace that can be a dependency for other projects so I don't have to replicate the jarfiles into each and every project.

However, I need to get pedantic here, and I'm just as guilty of this as everyone else:

In Maven, what we've been calling a "version" of a jar is actually a formal release of a jar. The difference is that when Maven projects refer to a dependency (jar), they can depend on a fixed, immutable set of resources, and not "version 1.0 as built on Tom's machine" or "1.0 as built last Tuesday". The intent is that instead of doing in a lot of systems and simply assuming that the latest version (or reasonable facsimile) will do, that instead the project will use that and only that verseion of a resource (as indicated in the POM). And thus that when large groups of geographically-distributed people get together and build copies of a project, there will be no hard-to-debug variations due to different builds of the same "version" of a given resource. And, as far as I can recall, "resource" is the operative word here, since I don't believe that a Maven dependency has to be a single jar file (or even any jars at all).

As I mentioned, I myself have no problems with using VCS as a one-stop-shopping database for application building components, I merely observe that the Maven Repository paradigm isn't going to gain much value per se. - other than common location of assets.

In fact, the nature of Maven is such that dependency object releases are stored sparsely and not necessarily in version order (if you think that pulling dependencies is painful now, consider what it would be like if you had to pull - and keep updated - the entire ibiblio Maven2 repository!). Local Maven repositories are, in fact, basically just caches.

BTW, It is a good idea to maintain a site-local Maven repository (remember, these critters, once released are immutable), so that at least people setting up a new build can pull their copies at LAN speeds instead of Internet speeds.

I also have taken to doing builds with the "-o" (offline) option. About once a day, this seems to fail, so then I do a connected build, but for the rest, it saves me a second or 2 per build.
Jon Brisbin
Greenhorn

Joined: Jan 03, 2008
Posts: 2
Gregg, you had asked for reasons why someone would use Maven and I was able to talk one of my clients into letting us use it on the project, so I'll relate my experience here for the edification of all.

When I came onto the project, the lead developer had been distributing the development code as a zip file that included subdirectories of Jetty, a lib directory that included dependent jars, the actual Java code, and a webapp. It was just a NetBeans project zipped up and extremely difficult to pass around to different developers. Since it was only one person, there was no source code control, either. So not only were we converting to using Maven, but adding SVN as source code control, too.

Using a lib/ directory with all your dependent JARs is a tried-and-true method that I've been using for years. It's frustrating, though, because of the reasons stated in this thread. I didn't like keeping JARs in SVN because of the file size, and because it was just extra stuff that had to be copied around. One copy goes in the lib/ directory of the Java project and one copy goes into the WEB-INF/lib/ Or maybe you could do some magic with libraries and classpath settings in your IDE to only keep one copy around, but what if you wanted to compile from the command-line because your working copy is checked out on a Linux box that you only have SSH access to? And nary an IDE in sight?

I wanted a project that I could compile from the command line with the same ease of use of hitting Ctl-S in my eclipse IDE. I also wanted a project that was portable enough that another developer could check out a fresh copy of the project, do one command, and have a built project. And I didn't want them to have to manually set up special libraries or classpath dependencies in their IDEs because we are using different IDEs (different requirements for different developers).

So instead of having one monolithic package that required special manual configuration to build (NetBeans uses Ant, so you *could* compile from the command line after you updated the project dependencies...assuming you can run NetBeans, etc...), we now have a Java project that contains ONLY the Java source code and a POM file describing the dependencies and a webapp project that contains a reference to the artifact built by the Java code. When it comes time to build a WAR file for distribution to the app server, all that is required is one command in the webapp's project directory, which packages the WAR file and includes all the dependencies of the Java artifact (except for the ones I tell it not to include) even though I only specify one dependency (the custom Java artifact) in my POM file.

The process now is very, very simple because of Maven:

svn co https://mysvnrepo/java
svn co https://mysvnrepo/webapp
cd myproject
mvn install (puts Java artifact in local repo...deploy puts it in our Archiva repo)
cd ../webapp
mvn package
cp target/mywar.war $APPSERVER/deploy

There are other deployment options, too, including installing the WAR into the Maven repository for the project. That's just a quick example.

Now I can check out a fresh copy of the project into eclipse or NetBeans (where the Maven plugin is installed) and the classpaths are already set for me. No updating of special libraries or fixing classpath errors (well, the eclipse Maven plugin is a little smarter than the NetBeans one...you have to run the compile goal manually the first time you load the project to force Maven to download those dependencies for you...eclipse takes care of that).

When I create a new webapp that requires the Java artifact, we can just create a new Maven webapp project and put in the dependency on our custom Java artifact (a few lines of XML) and our webapp will contain everything we need to run it in the app server.

I've managed projects using only manual processes (the most flexible and definitely for the control freaks), using Ant (better, but still a lot of XML to be editing, creating from scratch, copying, whatever...have you ever looked at a NetBeans build.xml file?? yikes!), and with Maven (less XML, fewer "things" to worry about). Maven saves me time and lets me focus my energies on writing code and fixing problems. It keeps me from having to expend time and mental energy on the actual process of getting a usable product out of my code.

I'm not a control freak. I'm more than happy to let software (that I didn't write and I just use for free) written by people a lot smarter than me do it for me so I don't have to think about it. I don't get paid to manage build processes, I get paid to write code and solve real-world problems. Maven helps me do that.

Maybe this helps Gregg, maybe it doesn't. I only know what works for me and I can only articulate the reasons I use Maven.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

Thanks for the info Jon but you are still considering some things complicated that you claim maven solves that really aren't complicated problems at all. Here are the steps to checkout, build, and deploy one of my projects..,.

svn co http://pathtoproject/repos/foo
cd projectFolder
ant -lib lib deploy

I didn't like keeping JARs in SVN because of the file size,

Yea, those 100kb JAR files are monsters aren't they.

One copy goes in the lib/ directory of the Java project and one copy goes into the WEB-INF/lib/ Or maybe you could do some magic with libraries and classpath settings in your IDE to only keep one copy around

Actually I keep a development lib folder and a deployment lib folder. For a webapp the dev lib folder is typically at the top level called lib. The deployment lib folder is right where it belongs under WEB-INF. No duplicatation of JAR's within the project though there would be duplicate
JAR's across projects.

but what if you wanted to compile from the command-line because your working copy is checked out on a Linux box that you only have SSH access to? And nary an IDE in sight?

If you can assume Maven is on this box since this is how you grabbed the project in the first place, it is safe to assume ant is also on this box and you can see my example above for building from the command line.

we now have a Java project that contains ONLY the Java source code and a POM file describing the dependencies and a webapp project that contains a reference to the artifact built by the Java code.

I don't really even know what to say to this. Why keep your java code that seperate from your webapp artifacts?

all that is required is one command in the webapp's project directory, which packages the WAR file and includes all the dependencies of the Java artifact

So does mine, without Maven.
Jon Brisbin
Greenhorn

Joined: Jan 03, 2008
Posts: 2
I didn't know this was a Maven vs. Ant pissing contest.

Well, my process fixes me breakfast (when I eat it) and desert for dinner.

So there.

Just because I want to be snarky, I'll continue this discussion, but don't go getting your hackles up and summon the BeNiceGestappo on me or anything. The following is intended to be HUMOR:

I think, just because I want to prove, beyond a shadow of a doubt, that my process is the ONLY one that has EVER made any sense as a build process, I'm going to write it all using shell scripts. You won't even have to type any commands. Just one letter. "d" for deploy and "c" for compile. No enter or anything, just the one letter.

And the spare CPU cycles are being used to find aliens in other solar systems and summon them to take us all to their much better universe on their shiny ship.

So there.

I use Maven. It helps me. It does more for me than Ant and requires less babysitting. If you don't like it, fine. Use whatever you want.

And I don't think that a comparison between the number of characters required to initiate a build is necessarily a measurement of that process' superiority.
Gregg Bolinger
GenRocket Founder
Ranch Hand

Joined: Jul 11, 2001
Posts: 15299
    
    6

It's not an ant vs maven thread. But you said maven makes it easier. I was just pointing out that not using maven is just as easy. And my means happens to be ant.
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
I used to like Ant because it made things more manageable, understandable compared to the custom shell scripts I'd been used to before that.

These days my first choice is Maven because it makes certain things more manageable, understandable compared to the Ant scripts I'd been used to before that.

I happen to love the Maven Standard Directory Layout. At first I was hesitant because I would've named the directories differently etc. but then I accepted the logic and decided to simply enjoy from the benefits of having a standard.

I also happen to love the way Maven downloads the dependencies for me. Part of it is the transitiveness (no need to declare indirect dependencies in a build file) but part of it is that, most of the time, I can just type in the snippet into my POM file, run Maven, and get the new dependency into my project without going online to click through various download links. And when I do need to do that, I can just go to mvnrepository.com and search for what I want.

I also happen to love how Maven lets developers use either Eclipse or IDEA without the burden of having to manage separate project files for both tools. Prefer Eclipse over IDEA? Just type "mvn eclipse:eclipse". Don't fancy the IDEA user interface? Just type "mvn idea:idea". That simple.

I've seen horrible, horrible build scripts written with Ant and I'm sure there will be a time when I face the same atrocity being committed with Maven. So far, however, Maven is doing the same for the Java build script community what Rudy Giuliani did to New York. Clean it up. Exceptions exist, I'm sure.

Now, having said that, there are things that are painful with Maven. That shouldn't be anything new. Few successors to a software tool are perfect, just a bit better. And in many cases that difference is highly subjective.

So if Maven is currently number one on my list, what's number two? I don't think it's Ant. I think it's Buildr. That is, if I want a scripted build (as in with Ant's "quasi-declarative but effectively imperative XML" approach), why not use a proper scripting language? I haven't used Builrd in anger, yet, but it certainly is a promising candidate, providing a programmable front on top of the Maven infrastructure.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Maven: What's the big deal?