-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bundle all "compile" dependencies into a fat jar bundle #62
Comments
This version problem might be because you're using an old version of the But regarding the fat jar. That's a good idea and would be easy to do. I will give it a shot in the next few days. |
I think I have the last one! My build.gradle:
Maybe I can solve the problem, as I have solved some that were appearing, but it's one more in the pipeline. I want to work on my product, not spending time solving OSGi stuff. Maybe that's why developers give up on OSGi! Building a core bundle similar to a simple fat jar to start in, sometimes make sense for a small product. |
I know the feeling :) This plugin is meant to make OSGi more usable, but there's still more room for improvement. I checked your dependencies and I agree, you have the latest... to avoid future errors for other people, though, it would be good to try to find out where the version is being rejected... I thought it was an older version of I will check that later, let me know if you have more information. Anyway, if you want to work around these stupid issues, make your problematic dependencies use systemLib. Then, they will work just like in the flat Java classpath, and the packages will be exported by the OSGi environment itself to all bundles. |
Unfortunately "systemLib" also doesn't work when adding the "org.raml:raml-parser-2:1.0.7" dependency. It gets rid of build errors, but the OSGi container is complaining a lot when starting. Here's the big log:
|
So, useful information for you. There are 2 transitive dependencies that are not being handled correctly.
Can I instruct the plugin to generate these correctly? Replacing (2-1.0 -> 1.0.7 and 1.7R4 -> 1.7) |
Ah, this is the jar author's fault for not giving a version in the manifest file (so the plugin tries to guess the version from the file name)... Quite unfortunate in this case, as the "guessed" version is the wrong one! It is possible to change the version of wrapped bundles but not of system libs (I think). See Wrapping jars. You can do something like: runOsgi {
wrapInstructions {
manifest( "raml-parser.*" ) {
instruction 'Export-Package', 'raml,something'
instruction 'Bundle-Version', '1.0.7'
}
} |
By the way, why do you have |
I had a look at the code that "guesses" versions for jars missing the information... It's already doing it as good as it's possible.. I can make it translate versions to OSGi automatically to avoid errors (using
Only a few look right. The current code behaves like this (from the Spock tests):
Whatever we do, we get errors either at compile time or at runtime :( There must be a way to improve this, but I am not sure what that is. |
I found a good alternative! Example: #Generated by Maven
#Tue Mar 07 09:39:48 EST 2017
version=1.0.7
groupId=org.raml
artifactId=raml-parser-2 I will start using these files if they are available. |
… Analyser for wrapping. This ensures any valid Maven version is recognized correctly.
…g file. This ensures any valid Maven version is recognized correctly.
My above suggestion is implemented in the It depends on two different versions of Guava (one from the jackson-core), so that needs to be explicitly declared as a So, now I can get the RAML dependency working in OSGi... using the following Gradle deps: dependencies {
compile 'org.raml:raml-parser-2:1.0.7', {
exclude( group: 'org.mozilla' )
}
systemLib 'org.mozilla:rhino:1.7R4'
// needed by transitive deps of raml
osgiRuntime 'com.google.guava:guava:16.0.1'
// logging
osgiRuntime 'com.athaydes.osgiaas:slf4j-to-osgi-log:1.7.0'
osgiRuntime 'org.apache.felix:org.apache.felix.log:1.0.1', {
transitive = false
}
} Of course, this won't help @shumy too much, I think, but versions are managed much more safely now, which is a good improvement for osgi-run! |
@shumy FYI I finally release the improvements on parsing the wrapped jars (and system libs) versions on version 1.5.5. You may want to upgrade. |
Is it possible to build a fat jar with all transitive dependencies (conflicts resolved similar to maven), and select just the packages that I need to export for my plugin architecture?
No matter what I try, I always get in trouble with dependency resolution, last one was about "Invalid syntax for version" when generating the manifest for "raml-parser-2".
I will rather prefer to build a core bundle with all that I need, and skip this bunch of problems. I know this is not very good OSGi paradigm, I don't care!
The text was updated successfully, but these errors were encountered: