//log//

Once you get back to trying… After using NetBeans IDE for the past couple of years mainly (even though not only) for its excellent support of projects based upon the maven2 build tool, right now I am into developing an Eclipse RAP based user interface, thus using (obviously) Eclipse IDE for this purpose. As running two IDEs in parallel has some drawbacks (the code you need always is in “the other tool”), I wanted to figure out whether, by now, it makes sense to use Eclipse altogether exclusively just for this project, thus being back to maven2 tooling again. Oh well, let’s see…

First impressions

Starting with the good things… By now, using Sonatype m2eclipse, Eclipse maven2 support has somewhat improved the last couple of years:

• Asides “Run as” -> “maven …”, Eclipse now seems to be able to build maven2 projects along with a straightforward workspace build / cleanup, which is really rather helpful (and actually something one would expect… 🙂 ).
• There now is a quite powerful editor for maven2 pom.xml files which, as I have to admit, in some situations even outperforms the tooling provided by NetBeans especially when it comes to displaying dependency graphs and dependency hierarchies. The various visual editor pages also help getting closer to the full maven2 feature set if you do not want to dive all too deep into the pom.xml syntax and/or are just learning…

Likewise, there is a whole bunch of features how to “import” maven2 projects into Eclipse, also (as I think) partly due to the fact that Eclipse, unlike NetBeans, can’t simply “open” a maven2 project simply using pom.xml as the only piece of relevant information but rather requiring its custom configuration files in the project structure to be happy. So, I tried to import and get started with my maven2 projects… So far, this is an SVN trunk consisting of about 55 mvn2 jar/war/pom artifacts, which I was about to check out and import into Eclipse.

Second impressions

And this prove to be fun, for sure. First shot, most straightforward, using “Import” -> “Maven” -> “Check out Maven2 projects from SCM”. Browsed to the repository trunk, let it check out all the project, and they’re here… and they’re all red? Well. It seemed that, with checking them out of SVN, Eclipse did for each project assume to enable project specific Java Compiler settings, thus forcing them to be Java 1.4 compliant each (and ignoring what’s stated in pom.xml explicitely). Fine. Resolving this was work no less than manually changing this setting for each of the projects in question. Following this, at least some of the projects didn’t have problems anymore. The whole mess built until I eventually trashed one of the project. Well, no problem – delete it, check it out again – and see the main project failing to build?

It took a few moments to resolve what happened: My main project is a maven2 pom project containing modules like this:


<modules>
<module>../moduleA</module>
<module>../moduleB</module>
<module>../moduleC</module>
</modules>


and is referring to modules living in the same folder on the same level as this core / build pom. However, Eclipse maven2 tooling did check out all the projects initially to a folder like workspace/maven.1259135232603, thus having them all in one place. Deleting the project (not much of a surprise) removed it from this folder. Checking it out again, however, created a new folder in workspace (workspace/maven.1259151842736) and checked the project out to there. Well… I have no real understanding why this happens, and so I wouldn’t want to say it simply dumb, but at the very least in this situation it’s a behaviour highly undesirable, and I really would want to at least be capable of having this configurable. Yet, so far I fail doing so. Did, however, commit the changed projects to at least hope to have the Eclipse metadata relating to the Java Compiler settings stored along with the project.

Anyway, so let’s test another stragety: Eclipse also allows for importing existing maven2 projects, which basically just does create project related metadata in the workspace but keeps the project code wherever it is. So, manually checked out the SVN trunk to some arbitrary folder, used Eclipse to import things, saw my projects, did the same settings as above (setting Java Compiler to not be project specific… – so obviously they are kept elsewhere but in the actual project itself), built. Worked. Tried to commit the projects to SVN – to see that, this way, even though there are .svn metainformation in any of these project folders, Eclipse fails to recognize these projects as “versioned” so the only thing to be found in “Team” menu is the usual standard (“share projects” / “apply patch”). No way of reconnecting, no way of committing. Of h***. :/ So back to the initial approach, let’s just hope we don’t have to delete and checkout any project anew…

A few hours later, I am frustrated beyond belief as many features one simply takes as granted in NetBeans don’t seem to work in Eclipse:

• Even though some of the maven2 artifacts are war applications, Eclipse WTP obviously fails recognizing this out of the box, i.e. without fiddling with the project metadata, so all the code in src/main/webapp is just available via generic folder browsing and there is no real meaningful webapp tooling available to these projects.
• Classpath detection seems somewhat broken: In many situations, maven2 projects (and Java classes inside) are marked as broken because classes can’t be found, yet running a maven2 build on these projects works flawlessly and the project also has the required dependencies at hand.
• In some situations, even though I am not sure who’s to blame for that, projects checked out of SVN were listed as “unversioned” in the project explorer, yet the SVN metadata were there and trying to share them ended in a reconnect (no surprise).
• In another peculiar situation, the pom.xml editor kept me from deleting a dependency – no matter how often I tried to cut the corresponding <dependency> section – it always got back inserted into things. Resolved this by deleting and checking out the project again, see above.
• Having some projects that generate code off WSDL (JAX-WS) or XSD (JAXB) using corresponding maven2 plugins, it seems even though after adding the folder where the generated sources ended to the list of project source folders in Eclipse, the IDE seemed unable to actually find the generated classes on the classpath.
• There seems to be a general problem in redundancy of Eclipse metadata vs. pom.xml, ending up in information (Java Compiler level, “Java Project Facet” level, …) being entered more than once where, actually, pom.xml itself should suffice…

So here I am… my maven2 projects all in Eclipse, a bunch of them marked red, the whole mess building regardless of this but (obviously) code editing being somewhat difficult with not all classes correctly found on the classpath, and I know things feel somewhat non-deterministic. Maybe I have not completely understood how m2eclipse does a bunch of things. Maybe I’ll take a dive deeper to learn more about how it works, later… but now, and first off, I need to get work done, and by now I know the dissatisfactions arising from using two different IDEs are easier to address than the various troubles and issues arising from importing a complex maven2 project structure into Eclipse. Agreed, maybe most of my project structure could be set up more straightforward and “better”… but it works flawless in maven2 (which is at the core of it), and it works flawless in NetBeans maven2 tooling (which is on top of it), so it can’t be all that bad. And, in maven2, I just don’t want any more essential information (like Java Compiler version, …) placed anywhere but in the pom.xml, no matter which IDE in use… I’m off now to get all these .project files out of my SVN trunk…

Filed under: