Closed J-N-K closed 4 years ago
To prevent adding new libs, the embedding code should be removed from the pom.
We should probably also add some documentation as we currently seem to be lacking any information on how to deal with required external libraries that are not "default". I myself regularly have issue remembering how we expect it to be done...
I‘m pretty sure I wrote something about that. Can‘t remember where though.
Haha, if you find out, I'd be interested in it! 😎
https://github.com/openhab/openhab-docs/pull/1199
Maybe we should add that bundles that are not available from a remote repo can be added to our openhab-addons-dep bintray
openhab/openhab-docs#1199
Ah, thanks!
Maybe we should add that bundles that are not available from a remote repo can be added to our openhab-addons-dep bintray
Would be a nice addition. Want to create a PR for it? Especially on how to get it added to openhab-addons-deps.
Hello @kaikreuzer or @wborn, could it be that this dependency (specifically ruuvi, https://github.com/openhab/openhab-addons/pull/8701 ) was not migrated, could you quickly outline what I can do do to help this to be fixed? Thanks a lot!
While building locally on a clean machine I get:
[ERROR] Failed to execute goal on project org.openhab.binding.bluetooth.ruuvitag: Could not resolve dependencies for project org.openhab.addons.bundles:org.openhab.binding.bluetooth.ruuvitag:jar:3.1.0-SNAPSHOT: Could not find artifact fi.tkgwf.ruuvi:ruuvitag-common:jar:1.0.0 in openhab-release (https://openhab.jfrog.io/openhab/libs-release) -> [Help 1]
After stepping over it I get the same error for Cbus
[ERROR] Failed to execute goal on project org.openhab.binding.cbus: Could not resolve dependencies for project org.openhab.addons.bundles:org.openhab.binding.cbus:jar:3.1.0-SNAPSHOT: Could not find artifact com.github.jpharvey:cgateinterface:jar:1.1.0-JH-dev in openhab-release (https://openhab.jfrog.io/openhab/libs-release) -> [Help 1]
Thanks for reporting this. Maybe @kaikreuzer can add them to Artifactory? Jenkins doesn't run into it because it only removes org.openhab
artifacts from the local Maven repo to improve build times.
I removed bintray from the artifactory releases repo yesterday and am currently looking at adding missing stuff to Artifactory directly. Reference build is https://ci.openhab.org/view/Sandbox/job/sandbox-openhab3-release/ - once this is green, it should be fine. Will finish it by the end of this month.
If it helps you. Feel free to create a user for me, I can make some time today to upload the missing artifacts there. Otherwise, let me know if there is something (small) which I could do to help
The distro build also seems to have some issue downloading artifacts:
[ERROR] Failed to execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.3.1:kar (default-kar) on project openhab-addons: Failed to create archive: Could not find artifact org.openhab:com.caucho.quercus:jar:4.0.45 in openhab-release (https://openhab.jfrog.io/openhab/libs-release)
FTR, this is what IntelliJ reports to be missing
Cannot resolve fi.tkgwf.ruuvi:ruuvitag-common:1.0.0
Cannot resolve com.github.tavalin.orvibo-sdk:s20-sdk:0.0.6-nmu1
Cannot resolve com.github.pathec:zway-lib:0.2.9.OH
Cannot resolve com.github.jpharvey:cgateinterface:1.1.0-JH-dev
Cannot resolve org.tellstick:javatellstick:1.1
Cannot resolve com.leapmotion.leap:leap-java:2.0.0
Many thanks @martinvw! I have uploaded all those libs to Artifactory now. Distro build is also green now.
Sandbox build is green, so it all looks good now!
I noticed that both 2.5.x and 3.0.x use https://openhab.jfrog.io/openhab/libs-release
as online repo @kaikreuzer. But it now only contains 3.0.2 addons. Which explains why everyone not running that version has issues installing them (even though bintray hasn't sunset yet):
Hm, I wasn't aware that 2.5.12 also pointed to Artifactory... In some way it is good as it gives us the chance to make it working even after May 1. I have created a new local repo https://openhab.jfrog.io/artifactory/libs-online-2.5.12/ with all 2.5.12 artifacts and can include it into the virtual libs-release repo. Unfortunately, the 2.5.12 still failed finding them - possibly because it is looking for a version range and the metadata is missing.
Well, I have added the bintray location to the virtual repo again, so that people can still use everything as before for 3 more days. I'll then shift the further testing to after that date, since then it will anyhow not work anymore...
This is to keep track of binary data in the repo.
To prevent adding new libs, the embedding code should be removed from the pom.