1 minute read

After refactoring a small project to manage subversion auth information into multiple Maven modules I started running into what I assume is a fairly common problem: trying to build a child module which depends on an edit applied to a different module which hasn’t been built yet. For some reason the “Set as main project” option has gone from Netbeans 7.2, so I found myself going back to the command line to build each time.

A couple of days later and I’m integrating the project with a local Sonar instance, only to find it fails with a similar message:

[ERROR] Failed to execute goal on project XXXXXXXX: Could not resolve dependencies for project XXXXXXXX:XXXXXXXX:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: XXXXXXXX, XXXXXXXX, XXXXXXXX: Could not find artifact XXXXXXXX:XXXXXXXX:jar:1.0-SNAPSHOT -> [Help 1]

A bit of digging turned up an issue which claims the problem is solved in Maven 3.2, but that didn’t solve it for me.

At least as an interim, packaging the project prior to running the Sonar plugin does the trick, ensuring that the relevant JARs are available for the sonar plugin’s run:

mvn package sonar:sonar

Now the only problem is dealing with all the violations I’ve introduced, Bad Ryan!

You May Also Enjoy

Protect yourself first

3 minute read

A common refrain in software engineering is to put your team before yourself. Also, put the customer first. Make sure you align with the organisation’s goals...

Capybara, WebMock, and too many open files

2 minute read

Getting set up with a new codebase is always a fun, sometimes head-scratching experience where you have to discern whether the issues you’re facing are becau...

Docker context switching

less than 1 minute read

Sometimes it’s useful to run multiple Docker contexts/daemons, e.g. if you’re running Docker Desktop and Lima, or local Kubernetes clusters.