Mailing-List: contact felix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: felix-dev@incubator.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
From: "Steven E. Harris" <seh@panix.com>
To: felix-dev@incubator.apache.org
Subject: Re: Programmatic/non-shell-based interface to OBR
Organization: SEH Labs
References: <q94y7punkm1.fsf@chlorine.gnostech.com>
	<456DDF2E.90602@ungoverned.org>
	<q94k61dn9jh.fsf@chlorine.gnostech.com>
	<475625fea8a1df57e25ba90c7a4dd337@ungoverned.org>
	<q94r6vllry7.fsf@chlorine.gnostech.com>
	<7539b3031e3fdb657c50548ab94101b0@ungoverned.org>
	<q94zma8kjep.fsf@chlorine.gnostech.com>
	<456F0D85.3060603@ungoverned.org>
	<q94psb4iut4.fsf@chlorine.gnostech.com>
	<456F37A8.8060909@ungoverned.org>
Date: Thu, 30 Nov 2006 13:36:42 -0800
Message-ID: <q944psgiplg.fsf@chlorine.gnostech.com>
User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.13 (cygwin32)
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

"Richard S. Hall" <heavy@ungoverned.org> writes:

> In the future if we provide a static method to return a Resource
> from a Bundle, then we would put everything in a public package so
> that it could be easily imported. Unfortunately, that doesn't exist
> now, so the only way to do it is to copy that code into your own
> bundle.

As I mentioned, I finished hoisting LocalResourceImpl into my code
just for the sake of mapping a Bundle to a Resource. I then had to
edit bundlerepository/pom.xml to export the would-be private
org.apache.felix.bundlerepository package from the bundlerepository
bundle.

After all that, I can declare

  SUCCESS!

It works. In my application, I install a bundle that I know has
unsatisfied dependencies. I have those necessary dependencies sitting
in a directory on my disk, but its location is immaterial here. Using
the Bindex program, I had created a repository.xml file for this
directory.

Once the first bundle is installed, I created a LocalResourceImpl
instance around it. Of course, I'd rather call on some mapping
function like you suggested to get a Resource from this Bundle. Using
a ServiceTracker�, I got ahold of the RepositoryAdmin service, added
my local repository.xml file, and asked for a Resolver instance.

Next I added my Bundle-based Resource to the Resolver, told it to
resolve() and, upon success, told it to deploy(). It looks like it
figures out not to install the original Bundle again, but obviously
even that is extra work: It would be nice if there was some way to add
/requirements/ to a Resolver rather than Resources themselves (as in
this case, I don't want the added Resource to be deployed, as it's
already installed), but perhaps that's what
RepositoryAdmin.discoverResources() is for.

To that end, it looks like the way to get a Filter string from a
resource is to loop over the Requirements in
Resource.getRequirements() and join the strings returned by
Requirement.getFilter(), using some AND operator.

> Hopefully from your experience we can learn what we need to do to
> make this easier in the future.

Based on the success here, this process can be made to work, but it's
a matter of finding the right place to expose this Bundle->Resource
mapping. Again, I'd prefer that such a mapping be available as part of
the OSGi OBR API, but for now I'd settle for a
Felix-specific-but-publicly-exposed solution as well.

Please let me know if you need more detail about what I did as part of
my experiment. I look forward to hearing of a proposed home for this
mapping function.


Footnotes: 
� Pulling in the org.osgi.compendium bundle has an unfortunate
  dependency on the javax.servlet.http package, though I couldn't
  trace it back to the org.osgi.compendium/pom.xml file.

-- 
Steven E. Harris