Hi Sameera, I agree with you on the compilation scenario. It was mistake on my part.
But recently I came across with this issue. Pls consider the following scenario. a non-OSGI jar say, 'foo.jar' depends on the 'a.jar' and 'b.jar' which are OSGI bundles. foo (non-OSGI) |_ a (OSGI) |_ b (OSGI) I OSGIfy foo.jar designating a & b as import-packages to make the "foo-orbit.jar". when I compile my component using foo-orbit.jar it compiles without an issue. but when I run the unit tests of the component, in the run-time I encounter classnotfound exceptions in the classes of a.jar and b.jar. so, I have to specify a and b as dependencies in the component along with the foo-orbit. when I compile the component using the original foo, compilation and testing (run-time) happens seamlessly without having to specify a & b dependencies individually. Is this the expected behavior? this issue occurred to me while I was testing the spark components with the spark orbits. and the classnotfound exceptions are thrown in the spark server start-up. Gokul also told me that he encountered a similar problem with the hadoop client orbit. look forward to know your thoughts in this regard. rgds On Wed, Mar 25, 2015 at 4:36 PM, Sameera Jayasoma <[email protected]> wrote: > We are in the process of getting rid of transitive dependencies from > orbits, carbon components etc. > > If your component requires the original Spark libraries for compilation > then there are obvious issues in your Spark orbit bundle. A component > should be able compile using orbits and other component dependencies. If > this is not possible, then your component dependencies are not properly > "OSGified" > > A component shouldn't depend on transitive dependencies. Thats the plan. > If you see issues with this approach, please explain. > > Thanks, > Sameera. > > > > On Tue, Mar 24, 2015 at 11:00 AM, Gokul Balakrishnan <[email protected]> > wrote: > >> Hi Kernel team, >> >> Any idea on $subject? Shouldn't the transitive dependencies of the orbit >> bundle be visible to the component referring to the bundle at compile time? >> Should we just refer to the 3rd party jar (the orbit bundle is wrapping) in >> the component and use the orbit in the feature, or should we use the orbit >> bundle for both? Would be great if you could clarify. >> >> Thanks, >> >> On 23 March 2015 at 14:59, Niranda Perera <[email protected]> wrote: >> >>> Hi, >>> >>> As of the current orbit bundle guideline [1], we have to mark the >>> dependencies as optional. I believe this results in transitive dependencies >>> of that particular bundle not being exposed. >>> >>> Because of this, I have experienced compilation failures, when I put >>> orbit bundles as component dependencies. >>> For an example, in carbon analytics components, when I import spark-core >>> orbit, I encsounter dependency errors (But when I import the original spark >>> dependency this does not occur) >>> >>> so, is it a good practice for us to say that, orbit bundles should be >>> used in the runtime, where as in the compile time, use the original jars? >>> essentially, is it okay to include original jars in the components and >>> only include orbits in the features? (because earlier, I was under the >>> impression that, once an orbit bundle is created, it should be used BOTH in >>> the components and in the feature) >>> >>> would be great if you could clarify this matter. >>> >>> rgds >>> >>> [1] >>> https://docs.google.com/a/wso2.com/document/d/1I3nWPnG6139YobZzQWPFOUxYEmHxqf9ieWykmQupPtc/edit# >>> >>> -- >>> *Niranda Perera* >>> Software Engineer, WSO2 Inc. >>> Mobile: +94-71-554-8430 >>> Twitter: @n1r44 <https://twitter.com/N1R44> >>> >>> _______________________________________________ >>> Dev mailing list >>> [email protected] >>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>> >>> >> >> >> -- >> *Balakrishnan Gokulakrishnan* >> Software Engineer, >> WSO2, Inc. http://wso2.com >> Mob: +94 77 593 5789 | +1 650 272 9927 >> > > > > -- > Sameera Jayasoma, > Software Architect, > > WSO2, Inc. (http://wso2.com) > email: [email protected] > blog: http://blog.sameera.org > twitter: https://twitter.com/sameerajayasoma > flickr: http://www.flickr.com/photos/sameera-jayasoma/collections > Mobile: 0094776364456 > > Lean . Enterprise . Middleware > > -- *Niranda Perera* Software Engineer, WSO2 Inc. Mobile: +94-71-554-8430 Twitter: @n1r44 <https://twitter.com/N1R44>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
