After fetching and pulling into my develop branch I was able to `mvn clean package` both with and without network with no errors. Nice job.
On January 19, 2019 at 13:17:11, Christofer Dutz (christofer.d...@c-ware.de) wrote: Ok ... so I guess I finally identified the problem Justin was having and fixed it (hopefully) It turned out that Justin wasn't doing a "mvn package" or "mvn verify" or "mvn install" ... but a "mvn compile". When doing this, Maven doesn't execute the package phase and Maven passes a directory in as dependency (Which is usually ok) However the karaf plugin isn't expecting this. So if tries to read the directory as if it was a jar (Zip File) and of course this fails. I managed to shift the feature.xml generation to the package phase ... as we don't have any code to compile, tests to run and stuff to package, this is a valid workaround. However I should report this to the karaf team as this is definitely a bug ... the plugin should be able to handle this. Either it should be able to handle directories and keep the generation in the generate-resources phase, or they should move is to a phase for which is known that jar exists. Guess this was the last build-problem I know of ... And as it turns out to be an avoidable problem by simply running "mvn package" instead of "mvn compile" I don't think we need the hastle of rebasing the release branch. But that's up to you Julian. Chris Am 19.01.19, 11:52 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>: Hi Julian, I think I'd wait for Justin to respond to my last suggestions ... this is the last issue I have on my radar. After we've addressed everything maybe it would be good to re-base even if these potential problems were always in there and we never really had any problem reports during the last releases. SO I guess it's up to you as Release Manager to decide ;-) Otto's problem could be solved by being online (We should change that however). I really like this option to define custom annotations for Junit5 and have some of the tests simply skipped if a prerequisite is not met. So I'd probably define a "@RequiresBeingOnline" and if that's not true it will skip that particular test. This way we can generally continue to test this functionality, without the problem of not being able to build offline. And I would probably add a "@RequiresNonCaptureAllDns" annotation for the other problems reported (This would just resolve two non-existent domain names and if both succeed and are equal, we've detected a "capture-all-dns" setup) Chris Am 19.01.19, 11:38 schrieb "Julian Feinauer" <j.feina...@pragmaticminds.de>: Hey Chris, thanks for the analysis, I'm totally of with Karaf, I'm not even able understand the problem it solves : / But to your point, I agree with your proposition to leave it out of the release if it's not "stable" and perhaps Sebastian can jump in when he has some time as he started the work on this, I think. Regarding all the recent fixes and changes in develop I'm unsure if I am able to follow anything. Do you think it would be better to rebase the rel branch to current develop as all that was happening in develop since then where build fixes? Best Julian Am 19.01.19, 11:19 schrieb "Christofer Dutz" <christofer.d...@c-ware.de>: Ok so that helped ... a little ... thing is I was expecting it to occur when WRITING the features.xml file ... seems it occurs when reading it inside a jar ... Investigating even more, I noticed that the build of the Karaf modules don't seem to produce any jar files, just sources.jar, which is quite pointless for a project without a line of code. As far as I understood it, these modules should take the driver modules and re-package them with OSGI descriptors so they can be used in an OSGI context. For that they would have to contain something ... I would suggest to comment out the Karaf module in the release branch and we concentrate on building something useful instead of just being happy the build works ;-) I've just checked out the Karaf project as a total and will now try to find out how to fix the bundle generation (Another option would be to add the descriptor generation to the drivers themselves (Would prefer that) No need to re-package stuff as the additional metadata will not interfere with the normal JAR functionality. Chris Am 19.01.19, 01:49 schrieb "Justin Mclean" <jus...@classsoftware.com>: at org.apache.karaf.tooling.features.GenerateDescriptorMojo.writeFeatures(GenerateDescriptorMojo.java:509)
