Hi,
i forked and ported the keycloak plugin for operaton => GitHub - hauptmedia/operaton-keycloak: Operaton Keycloak Identity Provider Plugin
How do we want to handle (community) plugins, should they be moved to the main github organization?
Cheers,
Julian
I wonder if any possible legal stuff in the future would be easier if there was a clear GH-organization level separation between supported “core” and stuff managed by larger community?
How about case by case until things get stable? Maybe super popular plugins like the keycloak one should be adopted into core organization? Maybe “Awesome Operaton”-repo to keep list of plugins available under their authors’ repositories?
This is amazing, thanks a lot! I started writing down my opinions on this, and then I saw that @datakurre already wrote down what I thought, mostly 
Having those repositories in the Operaton organization would ensure maintenance in the future, even if the initial maintainers abandoned the project. On the other hand, every plugin is more code to maintain, so I would (personally) prefer to have only the commonly used plugins there. I’d love to have some more opinions on this.
In this specific case, the group ID is org.operaton, which means that it has to be published with our Sonatype user, because we registered this namespace. This would be a strong point for having it in the org.
Hi @Julian , I tried building the fork, after running a mvn install on the fork of the community-hub-parent you also created, to install the dependency in my local .m2 Repo.
I tried running mvn clean install on the repository, and every test is failing. I also copied the command from the GitHub Workflow file with the same result (example, but it’s the same exception for every Test):
[INFO] Running org.operaton.bpm.extension.keycloak.test.KeycloakUseKeycloakIdAsUserIdQueryTest
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0 s <<< FAILURE! -- in org.operaton.bpm.extension.keycloak.test.KeycloakUseKeycloakIdAsUserIdQueryTest
[ERROR] org.operaton.bpm.extension.keycloak.test.KeycloakUseKeycloakIdAsUserIdQueryTest -- Time elapsed: 0 s <<< ERROR!
java.lang.NoClassDefFoundError: Could not initialize class org.operaton.bpm.extension.keycloak.test.KeycloakUseKeycloakIdAsUserIdQueryTest
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1161)
at java.base/java.lang.reflect.Method.acquireMethodAccessor(Method.java:726)
at java.base/java.lang.reflect.Method.invoke(Method.java:577)
Did I miss or misconfigure something, here? Is the fork builing for you?
Hi @javahippie the tests will only run if you spin up a local keycloak instance. The nasty “class could not be find” messages are in reality a failing static code block in the abstract class they are based on. For the time being i just disabled the tests. I have to fix the GH workflow to spin up a keycloak and apply the tests to it.
I just install it using mvn clean install -DskipTests=true
This is our complete Docker file for building our workflow engine:
FROM maven:3-amazoncorretto-17 AS builder
COPY .. /home/maven
WORKDIR /home/maven
RUN yum update -y && yum install -y git
# install community-hub-release-parent
RUN git clone https://github.com/hauptmedia/community-hub-release-parent.git /home/maven/community-hub-release-parent && \
cd /home/maven/community-hub-release-parent && mvn clean install
# install operaton-keycloak
RUN git clone https://github.com/hauptmedia/operaton-keycloak.git /home/maven/operaton-keycloak && \
cd /home/maven/operaton-keycloak && mvn clean install -DskipTests=true
RUN mvn clean install package spring-boot:repackage
RUN java -Djarmode=layertools -jar target/backoffice-plus-operaton.jar extract --destination target/extracted
FROM amazoncorretto:17
COPY --from=builder /home/maven/target/extracted/dependencies/ /opt/operaton
COPY --from=builder /home/maven/target/extracted/spring-boot-loader/ /opt/operaton
COPY --from=builder /home/maven/target/extracted/snapshot-dependencies/ /opt/operaton
COPY --from=builder /home/maven/target/extracted/application/ /opt/operaton
WORKDIR /opt/operaton
CMD ["java", "org.springframework.boot.loader.launch.JarLauncher"]
Thanks, reading the README would have helped me, apparently 
I wonder if this could be fixed with using Testcontainers 
@javahippie we have to decide what to do with the community-hub-release-parent, i can then do some further cleanups and create a gh workflow that can run the tests. my primary goal was to get it running and migrate our stuff to have a proof of concept that a migration is possible with moderate efforts
I was trying to build the project to find out if I could simply swap the community-hub-release-parent with the existing operaton-release-parent, as both seem to serve a similar purpose. When skipping the tests, the build is successful for me.
There is a problem with the maven-jar-plugin, it’s pinned to version 2.6 in the operaton-release-parent
<!-- for compatibility reasons pinned to 2.6, since 3.0.0 introduced a change incompatible to this build script -->
<plugin.version.jar>2.6</plugin.version.jar>
The community-hub-release-parent uses version 3.3.0.
The keycloak plugin does not build with version 2.6
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-jar-plugin:2.6:jar (default-jar) on project operaton-keycloak: Execution default-jar of goal org.apache.maven.plugins:maven-jar-plugin:2.6:jar failed: Unable to load the mojo 'jar' in the plugin 'org.apache.maven.plugins:maven-jar-plugin:2.6' due to an API incompatibility: org.codehaus.plexus.component.repository.exception.ComponentLookupException: null
Do you think it’s possible to update the version in the operaton-release-parent?
Updating the maven-jar-plugin might be a larger task than anticipated. For now, I’ve overridden it, and it seems to be working. You can check out the changes here: GitHub Commit.
I have removed the hauptmedia/community-hub-release-parent repository, as it is no longer needed and to avoid any confusion
Thanks for pointing this out (and also providing a workaround for now!)
I fear the Keycloak plugin is not yet in the state of being released. The tests are not running, this has to be fixed fist. I was starting by setting up Testcontainers for the tests. But I have problems getting the tests to work, I need to dig deeper. Also, the code is all over camunda, it needs to be cleaned.
The keycloak plugin code is at version 1.0.0-beta-2. This aligns to the Operaton version. But I think that is wrong. The plugin has its own lifecycle, i.e. IMO version 1.0.0-beta-1 will be the first to release.
I will try to get the tests now working first.
I can check the integration tests now. The version is tied to Operaton version because of the intended way to use the plugin.
You use the plugin’s POM as parent and it defines a Spring and Operaton version to use.
Like so
<parent>
<groupId>org.operaton.bpm.extension</groupId>
<artifactId>operaton-keycloak-root</artifactId>
<version>1.0.0-beta-2</version>
</parent>
In the original plugin this was always tied to the C7 version.
Perhaps we should change this because I see it not being ideal. Makes it difficult to include multiple plugins
For now i have renamed all missing parts. There are still changes to be made (for example the links to the documentation). But this can be only done once we have our documentation ready. I also noticed that there is some outdated information about keycloak in the README.md. I will update the README once i got the tests running again.
will also use normal GH workflow now, but the first commits with all the renaming I pushed directly to main
The normal integration tests are running again, but there is also a complete scenario test, that relies on an external docker image gunnaraccso/camunda-showcase-keycloak
I think we have to disable this for now. We have to create an account on dockerhub and see how this container is being generated
Ok great @Julian. So I can just wait until the main build succeeds, you take care for that?
I have already a branch for setting up Testcontainers in the tests. I think when you have managed to get the tests running it will be easy to take also this step.
Yes, you can take it from here, just have to review and merge this PR fix(test): disable example showcase test (related to #11, #3) by hauptmedia · Pull Request #12 · operaton/operaton-keycloak · GitHub
The build is running, I can proceed with the release process. I did first tests but need to fix it. Seems that we are not far from that. I will continue later.