Hi Niranda, On Mon, Apr 6, 2015 at 10:25 AM, Niranda Perera <nira...@wso2.com> wrote:
> 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 is exactly the expected behavior. You need to declare all the dependencies of a component in the pom.xml for compilation and testing. All the dependencies of a carbon component should be OSGi bundles. There are few exceptions though. Thanks, Sameera. > > 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 <same...@wso2.com> > 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 <go...@wso2.com> >> 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 <nira...@wso2.com> 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 >>>> Dev@wso2.org >>>> 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: same...@wso2.com >> 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> > -- Sameera Jayasoma, Software Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com 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 Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
