felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brad Cox <b...@virtualschool.edu>
Subject Re: The right way to chase dependencies?
Date Wed, 12 Nov 2008 12:31:10 GMT
What's puzzling me is why these dependencies are getting handled (or 
perhaps ignored) at compile time and bundle build time, then surfacing 
at load/update time. I thought embed transitive was supposed to deal 
with that at bundle build time.

obr seems tantalizing for load time resolution but I don't see how it 
helps with my current problem, finding dependencies of poorly understood 
source code. Am I missing something?

Atle Prange wrote:
> You could look into the bundle repository OBR. Its documented on the 
> felix pages.
> 
> You build a repository over all your bundles, and when you use the 
> bundlerepository bundle in felix to install from the repository it 
> automatically deploys all the dependencies too.
> 
> This means that you have to index your bundles with a tool called 
> BIndex, or use maven-bundle-plugin to build your bundles.
> 
> take a look at
> http://felix.apache.org/site/apache-felix-osgi-bundle-repository.html
> http://felix.apache.org/site/apache-felix-maven-bundle-plugin-bnd.html
> http://www.osgi.org/Repository/BIndex
> 
> It can take a while to get it working flawlessly, but once it runs it's 
> smooth.
> 
> hilsen
> Atle
> 
> Brad Cox wrote:
>> What's the right way to chase dependencies?
>>
>> One of my components is an OpenSSO policy enforcement point that 
>> originated with source code from a Netbeans tutorial. It has 
>> dependencies to god know what. I can work the OpenSSO issues. What I 
>> need help with is how experts deal with similar problems. I don't want 
>> to rework that until I get what I have now to load.
>>
>> This shows where I'm at and how I've been dealing with it. My current 
>> goal (unless someone can show a better way) is for the core and each 
>> component to fully (transitively) enclose all of its dependencies. 
>> That makes for big jars and slow compiles but that's the mental model 
>> I'm working; that a component should contain everything it needs (with 
>> obvious exceptions for java.*, soakit.core.*, etc).
>>
>> I'm new to this and don't understand whether other models exist that 
>> might work, for example tracking down dependencies at load time (seems 
>> that violates the goal to me but whatta I know; I'm the newbie).
>>
>> -> ps
>> START LEVEL 1
>>    ID   State         Level  Name
>> [   0] [Active     ] [    0] System Bundle (1.2.1)
>> [   1] [Active     ] [    1] Apache Felix Shell Service (1.0.2)
>> [   2] [Active     ] [    1] Apache Felix Shell TUI (1.0.2)
>> [   3] [Active     ] [    1] Apache Felix Bundle Repository (1.2.0)
>> [   4] [Active     ] [    1] soakit.core (1.0.0.SNAPSHOT)
>> [   5] [Active     ] [    1] iPOJO (1.0.0)
>> [   6] [Active     ] [    1] soakit.port.file (1.0.0.SNAPSHOT)
>> [   7] [Active     ] [    1] soakit.transform.identity (1.0.0.SNAPSHOT)
>> [   9] [Active     ] [    1] soakit.port.http (1.0.0.SNAPSHOT)
>> [  13] [Active     ] [    1] soakit.transform.log (1.0.0.SNAPSHOT)
>> [  14] [Installed  ] [    1] soakit.transform.pep (1.0.0.SNAPSHOT)
>> [  15] [Active     ] [    1] soakit.transform.xsl (1.0.0.SNAPSHOT)
>> [  16] [Resolved   ] [    1] soakit.main (1.0.0.SNAPSHOT)
>> [  17] [Installed  ] [    1] soakit.test (1.0.0.SNAPSHOT)
>> -> update 14
>> org.osgi.framework.BundleException: Unresolved constraint in bundle 
>> 14: package; (package=com.sun.msv.grammar.trex)
>> -> update 14
>> org.osgi.framework.BundleException: Unresolved constraint in bundle 
>> 14: package; (package=com.sun.msv.grammar.trex)
>> -> update 14
>> org.osgi.framework.BundleException: Unresolved constraint in bundle 
>> 14: package; (package=com.sun.xml.fastinfoset.dom)
>> -> update 14
>> org.osgi.framework.BundleException: Unresolved constraint in bundle 
>> 14: package; (package=com.bea.staxb.buildtime.internal.tylar)
>> ->
>>
>> Each try takes about 30 minutes right now, and there's no sign this 
>> chase is near ended. Surely there's a better way. Please share it.
>>
>> ------------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 
> 



Mime
View raw message