Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Received-SPF: pass (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <fd848f8b0908201238s22fc9085r43d15aede153eda7@mail.gmail.com>
References: <fd848f8b0908201138i4e1622abvb36fd406d2d07ba0@mail.gmail.com>
	 <4A8D9E98.5030100@ungoverned.org>
	 <fd848f8b0908201217u5c6b464cre7c5b8cc03c3e1a2@mail.gmail.com>
	 <4A8DA544.2080302@ungoverned.org>
	 <fd848f8b0908201238s22fc9085r43d15aede153eda7@mail.gmail.com>
Date: Tue, 6 Oct 2009 16:19:15 +0100
Message-ID: <fd848f8b0910060819v4147541eq7b3b74dae8522a74@mail.gmail.com>
Subject: Re: Sigil launcher
From: David Savage <david.savage@paremus.com>
To: dev@felix.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Aug 20, 2009 at 8:38 PM, David Savage <dave.savage@paremus.com> wrote:
> On Thu, Aug 20, 2009 at 8:34 PM, Richard S. Hall<heavy@ungoverned.org> wrote:
>> On 8/20/09 15:17, David Savage wrote:
>>>
>>> Sure like the felix launcher with the bundles dir which is like a
>>> simple version of fileinstall - this is a lowest common denominator
>>> type approach for remote control of an OSGi runtime. As you say I
>>> /could/ use the directory based bundle launch mechanism to start the
>>> server as a bundle - but what if that's the behaviour we wanted to
>>> debug via the ide - separating it out stuck me as cleaner as long as
>>> it remains light weight. From the IDE perspective I want to be able to
>>> bring the OSGi runtime up with as few dependencies as possible - as
>>> then what ever you debug is out of band of the IDE interaction.
>>>
>>
>> Still, we could potentially accomplish this via a wrapper approach. For
>> example, we could modify our Main.java launcher to have a
>> Main.getFramework() method. Then in the wrapper, you could invoke
>> Main.main() to start the framework, call Main.getFramework() to get the
>> created instance, open your socket and go to town. This would involve
>> minimal dependencies too, but would avoid duplicating launcher code.
>
> Ok yep, that makes sense.
>
>>
>> Well, let's see what other people think.

Sorry for the multiple emails on this but I'm going around the houses
on this launch support and I think I've come back to this idea. I like
the idea of using karaf or pax profiles but having taken the time to
have a look around they both have quite a few (useful) added extras
that unfortunately make them complex to use out side of their own
domains.

For karaf the support for configs is a dependency that would be
difficult to replicate from a standalone launcher and for both pax and
karaf the support for urls in mvn format whilst useful is difficult to
replicate outside of this context.

So I'm thinking that the simplest option is for the sigil launch
config to specify a felix config.properties which lists the bundles
that should be automatically booted into the framework. This allows
you to boot a framework into a known state and then use the socket
based API to do the later tweeking.

To launch an eclipse install via the felix launcher the
config.properties could look something like:

felix.auto.deploy.dir=/opt/eclipse/plugins

I just tried this myself on a felix 2.0.0 install using the following
command line:

java -cp /opt/eclipse-SDK-3.5.1/plugins/org.eclipse.osgi_3.5.1.R35x_v20090827.jar:bin/felix.jar
org.apache.felix.main.Main

and promptly ran into a bunch of resolution failures but this at least
proves it's trying to launch it...

I just had a quick look at the framework issues in jira and I don't
think this (Main.getFramework()) feature has been raised? I'm happy to
do this and take a stab at supplying a patch if this all sounds ok?

Regards,

Dave

>
> Indeed.
>
> Regards,
>
> Dave
>
>>
>> -> richard
>>
>>
>