Avoid Publishing SNAPSHOTs to Nexus

3. July, 2018

Once in a while I’m running into people who deploy SNAPSHOT versions of Maven dependencies to a company-wide Nexus server with a job on a CI server. This is usually a very bad idea, especially when using branches.

Scenario: Two developers, John and Mary, each working in their own branch. They push their branches, CI builds them and they end up on Nexus.

Problem: Nexus doesn’t know or care about branches. Whichever job finishes last wins.

Often, this is not a problem. Now let’s add another project B. B depends on A.

As long as B depends on a release of A, everything is fine.

Now, John needs to make some changes in A. So he updates the dependency in B to A-x.y.z-SNAPSHOT. Everything is still fine, since Mary still uses the latest release of A.

Then Mary also creates a feature branch in her clone of A. That still doesn’t break anything because Maven caches SNAPSHOTs for a day.

The next morning, John makes a change to B and builds it.

This build might break when Mary’s CI job finished last!

The problem here, which can go unnoticed for years, is that Maven silently downloaded Mary’s version of A onto John’s computer and used that to compile. John will see the source code from his branch of A but the binaries will be something else.

Eventually, one of them will make a small changes which affects the others project. They will see MethodNotFoundException or get strange compile errors while the source code (which isn’t affected by this) will look perfectly fine or unit tests will break in odd ways.

That is the main reason why you shouldn’t deploy SNAPSHOT branches to a shared Maven repository: It creates a small chance for subtle bugs which will take a long time to find since your mental model (“I see the source, this is what I get”) will be wrong.

You can get away with publishing the master branch to Nexus (i.e. only a single branch with SNAPSHOTs will ever be published to Nexus).

Note: If your CI server shares local Maven repositories between projects, your builds can fail on the CI server for the same reason. Configure your CI server for per-project local repositories and wipe them before the build to avoid such issues for sure.

Leave a Comment » | Software | Tagged: , , , , , | Permalink
Posted by digulla

