tags:

views:

1282

answers:

10

I have a side project I do = in Java. It's a pretty straight-forward webapp. It runs in Tomcat on a Linux Server and uses a MySQL database. The majority of the code was written with the Spring Framework. It has a lot of Unit Tests in place. When I'm coding it's in Eclipse. When I deploy the application I run a few shell scripts to move a WAR file to the web server, do Database updates, and make changes to apache configs. I'm the only developer working on it, and right now it's only deployed to 1 environment(production), although some day I might want to have a testing or staging environment as well. I use SVN version control, via the Eclipse plug-in.

I'm always hearing about people using Maven for their projects. Since so many people are using it, I'm saying to myself it must be good. I'd like to learn it in my spare time. The only thing is I'm not quite sold on why I'd want to use Maven? Does my first paragraph sound like a project appropriate for Maven? Does it have any specific advantages for a project that interacts with a Database?

+5  A: 

I'm using maven in anger at work. It's a harsh mistress. It makes things easy as long as you're doing things many other people have and, this is important, as long as you're doing them the way maven thinks you should be doing them. Step off that narrow path and it will fight you every step of the way.

I've been impressed by BuildR from using it on the side. It's flexable like ANT while leveraging maven's dependency system. Also, it's in incubation, so it's a little rough around the edges.

sblundy
Maven's main premise is "Convention over Configuration", meaning they are doing all the work for you, if and only if you're submitting yourself to their (common and generally easy to live with) convention paradigms. Shoehorning old projects into maven is often fraught with disaster for this reason.
Spencer K
@Spencer K: Conventions are a good idea. The problem with maven is that it's myopic and inflexible.
sblundy
+2  A: 

We do exactly what you do in our projects, and we use maven. You'd want to use maven to have a standardized layout and way to build your project. You never have to store all those jar dependencies in SVN or keep them somewhere special, maven does that for you. Maven also serves as a means to get other developers to understand your project easily. Once you start using it, you'll never want to look back :)

neu242
Does it do anything specific though for a DB-driven web application? For example, does it do anything to run a Database script, or update Apache rewrite rules or anything.
bpapa
We use maven together with dbunit (http://www.dbunit.org/) to run database scripts (initialize tables, populate db). Maven really doesn't do anything special, it's dbunit who does the work.
neu242
+9  A: 

Maven would be a good fit for your project IMO. Maven is an all around build and deployment management tool. It's biggest strength is that it makes build scripts significantly eaiser to maintain than functionally comparable Ant files or shell scripts.

There are a lot of advantages to using maven the biggest being it's preference of convention over configuration. This means that if you have your project laid out using the Maven directory structure there is almost no configuration required to get it building and running your JUnit tests.

The other big win that Maven gives you is dependency management. You can decoratively define your project's dependencies in Maven's config file called the Project Object Model (POM) and Maven does the work of storing all the jars in a local directory structure that it maintains. In the case of publicly available artifacts the jars are automatically downloaded from the Maven central repository and in the case of internal or proprietary 3rd party jars you can install them into your repository with a single command.

In addition to just organizing these artifacts and automatically setting up your build classpath to include all the necessary jars, maven will also manage dependency hierarchies. That means that if your project depends on jar A and A depends on jar B, jar B will automatically be bundled with your WAR even though you don't explicitly list it as a dependency in your build config.

Also, I'll say from a professional development standpoint it makes sense to learn Maven since in my experience Maven has overtaken Ant as the de jure build tool of choice both in open source and proprietary Java projects.

All this being said, if you have a build system that is fast and reliable for you, then it might not be worth the effort to convert over to Maven just for the sake of using the same tool everyone else is.

Mike Deck
+5  A: 

Maven would be just fine for what you want to do. Unlike most build tools, maven uses conventions wisely (well, better than many others at least), and it has "plugins" for every area you mentioned:

Unit tests: maven surefire plugin

Eclipse Integration: m2eclipse

Deploying WAR file: WAR plugin and Deploy plugin

Maven can also help you in integration tests on Tomcat (if you have some), since you can start, stop or deploy a war using the cargo plugin.

Anyway if you're planning to read in your spare time, here's a free book (PDF format): Maven the definitive guide

Hope it helps!

Pablo Fernandez
The sonatype book is quite good, and a must read if you're doing serious maven-izing.
Spencer K
+6  A: 

Your project does not sound like a project appropriate for Maven. You seem to have a working development environment. Why set up another one? It will just give you one more project file to maintain which breaks the good ol' DRY principle.

Arne Evertsson
I'd agree, though this would be a good opportunity to learn the differences between the existing environment and the one developed in maven.
Spencer K
+2  A: 
anjanb
+1  A: 

Don't. See what other people are saying, and research carefully. Also consider looking at some of my other comments on Maven here on SO.

Rob Williams
A: 

I used maven for dependency management some time ago, because I was tired of adding all the jars, if I wanted to test it on another box or so. You don't really have to 'learn' it for this, it doesn't take much time until you learn it.

However the easiest thing would be to just ask somebody who already knows mvn, so he can show you how it works and then you learn it quite fast.

Nils
+2  A: 

I once started a new temp job that was using Maven. Burned 2 days trying to figure out how their maven build worked. Turned out they were all using maven 1.01 on windows, and I'd been inadvertently trying to build on 1.02, so it didn't work for me. No one in the place new how it worked, and they'd been using it for months and they were happy with it. A few months later on the same project I had to dig deep into the jelly scripts to change a single build variable. It was not fun.

When I first started using it, I read "convention over configuration", and "uses a standard set of directories". These were not anywhere I could find on the docs. I guess you were supposed to guess.

My opinions:

  • any tool you use that you don't completely understand is a mistake, and a potential boat anchor to your development process. If the tool is really, really complicated, you're liable to use the simplest parts of it rather than mastering it deeply. If you're not using or shying away from the most powerful parts of the tool, you're likely defeating the purpose of using it.
  • Maven is a classic example of something so full of automagic goodness that you don't have a clue what it's doing unless you dedicate far more of your time than a build tool deserves to becoming a maven maven. An over-engineered solution in search of a problem.
  • I did not find any instances of things I needed to do that I couldn't do with ant and needed maven for. I know there are some, I just never needed them. If I did I'd probably be more charitable regarding the effort required to deal with maven.

May have gotten much better, this was, to be fair, about 2 years ago. I know I am being unkind. Nevertheless, I hated it (can you tell?)

Steve B.
A: 

One of Maven's great strengths is that it does a lot of the build/dependency management without you writing any build scripts or having to even describe your build process. You already have your project setup so you won't benefit from Maven setting up the project shell for you or downloading the dependencies you specify with out you having to download them individually. If your goal is to learn how to use and administer Maven then doing so for a project like this where there are no other developers and the build process is very simple (from what I can tell) is not going to help much either. So I would recommend against using Maven for the existing project.

I would however setup a simple test application similar to yours using Maven and compare it to your project's structure to see if you follow best practices(at least as the Maven developers see them) and if your application follows standard web application conventions.

neesh