Which repository type to use in an embedded software development context?


I’m currently evaluating Nexus OSS 3 in an embedded software development context. I have various C code projects that (via Jenkins) produce binary release blobs (basically .zips) that each contain a firmware image to be loaded onto the target hardware (various microcontrollers) and the respective scripts to load the firmware image.

My intention for using Nexus was shifting archival of those binary artifacts from Jenkins to another system (and also to prevent that people check in their artifacts into Git). Hence, I’m strongly interested in versioning the artifacts that I put into the Nexus repository.

Now I’m a bit lost because obviously most Nexus repository types don’t fit my scenario. I think the only two remaining ones are “Git LFS” and “Raw”. With the Raw repository type, I don’t seem to get versioning. So that leaves “Git LFS”. Correct?

How do I use Nexus correctly in my context? Have one Nexus repository of type Git LFS per embedded software project (e.g., one for “engine control software” and one for “windshield wiper control software”) and then let Jenkins put the artifacts into the respective repos? Or did I miss something?


Happy New Year, Manuel, and welcome to the Community Forum!

You are correct that Raw will not have enforced versioning, but let me suggest you take another look at the Maven format. The Maven spec is agnostic about the type of component which is being created or ingested.

We have users who use that format to store non-Java packages because it is reliable, well-known, works with many tools, and provides a version convention based on semantic versioning. The Nexus Repository Manager will allow you to enforce that convention which seems desirable based on your requirements.

1 Like

You might consider looking at using gradle as your build tool and publishing to a maven library. Here is an example that consumes a native library as a maven dependency from a local (aka a filesystem folder) maven repository. The library it consumes is from native-samples/build.gradle at dd212f83bbec3db7ad5774f614b486a5be3e3a92 · gradle/native-samples · GitHub.

1 Like