Richard S. Hall wrote: > Are you saying that your bundle's manifest does not contain a symbolic
> name and the one shown below is given by default? Yes, that's correct. Here is a portion of the manifest: Bundle-Name: Framework Data Source Bundle-Description: Data Source Layer. Bundle-Version: 1.1 Bundle-Activator: com....framework.ds.Activator Bundle-ClassPath: . Export-Package: ... Import-Package: ... I was just hoping that the exception from OBR will be able describe what dependency failed to resolve so that the appropriate action can be taken. I will also try to insert some code to make this happen as well. Thanks in advance. Rick Litton -----Original Message----- From: Richard S. Hall [mailto:[EMAIL PROTECTED] Sent: Thursday, February 08, 2007 2:04 PM To: felix-dev@incubator.apache.org Subject: Re: Another OBR issue On Feb 8, 2007, at 3:09 PM, Rick Litton wrote: > 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: Are you saying that your bundle's manifest does not contain a symbolic name and the one shown below is given by default? I don't recall doing it that way, but anything is possible...it has been a long time since I worked on OBR. The last time I saw this bug, though, I am fairly certain it was because there was no symbolic name. I will try to take a closer look at it and see if I can see what is going on. -> richard > > -> 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 >
