I tend to use Option 4 from my blog, but I'm using the compileInclude Gradle dependecy directive to handle the grunt work for me. If you have a dependency, you have to include it. The last thing you want to have happen is to find your module deployed to production and fail on a sporadic basis because sometimes an XML file has a date/time to parse. The problem, however, is it leaves you open to a later ClassNotFoundException because you have a dependency on a package which is marked as optional. It will get you by the Unresolved Requirement bundle start error. Yes, you can tell OSGi to also treat the dependency as optional. Now I hate picking out one example like this, but I think this is really important to point out. If you, the developer, are using XStream, OSGi expects that you should know if you are going to need an optional dependency like Joda or not. It is up to the bundle developer to know what is required and what isn't, and OSGi forces you to either satisfy the dependency (ala something like this) or excluding the package dependency by masking them out using the Import-Package declaration. This is one reason why you get the "Unresolved Requirement" error when OSGi attempts to start the bundle. OSGi sees that XStream may need Joda, but it cannot determine whether or not it will be needed when the bundle is resolving. The OSGi container is stricter about these optional dependencies. However, if you were to try to process an XML file with a date/time stamp, you may encounter a ClassNotFoundException or the like if Joda is not available. For example, if use the "java" command with a classpath that includes the XStream jar and your classes, Java will happily run the code whether or not Joda is required. Depending upon how the jar is used, this extra designation can be used or it can be ignored. runtime vs compile in Gradle and tag in Maven, will translate into the "resolution:= optional" stanza in the jar's MANIFEST.MF. When the libraries are being built, the scope used for the declared dependencies, i.e. If you have XML that does have dates/times but you don't have Joda, you'll get ClassNotFoundException errors when you hit the XStream code that leverages Joda. So Joda is absolutely optional, from a library perspective, but as the implementing developer only you know if you need it or not. The library is marked as "optional" because you don't have to have Joda in order to use XStream.įor example, if you are using XStream to do XOM marshaling on XML that does not have dates/times, well then the code that uses Joda will never be reached. Joda is a date/time library that supports parsing date/times from strings and formatting strings from date/times, amongst other things. Let's pick the well-known one, Joda Time. These are libraries that XStream uses for lower-level XML stuff.īut what are all of these optional dependencies? Note that there are only two dependencies here that are not listed as optional, xmlpull and xpp3_min. If we check, these are the listed dependencies for XStream: Group What you find, especially when you deploy your OSGi bundles, is that you not only have your direct dependencies like the servlet spec jar or the XStream jar, but there are also indirect dependencies to deal with. Runtime dependencies are not as straight forward. That's really it you need a class from, say, the XStream XOM package, well then you declare your dependency on in it your adle file and your code compiles just fine. Oh, you want to create a servlet filter? Fine, you just have a compile time dependency as expressed in a adle file like:ĬompileOnly group: "rvlet", name: "rvlet-api", version: "3.0.1"īasically a compile time dependency is a dependency needed by the compiler to compile your java files into class files. There are compile time dependencies and there are runtime dependencies.Ĭompile time dependencies are those direct dependencies that we developers are always familiar with. So here's the thing - dependencies come in two forms. īasically a developer was able to get Apache POI pulled into a module, but they did so by replicating all of the "optional" directives into the bnd.bnd file and eventually putting it into the bundle's manifest. Just a quick blog post to talk about compile time vs runtime dependencies in the OSGi container, inspired by this thread.
0 Comments
Leave a Reply. |