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
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
