How to patch an opendaylight bundle for SDNC
In fact we found some issues for SDNC which are only fixable in the opendaylight artifacts, we have to provide some fixes for the ONAP SDNC distribution. The problem is that the in opendaylight used eclipse license is not okay for the ONAP project so that we have to publish and deploy the code somewhere else.
Hint: The goal always should be to bring the fix into the opendaylight project!
The artifacts we provide will be deployed to official maven central with our sonatype account.
Example
opendaylight does not support initial configuration of the admin user, or at least setting the password for admin
therefor we have to patch org.opendaylight.aaa:aaa-authn-api
org.opendaylight.aaa.api.StoreBuilder
public void initWithDefaultUsers(String domainID) throws IDMStoreException {
String newDomainID = initDomainAndRolesWithoutUsers(domainID);
if (newDomainID != null) {
createUser(newDomainID, getPropertyOrDefault("${ODL_ADMIN_USERNAME}", "admin"),
getPropertyOrDefault("${ODL_ADMIN_PASSWORD}", "admin"), true);
}
}
now the default admin username and password can be set by environment variable on startup, e.g. controlled by kubernetes secrets or sth. similar
Steps
find correct artifact version
in fact that ODL has some strange versioning behaviour the easiest way is to look into your distribution or in the base distribution of opendaylight and find your artifact in <odl-folder>/system/<the>/<odl>/<groupId>/<artifactId>
the code
therefore you have to fork the responding odl subproject (we did it directly with github)
go to your branch/tag of the version you found out before
apply your fixes
change for the specific artifact the groupId to yours
deploy your fix
create oss.sonatype account
edit your profile and create new access token
configure your maven settings.xml
create gpg key and publish for your email address (the same with which your sonatype account is registered)
build local artifacts (these should be there after a build)
<artifactId>-<version>.jar
<artifactId>-<version>-javadoc.jar
<artifactId>-<version>-sources.jar
sign your artifacts and pom files
gpg -ab {your-project-path}/pom.xml
gpg -ab {your-project-path}/target/{artifactId}-{version}.jar
gpg -ab {your-project-path}/target/{artifactId}-{version}-sources.jar
gpg -ab {your-project-path}/target/{artifactId}-{version}-javadoc.jar
deploy
# deploy bundle with javadoc and sources
mvn gpg:sign-and-deploy-file \
-DpomFile={your-project-path}/pom.xml \
-Dfile={your-project-path}/target/{artifactId}-{version}.jar \
-Dsources={your-project-path}/target/{artifactId}-{version}-sources.jar \
-Djavadoc={your-project-path}/target/{artifactId}-{version}-javadoc.jar \
-Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2 \
-DrepositoryId={your server id of maven settings file}
# deploy jar
mvn gpg:sign-and-deploy-file \
-Dfile={your-project-path}/target/{artifactId}-{version}.jar \
-Durl=https://oss.sonatype.org/service/local/staging/deploy/maven2 \
-DrepositoryId={your server id of maven settings file} \
-DgroupId={groupId} \
-DartifactId={artifactId} \
-Dversion={version} \
-DgeneratePom=false
go to oss.sonatype.org and login
go to Staging Repositories
first check your artifacts on the very bottom and then close your submission (will take a while)
last step: release artifacts
apply you fix to the distribution
load additional artifacts with the pom file
overwrite the artifact within the Dockerfile
The versioning problem
There will be maybe the case that you'll have to do a fix for the fix. The problem is that you cannot release an artifact in the offical maven repository twice. The solution is luckily quite simple. Just release it with a new version number and modify the injection of the artifact in the release building pom.xml.