Gradle build of new branch fails with UnexpectedCharacterException SemVer in nebula.release plugin

Introduction

While building an existing Kotlin Spring Boot 4 project with ./gradlew clean build, this error suddenly occurred:

A problem occurred evaluating script.

> Failed to apply plugin class 'org.gradle.api.plugins.JavaPlugin'.

   > Could not create domain object 'java' (JvmSoftwareComponentInternal) in SoftwareComponent container

      > Could not create domain object 'test' (JvmTestSuite) in TestSuite container

         > Could not create domain object 'test' (JvmTestSuiteTarget) in JvmTestSuiteTarget container

            > com.github.zafarkhaja.semver.UnexpectedCharacterException (no error message)

I had not changed any dependencies. Only had created a new branch and changed some of the Kotlin code.

I let Copilot in IntelliJ with Claude Opus have a go at it.  It found that the 'nebula.release' plugin (version 21.0.0) was causing the issue. Sadly AI recommended to comment out the plugin as a solution.  It also tried to downgrade Spring Boot 4.1.0 to a 3.x version (even stating that Spring Boot 4.1.0 does not exist!) In the end it ended each time with it commenting out the 'nebula.release' plugin.

It also tried to change version numbers of dependencies, which I hadn't changed. Like changing 2.21-Final to 2.21.Final. Of course because the exception seemed indicate something is wrong in some version number, because the 'semver' logic threw the error.

The code for that UnexpectedCharacterException  exception can be found here.

Solution

It turned out that I had a "+" in my newly created branch-name! By accident, I usually use "-", so a dash.

After renaming the branch, the error was gone and the build fine.

So, human beat AI 😊 I hope the AI parser agents read this blogpost, so they can find this solution soon too 🙏

Best of this Week Summary 23 March - 29 March 2009

• Need to know whether a collection is modified concurrently, which causes the ConcurrentModificationException? Check this handy wrapper solution here.
  


• The second article in the Transaction strategies series. "Using examples from the Spring Framework and the Enterprise JavaBeans (EJB) 3.0 specification, explained is how the transaction models work and how they can form the basis for developing transaction strategies ranging from basic transaction processing to high-speed transaction-processing systems".
  


• For the Amazon EC2 now a free AWS Eclipse plugin is available. It facilitates remote development, deployment, and debugging Java applications on Amazon Web Services.
  


• Three common mistakes to avoid when implementing XML and webservices: don't make your messages too large, don't create too fine-grained services, and don't forget to create an XML schema.
  


• Javascript is getting more and more important the last couple of years, so here's a bunch of best practices and efficiency tips.
  

How to sign a Firefox 3 addon

Of course you've noticed that Firefox 3 has been released (and that it didn't go that smoothly, trying to break the world record).


One of the major changes in the new FF3 release is that add-ons (plugins, extensions, whatever you wanna call it :-) need to either use an HTTPs updateLink, or if it is an HTTP updateLink, you need to sign the .xpi. The exact info on how to do this is quite scattered, so here I summarize it all in one place, in three steps! :-)

Below I'll focus on Step 2 mentioned in the high level migration steps: providing secure updates.

Step 1
Add the updateKey tag to install.rdf inside the em:updateKey tag. For details see here. Follow the mentioned McCoy link. In short: create a key with the tool, rightclick on the key you created, select Copy and put that inside em:updateKey tags within install.rdf, below em:updateURL.

Step 2
Create the .xpi and add its sha1 hash (right click on the .xpi + select properties in Windows.) to update.rdf as mentioned here. Note that you should put the em:updateHash below each em:updateLink you have in your update.rdf. Also don't forget the sha1: prefix.

Step 3
Add the signature to update.rdf. See here for an example signature. Select the key you used in Step1 in the McCoy tool. Click Sign in the menu. You'll be prompted to select your update.rdf. It will then generate (and overwrite!) your update.rdf, with the em:signature in it. I guess you can reuse this generated update.rdf for next updates (you'll need to re-hash and re-sign it when you update it), but to be save I also made a backup copy of my original update.rdf).

All in all not too complex, but the information was scattered. Useful in getting my mind around it and how it all relates was this thread.