groovy.lang.GroovyRuntimeException: Conflicting module versions. Module [groovy-all is loaded in version 2.1.8 and you are trying to load version 2.1.9

8. December, 2014

If you see this error while running the code from Eclipse, check the .classpath file for this line:

<classpathentry exported="true" kind="con" path="GROOVY_SUPPORT"/>

In this case, Eclipse adds version 2.1.8 to the classpath and Maven adds 2.1.9. At runtime, Groovy detects both versions and aborts since this will cause subtle bugs.

Solution: Delete the line above in the .classpath file.

If you see a line which contains GROOVY_DSL_SUPPORT, then you can leave that in – the Groovy plugin will use the JARs which Maven adds to the classpath.

Leave a Comment » | Software | Tagged: , , , | Permalink
Posted by digulla

Better Maven Deploy

9. October, 2012

mvn deploy has two major issues:

  1. If the project has several modules and the build fails in the middle, you will end up with a repository that is a mix of old and new modules.
  2. The POM must have the correct values in the distributionManagement element.

The former can break builds for your colleagues, the latter means you have to edit the POM file. Not a big deal – unless the POM file comes from an external source, say, an OSS project. If you edit it, you need to maintain the changes. But it gets ugly when your changes are committed to the external project.

The following script solves both problems. In a nutshell, it copies the POM, removes any existing distributionManagement elements, adds the ones you want and then builds using the new, temporary POM. If the build succeeds, the temporary POM is deleted.

The build itself is split into two steps. The first step does a local build, the second build skips tests and only uploads the results. It does run the compilers again but since the code was already built a few seconds ago, this shouldn’t be an issue.

Shell script.

Leave a Comment » | Software | Tagged: , , | Permalink
Posted by digulla

CBI or Taking The Pain out of Eclipse Builds

20. July, 2012

When a project is young and dashing, mistakes are made. The PDE build process is such a mistake. If you ever tried to build Eclipse (or at least some of the older parts), then you know that this is brittle and the error messages are more like mysterious ramblings of an angry deity than helpful.

Enter stage CBI. From the FAQ:

 The CBI build of the Eclipse platform is intended to produce the same output as the PDE build, and thus facilitate packaging without noticeable change. The noticeable difference the CBI build of the platform makes is ease of use to build the platform. For example, the prototype has consistently demonstrated that a newcomer without prior experience can build the Eclipse platform with under 30 minutes of effort on a machine with a supported JDK & Maven.

What can I say?

Finally!

Leave a Comment » | Software | Tagged: , , , , | Permalink
Posted by digulla

Sonar: The current batch process and the configured remote server do not share the same DB configuration

10. July, 2012

You might see this error message when starting the Sonar client, for example via Maven (mvn sonar:sonar):

The current batch process and the configured remote server do not share the same DB configuration
- Batch side: jdbc:...
- Server side: check the configuration at http://.../system

The message is a bit misleading. Sonar doesn’t actually compare the database URL, it compares the ID which you can find in the database table properties under prop_key = sonar.core.id and this isn’t an ID, it’s the start time of the Sonar web server:

select * from properties where prop_key = 'sonar.core.id'

There are two reasons why there could be a mismatch:

  1. The database URL on the batch and the server side don’t match (just check it via the URL which the Sonar client gives you)
  2. There are two Sonar servers using this database. This can happen, for example, when you migrated the service from one host to another and forgot to shut down the old version properly.

7 Comments | Software | Tagged: , | Permalink
Posted by digulla

How I Came to Hate Orbit

29. February, 2012

Orbit is an Eclipse project which contains IP clean OSS code to be used in Eclipse projects.

Why is that important? Well, IP clean means that big companies who consume Eclipse code, can use it safely (their lawyers have to check the EPL once and after that, their developers can use any code they can find on eclipse.org).

Now, Eclipse writes a lot of source code but not everything. commons-io, for example, contains a lot of code which would be really cool to have for Eclipse projects.

Orbit was created to have just that: Copies of OSS code from all kinds of places relicensed under the EPL. Sweet.

Enter stage: maven.eclipse.org

The idea behind maven.eclipse.org is to provide projects outside of the Eclipse foundation a place where they can find Eclipse’s OSGi bundles as Maven artifacts (which are easier to consume when you build your projects with Maven). Sweet 2.

To make the Eclipse bundles available on maven.eclipse.org, I need to convert them. Part of that process is to assign each Eclipse bundle (which has bundle ID and a version) a Maven coordinate (which consists of group ID, artifact ID and version). That’s not always simple but I’ve found a rule that works pretty well.

If it wasn’t for Orbit.

Orbit contains bundles which you can also find on Maven central. One example is commons-io.

And Orbit didn’t simply copy the JAR from Maven Central – they changed it. In this case, the changes are purely for legal reasons (EPL license, moved a couple of files around). Not a big problem here. I could map the two to the same coordinate – except that you would sometimes build software which contains code licensed by Apache and sometimes code which is licensed by EPL. Worse, some other code might be under the viral GPL on Maven Central – linking that could turn your project into open source! Not a problem for most developers but it could be a problem for your legal department and guess which head is going to roll?

But there is more.

Let’s have a look at … org.apache.batik.pdf. This is a fragment of the Batik’s rasterizer JAR from Maven Central. In this case, we have several issues:

  • Orbit has split a single artifact from Maven Central into several Orbit bundles. Which bundle should get the same coordinate as the original Maven Artifact?
  • The Orbit bundle also contains code from commons-io and commons-logging. So it pollutes your classpath with classes that you don’t expect. Worse, someone (not the Eclipse guys) removed “unnecessary” methods from some classes copied from commons-io. So if the compiler sees this JAR on the classpath, you will get errors for many methods in the class IOUtils. Bad.
  • Some Orbit bundles have bugs fixed but the version hasn’t been changed – only the qualifier changed which works if you use OSGi to build your classpath but Maven doesn’t. A couple of bundles from org.apache.batik are among them (bug 329376).

While it might make sense from Orbit’s point of view to do this, it makes my life a bit complicated.

Leave a Comment » | Software | Tagged: , , , , , | Permalink
Posted by digulla

Maven Tool 4 Eclipse 0.10.0 Released

12. January, 2012

I’ve just release a new version of Maven Tools 4 Eclipse (Changelog). It fixes the two most pressing issues:

  • Bug 367461 – [mt4e] mt4e needs priming.zip
  • Bug 354381 – Error: groovy.lang.MissingPropertyException: No such property: args for class: m4e.ImportTool

Have Fun!

1 Comment | Software | Tagged: , , , , | Permalink
Posted by digulla

New Release of MT4E

24. August, 2011

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: , , , , | Permalink
Posted by digulla

When Maven Crashes Eclipse

8. August, 2011

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. Close Eclipse when you build your projects with Maven from the command line
  2. Disable automatic refresh (Preferences -> General -> Workspace -> Refresh using native hooks or polling)

 

1 Comment | Software | Tagged: , , | Permalink
Posted by digulla

New Website for Maven Tools For Eclipse (MT4E)

13. July, 2011

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: , , , , | Permalink
Posted by digulla

« Previous Entries
%d bloggers like this: