Richard S. Hall wrote: > I don't think so. OBR requires a bundle symbolic name, because this > plus version is a unique identifier.
Hmmm. I wonder how this worked: -> obr info "Framework Data Source" --------------------- Framework Data Source --------------------- description: Data Source Layer. documentation: file:../temp/repository.xml id: 1 license: file:../temp/repository.xml presentationname: Framework Data Source size: 7783 source: file:../temp/repository.xml symbolicname: Framework Data Source url: file:../temp/Build/bundles/fwk-ds.jar version: 1.1.0 ... -> obr deploy "Framework Data Source" Target resource(s): ------------------- Framework Data Source (1.1.0) Deploying...done. Rick Litton -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 12:02 PM To: felix-dev@incubator.apache.org Subject: Re: Another OBR issue On Feb 8, 2007, at 1:18 PM, Rick Litton wrote: > Steven wrote: > >> It looks like either the symbolic name or the version are nil. I > haven't been able to track down all the ways this could be so. > > Looking at the output from obr info, the repository.xml generated by > bindex shows that the Bundle-Name has been used as a substitute > when the > Bundle-SymbolicName descriptor is missing from the manifest. Hence my > guess is that the obr deploy command fails with an NPE only when > dependencies are not satisfied. I don't think so. OBR requires a bundle symbolic name, because this plus version is a unique identifier. -> richard > > > Rick Litton > > > -----Original Message----- > From: Steven E. Harris [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 08, 2007 9:51 AM > To: felix-dev@incubator.apache.org > Subject: Re: Another OBR issue > > Rick Litton <[EMAIL PROTECTED]> writes: > >> java.lang.NullPointerException >> at >> > org.apache.felix.bundlerepository.ResourceImpl.hashCode > (ResourceImpl.jav >> a:79) > > ,----[ ResourceImpl.hashCode source ] > | public int hashCode() > | { > | return getSymbolicName().hashCode() ^ getVersion().hashCode(); > | } > `---- > > It looks like either the symbolic name or the version are nil. I > haven't been able to track down all the ways this could be so. Do you > know if the ResourceImpl here is a LocalResourceImpl, or one created > by RepositoryImpl's parsing of an XML file? > > -- > Steven E. Harris