Step 1. Create a maven project with war packaging
Step 2. Run mvn eclipse:eclipse
Step 3. Open Eclipse. It’s not a dynamic web project.
Step 4. Yell.
Step 5. Look things up on Google.
Step 6. Try some of the things you find on Google.
Step 7. Yell some more.
Step 8. Create a dynamic web project and configure all your libraries by hand.
Step 9. Run web app on server within Eclipse.
Step 10. Go back to Ant and get things done.
I mean seriously, I can’t believe it’s this hard to take a web project and have the eclipse:eclipse task build out an Eclipse project (Eclipse 3.3) that will deploy into a Server instance to make it easier to run/debug.
I’m sure some people have it running but if it’s not relatively simple or documented more clearly or findable on Google within the first page or two then I’m sure I’m not the only one that has thrown up their arms with Maven and use within Eclipse.
On top of all that, just try learning this thing and using it with a Hibernate based project and having to go out and hunt down all the plug-ins you need to make your project do what you want it to do. Any project that makes me do this much hunting around to get it to do relatively simple things that I can do in Ant really quickly is just not going to succeed. The sad thing is that most of the initial impression problems are solvable but no one that is a Maven fan seems to be doing anything about it. Just take the ten or so most popular open source projects, throw a cookbook style doc out there that tells you how to quickly integrate the plug-ins for those projects and do common tasks and you’ll get people that will spend more time trying to use it. As of now, virtually none of the developers I know will use Maven.
(note:Β I wrote this up about a month ago and just got around to publishing it so maybe it’s been fixed, maybe it hasn’t but I’m tired of trying to make it work for other reasons as well)
I wrote software for over two decades before becoming a full time build engineer.
That means I compile other people’s code for a living. π
On a daily basis, an aspect of my job is making over 100 continuous integration builds work correctly
All but 2 of those builds are Maven based, so I have some regular exposure to this issue.
I did the first 3 steps that you stated.
I looked at the maven eclipse plugin.
I followed the steps for getting the M2_REPO variable added to my workspace.
I had an eclipse project that would compile. In order to package it, I had to use Maven.
Nothing’s been fixed at this point, because nothing is broken. Let’s mark this one “Performs as expected”. Maybe one day the eclipse pluging will try to modify where the basic Eclipse web tools looks for web content, but probably not anytime soon.
Why would you think it would build a Dynamic Web project?
The eclipse plugin builds the settings in eclipse for compiling your code. If you want it to integrate to {insert your plugin mashup here}, that’s an entirely different problem, clearly not covered by the eclipse plugin, as documented [1].
Maven may not be for you. As a tool, it’s more of a philosophy, and its documentation leaves a bit to be desired. Maven is primarily for managing the build/test/deploy cycle on the command line or within a CI tool, and the philosophy centers around convention over configuration. The Eclipse integration isn’t really spectacular once you’re making something that isn’t JAR packaging. Things can get complicated with web projects, for instance, since there’s little or no incentive for anyone to attempt to map to the lastest of the eleven million iterations of various web development plugin collections within eclipse. I did recently manag to make a 3.3 Dynamic Web project integrate with maven, but it took quite a bit of work. Maven doesn’t actually do the builds for the developers for the most part. It just does the continuous integration and release builds.
If Maven’s brand of “convention over configuration” isn’t for you, I might suggest Ivy [2]. Ivy will do dependency resolution within Ant reasonably well, which is generally all coders are interested in maven for anyway, and you can specify where the dependencies will go within your filesystem. Then just add a library within your eclipse project that is that directory. Of course, there’s very little in the way of reporting done by eclipse natively (ie. none). And whatever poor soul is responsible for your release engineering [3] will probably have more than a little difficulty. But you should be able to figure out something based on RLENG with the documentation for that, which IIRC is pretty good.
[1] http://maven.apache.org/plugins/maven-eclipse-plugin/
[2] http://ant.apache.org/ivy/
[3] http://en.wikipedia.org/wiki/Release_engineering
Unlike you Maven doesn’t drive me crazy. I really like the consistency it brings across projects. All source, JSPs, property files, etc are always in the same location, making it easy to work on several different projects without having to get familiar with each project’s web site.
I agree with the point that making a web tools project from Maven is a big pain.
NetBeans has a Maven plugin that will load a Maven war project and it will automatically be recognized as a web project, all expected completion, behavior, deployments, etc. will work out of the box.
NetBeans 6 comes with Eclipse keybindings out of the box (the bindings are not perfect, but the missing ones can be added, see http://www.jroller.com/heffel/entry/netbeans_6_0_eclipse_keyboard), therefore the trainsition from Eclipse is fairly painless. I suggest you give it a try. http://www.netbeans.org/community/releases/60/index.html
Mykel, I think you’re right. Maven probably isn’t for me. While I like the idea of what it can bring to the table, the cost that it incurs doing that is too much for me. I know Ant well enough that I can stay very productive with it and focus more of my time coding and investigating other frameworks that let me code faster. Plus, since I tend to experiment a lot with newer packages they don’t always get into repositories quickly and I really get annoyed with having to put things into and maintaining my own repositories in that scenario. Builds just don’t cost enough time in my environment to be worth the up front costs.
As far as the Eclipse plug-in goes, it’s just a shame it doesn’t support the current web tools version. I’m not a huge fan of web tools by any stretch (I’ll comment on David’s post next) but like a lot of Eclipse users I don’t want my build platform to get in my way, and unfortunately in this case, it does.
Hi David, I agree that I like the idea of consistency it brings, especially in its generated documentation.
I just can’t get past the fact that it’s near impossible (or at least in the amount of time I’ve spent on it) to have my environment automagically see new libraries/versions as they come into the Maven project. Sure, they are there for the build but I have to code in an environment and unless the IDE project can bind directly to that vs. having to generate the environment then it’s just going to suck, err, be not good.
We’re going to be looking at IDEs soon since Eclipse is driving me crazy. I used to like it but I just don’t know what they’re thinking with the multiple navigation panels, right click to create a class that takes like 5 clicks from package explorer, SWT crashes on Mac (leopard), inability to do auto-import when there is a compile error (i.e. when I’m typing!) and so forth. I know IntelliJ really well so we’re going to look there and I’ve heard good things about NB 6.0 so we’ll take a look at that also.
The maven m2 plugin for Eclipse “sort of” works, but with JEE projects it’s STILL a monstrous pain. My verdict on it is that it still doesn’t work well enough.
I love the NetBeans way of building (everything with a build tool). The NB maven integration is way better that Eclipse (because Eclipse considers itself an island) and you can make Maven do your NB builds basically in the same manner that it uses it’s internal ant builds. I’d suggest making some use of it before ditching Maven entirely.
The great thing that I currently have with Maven is that my builds basically fall into one of a few categories. Maven with Xdoclet, Maven without Xdoclet, Ant and non-tool. The one ant build is completely out of control. It was built by an offshore team who clearly didn’t understand anything about portable builds. The one untooled build is handled by a MS batch file with MS specific elements. This makes it currently un-integratable with the CI system since that system is running on Linux boxen.
The remainder (100-ish) of my builds are Maven based. They have between 2 and 4 levels of parent POMs and are thus generally completely configured by the time the actual component-level POM is built. I enforce a pattern in source control that allows the SCM tags to be built within the parent POMS. Release time for a given artifact is usually about 5 minutes start to finish. All dependencies are cached in an internal repository using Proximity. Nobody on the internal network ever makes a call directly to the internet. Management is satisfied with our security and all I have to do is occasionally check on the build farm boxen.
FWIW, I’m writing something on socialism in software development and how it specifically applies to the parts of software that aren’t the code-monkey elements. I’ll post a link when I finally get it done. Reasons for choosing a build system (like Maven or even a controlled ant build) are expounded in it.
Why are you even using maven and eclipse!!
One word my friend…Netbeans 6!!
try using 6.2 beta version and say goodbye to ‘finding * using eclipse plugins’
Yeah, you said it, Eclipse and Maven don’t play well together. As other’s here have posted, Netbean 6 has excellent Maven2 support. BTW, IntellliJ IDEA 7.0 also has excellent Maven2 project support. You might want to give one of them a try.
I started switching most of my projects over to Maven from Ant Ivy last year. There was a lot of pain initially as I learned Maven, but now I use it for all my Java projects.
Socialism in software development? I’d like to see that post!
use m2eclipse
mvn eclipse:eclipse -Dwtpversion=1.5 or mvn eclipse:m2eclipse -Dwtpversion=1.5
http://maven.apache.org/plugins/maven-eclipse-plugin/m2eclipse-mojo.html
mp is right !
Either you run :
mvn eclipse:eclipse -Dwtpversion=1.5
or much better, include it in your pom.xml and tell maven to get the sources of the dependencies too π
org.apache.maven.plugins
maven-eclipse-plugin
true
1.5
Maven Rocks π
Sorry for the previous comment, we can’t see the xml. Here it is :
$lt;plugins$gt;
$lt;plugin$gt;
$lt;groupId$gt;org.apache.maven.plugins$lt;/groupId$gt;
$lt;artifactId$gt;maven-eclipse-plugin$lt;/artifactId$gt;
$lt;configuration$gt;
$lt;downloadSources$gt;true$lt;/downloadSources$gt;
$lt;wtpversion$gt;1.5$lt;/wtpversion$gt;
$lt;/configuration$gt;
$lt;/plugin$gt;
$lt;/plugins$gt;
Sorry for the previous comment, we canβt see the xml. Here it is :
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-eclipse-plugin</artifactId>
<configuration>
<downloadSources>true</downloadSources>
<wtpversion>1.5</wtpversion>
</configuration>
</plugin>
</plugins>
Last time I tried the wtpversion 1.5 stuff above it did not create a real web project which meant I couldn’t deploy into a server for easy development/testing/debug cycles in eclipse and it didn’t function with the rest of the current web tools project, either. Eclipse 3.3 and the accompanying WTP tools were in development for a long time. The change in Eclipse configuration files from the previous version was not that big. They should have had it working before the tools even went final. People use IDEs, they depend on using them and if your build tool gets in the way from using one of the more popular IDEs and plugins that is necessary for web development then the tool is going to be fighting a huge uphill battle in the minds of developers.
It still comes down to the fact that it’s just too much of a pain to use it on projects and I can’t see the payoff outweighing the costs it incurs in increased development overhead. Maybe there is a way to get it there but it’s not clear enough or documented enough to make it work.
If Maven wants to make more inroads it has to get better documentation and a standard set of plugins that are well defined and referenced somewhere from the primary maven site. For example, check out this link: http://maven.apache.org/plugin-developers/cookbook/index.html – Coming Soon! Great. Then you go here: http://maven.apache.org/plugins/index.html and no plugins listed for Hibernate. Hibernate is just an example and a sore spot but just about every project I’ve worked on that uses Hibernate (and there are a lot) needs to use the hbm tools somewhere. So you go and search for one and you find one here: http://mojo.codehaus.org/maven-hibernate3/hibernate3-maven-plugin/ and it’s documented…let’s just say, poorly.
You can very easily create a Maven project and import it in Eclipse and then use it within Eclipse for deployment and testing. I’ve written about it:
http://moritzpetersen.de/index.php/archives/2007/10/11/maven2-eclipse-and-apache-shale-part-ii/
Apache Shale is just an example, you can do it with every Maven Project.
Regarding Hibernate: When using hibernate-entitymanager, all dependencies are added automatically. All you have to do is:
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.3.1.ga</version>
</dependency>
You are right, documentation is poor, as it is with many up to date technologies. Hope I could help a bit.
@Moritz
That’s not what I’m talking about. I realize how easy it is to bring in the Hibernate entity manager or hibernate core. I’m talking about the Hibernate tools that can be use to generate code or to generate the schema from your Hibernate configuration. There are plugins required for that which are a true pain to use.
Ah, right.
I am using Maven at my work currently. We were using Ant at one point of time. But we migrated all our builds from Ant to Maven. The biggest reason: Not every Java developer is an expert in build scripts and not every company can afford to have a build engineer. And we didn’t want to spend a bunch of time creating and maintaining builds. And we certainly didn’t want to spend time doing a copy/paste/edit/save when we created a new project. Therefore we needed a build tool that could be easily understood and quickly adopted by our developers.
Now I like Ant and for a small subset of projects, it’s a great tool. With “macros” and “imports” you can do a lot with Ant. You could hide the common functionality inside macros in a common build and have each project import them. Which we did. But we still realized we were baby-sitting the build scripts a lot. And it’s gets frustrating when one person is assigned the job especially when he or she isn’t primarily a build engineer.
Maven solved a bunch of stuff for us. Creating builds for projects was easy (archetype:create). One of the biggest benefits that showed quickly was the standardization of the project directory structure. Of course this has nothing to do with Ant. But with Maven, it just seemed easier to “coax” people into following a standard directory structure. That was half the battle won right there.
And once you exploit the inheritance and aggregation aspects of Maven using parent poms, it’s makes standardization even easier. In addition there wasn’t a build script you had to learn. For the most part the only changes that were done were addition/deletion of “dependencies”.
Now to be fair, I’ve had my share of “Why Maven Drives Me Crazy” moments. For instance the latest being trying to release projects with Maven. And I agree with you on the documentation. Some of the advanced stuff isn’t documented well. But once you figure it out, it’s not that bad.
And yes, the m2eclipse plugin for Eclipse isn’t robust. You may want to look at http://code.google.com/p/q4e/ as an alternative for the m2eclipse plugin. I haven’t started using it yet.
Anyway, going back to your example above of trying to create a web project – having to eclipsify a single project. If it’s your first web project that you are creating using Maven, then perhaps you have a reason to scream. But then on the other hand, you know Ant and therefore it’s easy to create a script. But wait until you have to create many more projects. Or you need to refactor your single project into many modules (smaller projects). That’s where in my humble opinion Maven shines.
As for your quote:
As of now, virtually none of the developers I know will use Maven
I don’t know if you are talking about the developers in your company, team, etc. But a lot of open source projects are using Maven or moving to it.
I completely agree with the author of this article. Using maven with eclipse is driving me crazy. Especially when it comes to creating a simple J2EE app with one EAR, WAR, EJB and Util project. The wtp support is damn poor. Even after maven eclipse plugin is run with the wtp option, the project does not appear to be a EJB or dynamic web project. I had to manually tweak the pom to add all the stupid nature and facets (jst.ejb, jst.web) etc. I like eclipse very much.. just a few clicks and within seconds the project structure is neatly created. Of course I agree with Maven’s philosophy and would love to use it.. But lack of proper support in eclipse is just @#$%. I tried m2eclipse and the maven eclipse from apache.. both sucks… If eclipse fails to recognize the project as EJB or web project… the option of using wizards just disappear.. and i have to manually identify each and every jar and add it. Then eclipse becomes comparable to a text editor sans colour and views !!. With Maven gaining lot of popularity, its better that the folks at eclipse take the integration more serious. I heard that Netbeans is having a great support to Maven.. So I am off to using Netbeans.. One eclipse fan minus…
build a bridge and learn to use maven, like how you had to learn how to use ant.
i guarantee it will take A LOT less time to learn maven than ant.
I thought maybe this could help shed some light. I had to put together a document at work to explain why maven. You can read it here. Thanks to all, haters and the lovers both helped shape this document.
http://lukesamad.blogspot.com/2009/06/why-maven.html
Josh is right, Ant is a great program – my devlopment team are enthusiastic supporters. Maven can be very frustrating.