I’ve just release a new version of Maven Tools 4 Eclipse (Changelog). It fixes the two most pressing issues:
Have Fun!
1 Comment | 
Software | Tagged: Apache Maven, Eclipse, Maven, Maven3, mt4e | 
Permalink
Posted by digulla
If you have the source for the dependency, patching the code is simple: Just create a small Maven project that compiles the source with your changes. Since your changes are probably small, you need only a few tests: What’s the point to test the code that you didn’t touch? Also the build will be simple (just compile the sources for your need, no fancy resource processing/filtering).
But what if you don’t have the sources? Jakub Holý has a solution: Hacking A Maven Dependency with Javassist to Fix It
Leave a Comment » | Software | Tagged: Apache Maven, Javassist, Patching, Programming | Permalink
Posted by digulla
A few days ago, kingargyle posted about “Push Button Builds.” The idea is that building a software should be as simple as triggering a light switch.
A good example are Maven (mvn install) or most automake builds (configure && make && make install). They usually just work and if they fail, they give you some context to work from.
A good negative example are Eclipse PDE builds: Often there is no build script. If there is a build script, it will fail with an obscure error message in an Ant script that was recursively called by about 100 other Ant scripts. Each Eclipse project uses PDE but each build has different prerequisites (which you must know). If the build uses p2 repositories, there is no way of telling whether two subsequent builds will produce the same result. Some projects try really hard to help newcomers to build their stuff with a recipe that needs 100+ easy steps. In four words: It’s a mess.
Or a surefire way to attract only the most dedicated committers because everyone else will be utterly demotivated very quickly (and you don’t want those, do you? 
So like Dave Carver, I would like to spread the idea. Make builds more simple. Here is an example and following Dave’s advice, I’m going to make the build script even more simple.
Why a script and not, say, a web site with instructions? Several reasons:
Leave a Comment » | Software | Tagged: Apache Maven, Build Management, Continuous integration, Eclipse | Permalink
Posted by digulla
Note: This post is now obsolete since there is a newer release.
I just finished a new release of Maven Tools 4 Eclipse. It’s not written in Groovy and supports all the features of the old Python version plus a few new ones.
You can find instructions how to use it on the wiki page.
For now, you need to build the tool from source (which needs 1.4-SNAPSHOT from DecentXML) using Maven. I’m in discussion with the people at Eclipse to get a download link for the binary.
Update: The project page now has a download link.
9 Comments | Software | Tagged: Apache Maven, Eclipse, Maven, mt4e, Project Dash | Permalink
Posted by digulla
If your Eclipse IDE suddenly crashes with an error in java.util.zip.ZipFile.getEntry() chances are that you’re hit by this bug: Crash in ZipEntry when some other process changes the ZIP File at the same time
Workarounds:
1 Comment | Software | Tagged: Apache Maven, Eclipse, Maven | Permalink
Posted by digulla
My Maven Tools for Eclipse (MT4E) project has now a wiki page: http://wiki.eclipse.org/Maven_Tools_4_Eclipse
And I’ve started to convert the tools from Python to Groovy.
Leave a Comment » | Software | Tagged: Apache Maven, Eclipse, Maven, mt4e, Project Dash | Permalink
Posted by digulla
I’ve recreated the testing repository using the latest version of my Maven Tools 4 Eclipse.
To browse the repository, please use the Nexus interface.
If you pull in any dependencies from the repository, non-Eclipse artifacts will come from from Project Orbit. If you want non-Eclipse dependencies (like log4j) from Maven Central, you need to change your profiles.
Deactivate “m4e.orbit” and activate “m4e.maven-central“. From the command line, that’s “-P m4e.maven-central” but I suggest to put these into your settings.xml (add “<activeProfile>m4e.maven-central</activeProfile>” to it).
Note that you don’t need to deactivate the profile m4e.orbit. As soon as you specify a profile on the command line or via the settings, it’s deactivated automatically.
“mvn help:active-profiles” and “mvn dependency:tree” are your friends.
Let me know if you find anything missing, odd, broken by filing a bug or posting a comment here.
Some dependencies from the new repo can also be found on Maven Central. One nasty problem is that both repos contain org.eclipse.equinox.app but the version from Maven Central contains odd dependencies which break your build.
To fix this, add this to your parent/root POM:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.eclipse.dash</groupId>
<artifactId>dependency-management</artifactId>
<version>3.6.2</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencies>
<dependencyManagement>
This will limit all version ranges to the versions found in our new repository. Since Maven Central didn’t import new versions for at least one year, this should fix all problems.
Related posts:
Leave a Comment » | Software | Tagged: Apache Maven, Eclipse, Java, Maven, Maven2, Project Dash | Permalink
Posted by digulla
I’ve finished RC1 of my set of tools to import Eclipse plug-ins into Maven 2 repositories. You can find the source on github. It needs Python 2.7 and lxml. pip is your friend.
The new features: There is now a tool to analyze the M2 repository for oddities. Currently, it can find these issues:
Plus it prints a list of all POMs in the repo with files (jar, pom, sources, test-sources, …). Here is a sample report.
The last tool can create a POM file with a dependencyManagement element containing the versions of the POMs in the repository. You can use this to nail down all versions to the ones existing in your repository (so you don’t accidentally pull in something you don’t want).
Lastly, I’ve enhanced the patch tool. Instead of overwriting replaced dependencies, it will now move them into a new profile. This way, users of the repository can specify which dependency they want (the one from the repository or, say, one from Maven Central).
I will try to build a new testing repo over the weekend so we can start wrapping up the necessary patches for a release.
Related posts: Eclipse 3.6.2 Artifacts for Maven 2
2 Comments | Software | Tagged: Apache Maven, Eclipse, Java, plug-ins, Project Dash, Python | Permalink
Posted by digulla
I’ve added a new feature to my Maven tools for Eclipse: Applying patches to POMs.
This is a first step towards solving issues like this one: Bug 342046 - Invalid third party dependencies in Mavenized BIRT plugins
I’m not 100% happy with the result, though. Currently, the patch overwrites the original code. I think it would be much better if it created a profile instead. This way, you could see the original code and it would be simple to switch between different solutions for a problem in a POM.
The two standard problems are:
The latter is introduced by the fact that Eclipse projects need to pull dependencies via Project Orbit. Orbit often renames dependencies so there is a naming conflict if you pull your dependencies from Maven Central. So we need a way to say “I’m using Orbit” and “I want Maven Central”.
1 Comment | Software | Tagged: Apache Maven, Eclipse, Java, Maven, Maven2, Project Dash | Permalink
Posted by digulla
Image via Wikipedia
Update: The project has its own web site, now.
Two days ago, I told you about Project Dash and my new tools for it. Well, we did run them over the weekend and import a lot of stuff from Eclipse 3.6.2 into a brand new testing Maven 2 repository.
So if you want to use Eclipse bundles in Maven 2 for your own projects (SWT, EMF, even BIRT), have a look and let me know:
Making the world a better place, one line of code at a time! 
The tools are here.
New project home page: Maven Tools 4 Eclipse
6 Comments | Software | Tagged: Apache Maven, Eclipse, Maven, Maven2, mt4e | Permalink
Posted by digulla
