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

Reply via email to