>>>>> Jean-Baptiste Onofre <[email protected]>: > Hi, > Is it a static or dynamic distribution ?
I'm provisioning the application from maven and I'm provisioning from version LATEST on the top feature. Unsure of the terms here, but I guess that makes it dynamic...? > If dynamic, do you have stage in the boot features (to have > pax-url-wrap before your features that use wrap protocol) ? I don't know. But I had a thought waking up today: The reason it works when running locally is probably that the troublesome jar file in the stack trace is already in my $HOME/.m2/repository/ before I and the reason it fails in docker, is probably that it starts with an empty $HOME/.m2/repository/ So somewhere in the dependency graph there are two versions of a feature that at one point in time pulled in the troublesome jar and no longer does (in the newest version) and that this is the loop hinted to in the stack trace...? > I will take a look on your features XML. Thanks! Let me see: Here is the Dockerfile and the files it copies into the karaf official docker image: https://github.com/steinarb/oldalbum/tree/master/docker/docker Here is the oldalbum top level (handwritten) karaf feature repository: Source: https://github.com/steinarb/oldalbum/blob/master/karaf/src/main/filtered-resources/feature.xml Latest on maven central: https://mvnrepository.com/artifact/no.priv.bang.oldalbum/karaf/1.6.4 I have moved many of my handwritten karaf repositories from being attached to the top pom and into a sub-module of the reactor build. The reason for moving feature repositories to a sub-module, was that I've reintroduced karaf pax exam integration tests that load and assert the features (since they are now so simple to write...:-) ), and attaching the hadwritten feature to the top pom introduced a dependency loop: "mvn clean install" would run locally if there already was a SNAPSHOT of the feature with the original URL, but "mvn release:perform" would fail But anyway: I may still have feature dependencies referring to other feature repositories with their old maven URLs and picking up an older version. So finding any leftover old URLs and cleaning them up seems like the way to go...?
