Home > JavaEE > Better Maven integration leads to unforeseen consequences (bugs)

Better Maven integration leads to unforeseen consequences (bugs)

This week, I was faced with what seemed an near-insuperable problem. I was called by one of my dev: as soon as he upgraded his Eclipse (or more precisely, our own already-configured Eclipse), he couldn’t deploy to Tomcat through WTP. Here are the steps I took to resolve the problem and more general thoughts about upgrading and tooling.

The log displayed a ClassNotFoundException, one involving Spring. So, the first step is to look under the hood. Provided you used the default configuration – to use workspace metadata – it should be located under <WORKSPACE>/.metadata/.plugins/org.eclipse.wst.server.core/tmp<i>/wtpwebapps where WORKSPACE is your workspace location and i is an incremental number beginning with 0 assigned by Eclipse to each virtual application server in WTP. There you should see the applications deployed in Eclipse. When I checked, I realized the application was deployed alright, but found no WEB-INF/lib folder.

I had already experienced such deployment problems: I solved them by first forcing publish (right-click on the server and choose Publish) and if not successful, cleaning (it removes all deployment and starts again from scratch). Well, this didn’t work.

Also, sometimes classes are not deployed because there aren’t there in the first place: compilation doesn’t occur (because of bad code or Eclipse may be playful) and this prevents generating .class files. This didn’t seem like the problem but hell, this was a lead like any other. In order to force compilation, clean the project and check recompile afterwards (or check auto build is on). This didn’t work too…

It happened before that closing the project and reopening it resolved some code-unrelated compilation problems. Closing and restarting Eclipse may yield the same results. I did both to no avail. At this point, I was disappointed because all previous steps should have resolved the problem… yet they hadn’t.

Since the project used Maven (and we had m2eclipse installed), I also checked the Maven Dependencies library was correctly referenced: it was. Just to be sure, I disabled and re-enabled dependencies management. Guess what? Nothing changed.

Desperate, I hopelessly browsed through the POM and the following caught my attention:

<plugin>
 <artifactId>maven-war-plugin</artifactId>
 <configuration>
 <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes>
 </configuration>
</plugin>

This configuration creates skinny WARs so that libraries are not packaged in the WAR but are in the EAR, provided they are referenced, of course (for the right way to create such WARs, see my post from last week). With a faint gleam of hope, I removed the configuration part and it worked, the libraries were finally deployed.

Yes, dear readers, it seems newer versions of the m2eclipse plugin are able to parse some portions of the POM that were not parsed before and act accordingly. Although this is a good news in general, it means we have to carefully check about potential side-effects of upgrading to those newer versions. Of course, this was stupid to upgrade in the first place but think that sometimes it’s mandatory for a newer project.

However, the problem is much more widespread than m2eclipse. It’s very similar to issues adressed in Andrew Spencer’s post, only more so since if we don’t upgrade, we may have to keep an Eclipse instance for each project, that has to be shared between all team members. Right now, I don’t have any solutions for this problem, apart from changing the code to keep in synch with the tool.

PS : since we still wanted to have skinny WARs, I just moved the configuration part in a profile… which was what was configured in the archetype provided by the support team :-)

email
Send to Kindle
Categories: JavaEE Tags: ,
  1. September 11th, 2011 at 22:04 | #1

    Thanks for the mention!

    I’m now in a team which does manual Maven+Eclipse integration – no m2eclipse, no maven-eclipse-plugin, just a .project+.classpath and a POM managed in parallel, and we’ll just cross our fingers that we didn’t forget to propagate any changes from one to the other. That opens up a completely new set of ways to get bitten on the backside. Well, they have a CI build that picks up compile problems pretty quickly, but still…

    None of that is any help with the wider point of keeping code and tools in synch. But I thought it would amuse you.

  2. September 11th, 2011 at 22:25 | #2

    My amusement can be sumed up in 3 letters: OMG! Have fun…

  3. Fred Deniger
    September 13th, 2011 at 08:54 | #3

    Hi,
    I work in this team and the .project+.classpath are generated thanks to maven-eclipse-plugin. Currently these files are managed by the source control because of maven-eclipse-plugin that launch the aspect compiler before generating these files.

    Fred

  4. September 13th, 2011 at 09:00 | #4

    Current versions of the m2eclipse plugin should let you make without overwriting .project and .classpath. The culprit is in fact the .classpath and displays the Maven Library dependency: there should be no generation involved. You can test this: create a new Maven project and just replace the lines referencing each individual libraries by the one referencing the Maven Library. It should do the trick.

    If it works for us, it should work for you! Then you can trash maven-eclipse-plugin…

  5. Fred Deniger
    September 13th, 2011 at 15:06 | #5

    I’ll do Nico :-) after solving the problem of aspectj…
    I really want to trash maven-eclipse-plugin …and eclipse too

  6. September 21st, 2011 at 12:33 | #6

    You can find similar story here. Although context is a bit different, maven and m2e are still in the middle of the discussion…

  7. Christophe Vigouroux
    September 30th, 2011 at 15:30 | #7

    What’s good with eclipse and maven integration is that it creates plenty of work for architects/technical leaders, and lots of usefull blog posts (like this one, thanks Nicolas !). Well, after so much years of errance, as we seem to use maven as a central component of our developpement stack (dependency mangement, unit tests, CI, quality tools like sonar) perhaps we should consider using an IDE that is not a pain to use every day…

  1. No trackbacks yet.