How to handle mix of OpenEMS and proprietary software

English Forum
1

My case: I am working with a customer to build a system that will benefit from OpenEMS and extend from this. Some of my work will be public domain and when duly qualified offered back to the project - but some of my work will be proprietary with my customer.

I would like to keep the link to the official repository to enable sharing both ways - hence I have created a fork of the project.

I had the intention of using a git submodule to include a different repository in the workspace. This is all set up - but when I attempt to create new bundles, stored in the folder of the sub-module, eclipse (or whatever magic wand) does to pull all the dependencies into the bundle path folder???

Does anyone have any experience with a setup like this?

2

You can repackage openEMS into your own solution. If you look at the source code there are few key elements which serve core functionality. By making new assembly you can create a new runtime which will include your private as well as open source components.
Gradle which is used to build openEMS can be used to publish artifacts to local artifact repository, which can be used by another gradle build to create another instance of edge deployment. I’ve made a partial job here: Generate maven poms and releases within bnd workspace. by splatch · Pull Request #2612 · OpenEMS/openems · GitHub, I should be able to complete it within few weeks.
Another way is running copybara to merge and manage code between private and public repository, however due to complexity of the tool and quality of documentation I would not recommend that.

Best,
Łukasz

3

Thank you very much Łukasz. I have spend a couple of days trying to find my way in this. Today I realized that the folder structure of the workspace must be “flat” and since the git submodule method added a new folder for my external content it is in conflict with the bundle management (as far as I have deducted from from my search). The method would be, as you describe, to export the OpenEms to a repository that could then be referenced similar to the maven repository.

I will study your example and see if I can find my way forward.

Jens

4

Hi Łukasz

I added this to “build.gradle” in the subprojects section and it appears that I am able to publish to a github package repository. I need to share the packages with a colleague, hence a local repository is not the favorite flavor.

Publishing is executed by ./gradlew --build-cache publish

When publishing is completed, I will make the attempt of using the published packages in separate project.

Let me know if you have any suggestions for an improved method.

` apply plugin: “maven-publish”
apply plugin: “java”

repositories {
	mavenCentral()
}

publishing {


	publications {
		openems(MavenPublication){
			from components.java


			groupId = 'io.openems'
			artifactId = project.name.toLowerCase()
			version = '1.0.0'

			}
	
	}
	repositories {
		maven {
			name = "GitHubPackages"
			url = "https://maven.pkg.github.com/<username>/<repository>"
			credentials {
			username = findProperty("gprUsername") ?: "yourusername" // GitHub username
			password = findProperty("gprToken")  // GitHub token
			}
		}
	}
}`
5

Awesome outcome, I have been going over gradle and bndtools functionality (with some hair pulling among the way), trying to figure out valid gradle way, and separate it from bnd config.
To be fair, I like this way more than bndtools, since it is more common than doing it from earlier.
One thing I can think of, which is independent of gradle vs bndtools, is version propagation. Version used by bnd files might result in resolution errors later on. This is due to the fact that under OSGi v 1.0.0.2024.03 is assumed to be compatible with 1.0.0.2024.04, because qualifiers are not considered when matching version ranges.
This puts present versioning strategy in question, especially with third party development which needs to validate runtime assembly against given base version of openEMS.

6

Yes, I was very pleased when I saw the bundles being uploaded.

I understand you point on versioning - but I do not feel qualified to give you some sensible input. I am still on the “newbie” section on the learning curve.

After reading https://docs.osgi.org/whitepaper/semantic-versioning/040-semantic-versions.html I learned that the “qualifiers” section is not compared and essentially intended to separate bug-fix releases. Based on this, releases offering new functionality should increment on one of the first three elements.