Karaf features + Sigil launch

[David Savage <da...@paremus.com>]

Hi there,

I'm currently looking into how to set up a launch configuration for
Sigil development in the IDE and one idea that seems quite attractive
is to reuse the Karaf features format to list the bundles that the
user wishes to install in the framework. The use case I'm looking to
solve is initial boot of an OSGi framework from the IDE with a pre
configured set of bundles. Once the framework is running it will be
possible to install and uninstall individual bundles via the IDE to
allow for update of classes during debug. But this initial step allows
us to boot a framework into a known state.

Some areas that I'm a little hazy about...

* Editor support for features files - is there any available plugins
for Eclipse in this area?
* Extensions to the karaf format to support sigil projects (ivy dependencies?)
* Support for Karaf features from a remote process - how tied is the
org/apache/felix/karaf/features/*.java code to a local framework? I
think it makes sense drive this from an external process vs installing
Karaf in the framework as this would allow us to debug Karaf. This
would involve having a Karaf driver in the IDE that understands the
Karaf features file format and uses it to make install and start
commands into the external framework process.

The other idea that sprang to mind was the pax runner profile format.
Can anyone comment on the relative pros and cons of each format?

Regards,

Dave

Re: Karaf features + Sigil launch

[David Savage <da...@paremus.com>]

On Tue, Oct 6, 2009 at 5:36 PM, Alin Dreghiciu <ad...@gmail.com> wrote:
> Dave,
> If you like we can get into a discussion on what you need and the reasons
> behind. I have that feeling that Pax Runner infrastructure can satisfy your
> requirements. For example, Pax Runner can be started in such a way that it
> will give you back all you need to start a traget framework such as the
> framework jar, configuration file that include all the necessary properties
> to start up the framework + the bundles to be installed / started, setup
> class path, java vm startup options and so on.
>
> Think about. You can start any framework, any version. And also, I can make
> Pax Runner a separated eclipse plugin that can be shared between Pax Runner
> Eclipse Plugin and Sigil. Did you had the time to look at pax runner eclipse
> plugin?

I had a quick look it looks very useful and as you say being able to
start any framework is a useful feature my only up front "concern" is
that it reuses the PDE osgi framework widget for launch configuration.
I can certainly understand why you do this as it saves reinventing
code.

However, this puts a dependency on the PDE concept of target platform
(specifically having to manually create a directory that contains all
the platform dependencies)

In sigil I'm trying to get away from the explicit creation of a target
platform and instead define the target as a dynamic set of bundles
based on requirements which are resolved against available
repositories...here I thought the use of a karaf or pax profile might
be a more flexible way of defining the config. Instead a large gui
widget in the launch config you just point the launcher at various
config files from your workspace.

>
> More if you do not need the whole pax runner infra we can work on a setup
> where you can use Pax Scanner outside the targeted framework process.
>
> lets get into a chat session and figure out what you will need ;)

That sounds like a good idea, I'll ping you offlist with my contact details...

Regards,

Dave

>
> On Tue, Oct 6, 2009 at 1:31 PM, David Savage <da...@paremus.com>wrote:
>
>> On Tue, Oct 6, 2009 at 10:27 AM, Alin Dreghiciu <ad...@gmail.com>
>> wrote:
>> > I do not want to compare the two formats so here fact about the "profile"
>>
>> Fair enough, yep I realized just after I sent my mail this could be
>> asking for trouble - that is not my intention just to figure out what
>> is the "best" way to achieve this.
>>
>> > format: * profile format is the format that can be scanned by a composite
>> > scanner (scan-composite:). Here is some more documentation:
>> > http://paxrunner.ops4j.org/display/paxrunner/Composite+provisioning
>> > * it can include any other provisioning specs so you can scan from karaf
>> > features, simple text files containing bundles urls, maven poms,
>> directories
>> > containing bundles, zips containing jars, any bundle referenced by url.
>> > * it can include references to another composite scanners.
>> > * there are a bunch of such files in Pax Runner repository:
>> > http://paxrunner.ops4j.org/space/Pax+Runner+profiles+list (
>> >
>> https://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/org/ops4j/pax/runner/profiles/
>> > )
>> > * the whole functionality about using this scanners is extracted out of
>> pax
>> > runner into pax scanner project
>>
>> Does the scanner run in the framework process? I think for isolation
>> reasons it make sense to make the framework a very thin client with
>> very few dependencies installed, this ensures that when you debug
>> you're actually debugging your code and not some accidental collision
>> with pre resolved bundles in the framework. Consider the case where
>> you'd want to debug pax scanner for example? Or more likely some other
>> application that happens to share dependencies with pax-scanner and
>> you want to ensure you're debugging precisely your set of bundle
>> dependencies.
>>
>> >
>> > Now related to the part where you launch an osgi framework you may want
>> to
>> > take a look at pax runner eclipse plugin that allows you to start any OSS
>> > framework / any version and we can discuss about any features you may
>> need.
>>
>> I'll take a look, that's basically what I'm trying to write a gui for
>> at the moment - but I would love not to have to reinvent this
>> particular wheel as it involves a lot of GUI code that I can do but
>> always feels a little like pulling teeth ;)
>>
>> >
>> > About install/update/uninstall bundles in the external running framework
>> you
>> > may want to look at Pax Exam RBC (remote bundle context) that we use it
>> to
>> > allow the install/uninstall of bundles from outside of the process (RMI)
>> +
>> > allows to make calls to services in the remote process. Again, if any
>> > special needs, let me know.
>>
>> That sounds similar to something I've started here too i.e. a launcher
>> for Sigil that uses a socket based approach to control the framework
>> remotely:
>>
>>
>> http://svn.apache.org/viewvc/felix/trunk/sigil/common/runtime/src/org/apache/felix/sigil/common/runtime/Client.java?view=markup
>>
>> The point about using sockets was to again reduce the dependencies on
>> the framework to a minimum. This does seem to have some overlap with
>> the pax exam functionality. Maybe there's some mileage in coming up
>> with a common model for this?
>>
>> >
>> > About ivy is just a matter (I think) of implementing an url handler as we
>> > did for maven. Actually we have an issue there to support it but yet
>> there
>> > was not requested.
>>
>> As per other comments - does this imply the url handler is installed
>> in the remote framework?
>>
>> Thx for the info.
>>
>> Regards,
>>
>> Dave
>>
>> >
>> > HTH
>> >
>> > On Tue, Oct 6, 2009 at 11:20 AM, David Savage <david.savage@paremus.com
>> >wrote:
>> >
>> >> Hi there,
>> >>
>> >> I'm currently looking into how to set up a launch configuration for
>> >> Sigil development in the IDE and one idea that seems quite attractive
>> >> is to reuse the Karaf features format to list the bundles that the
>> >> user wishes to install in the framework. The use case I'm looking to
>> >> solve is initial boot of an OSGi framework from the IDE with a pre
>> >> configured set of bundles. Once the framework is running it will be
>> >> possible to install and uninstall individual bundles via the IDE to
>> >> allow for update of classes during debug. But this initial step allows
>> >> us to boot a framework into a known state.
>> >>
>> >> Some areas that I'm a little hazy about...
>> >>
>> >> * Editor support for features files - is there any available plugins
>> >> for Eclipse in this area?
>> >> * Extensions to the karaf format to support sigil projects (ivy
>> >> dependencies?)
>> >> * Support for Karaf features from a remote process - how tied is the
>> >> org/apache/felix/karaf/features/*.java code to a local framework? I
>> >> think it makes sense drive this from an external process vs installing
>> >> Karaf in the framework as this would allow us to debug Karaf. This
>> >> would involve having a Karaf driver in the IDE that understands the
>> >> Karaf features file format and uses it to make install and start
>> >> commands into the external framework process.
>> >>
>> >> The other idea that sprang to mind was the pax runner profile format.
>> >> Can anyone comment on the relative pros and cons of each format?
>> >>
>> >> Regards,
>> >>
>> >> Dave
>> >>
>> >
>> >
>> >
>> > --
>> > Alin Dreghiciu
>> > Software Developer
>> > My profile: http://www.linkedin.com/in/alindreghiciu
>> > My blog: http://adreghiciu.blogspot.com
>> > http://www.ops4j.org - New Energy for OSS Communities - Open
>> Participation
>> > Software.
>> > http://www.qi4j.org - New Energy for Java - Domain Driven Development.
>> >
>>
>
>
>
> --
> Alin Dreghiciu
> Software Developer
> My profile: http://www.linkedin.com/in/alindreghiciu
> My blog: http://adreghiciu.blogspot.com
> http://www.ops4j.org - New Energy for OSS Communities - Open Participation
> Software.
> http://www.qi4j.org - New Energy for Java - Domain Driven Development.
>

Re: Karaf features + Sigil launch

[Alin Dreghiciu <ad...@gmail.com>]

Dave,
If you like we can get into a discussion on what you need and the reasons
behind. I have that feeling that Pax Runner infrastructure can satisfy your
requirements. For example, Pax Runner can be started in such a way that it
will give you back all you need to start a traget framework such as the
framework jar, configuration file that include all the necessary properties
to start up the framework + the bundles to be installed / started, setup
class path, java vm startup options and so on.

Think about. You can start any framework, any version. And also, I can make
Pax Runner a separated eclipse plugin that can be shared between Pax Runner
Eclipse Plugin and Sigil. Did you had the time to look at pax runner eclipse
plugin?

More if you do not need the whole pax runner infra we can work on a setup
where you can use Pax Scanner outside the targeted framework process.

lets get into a chat session and figure out what you will need ;)

On Tue, Oct 6, 2009 at 1:31 PM, David Savage <da...@paremus.com>wrote:

> On Tue, Oct 6, 2009 at 10:27 AM, Alin Dreghiciu <ad...@gmail.com>
> wrote:
> > I do not want to compare the two formats so here fact about the "profile"
>
> Fair enough, yep I realized just after I sent my mail this could be
> asking for trouble - that is not my intention just to figure out what
> is the "best" way to achieve this.
>
> > format: * profile format is the format that can be scanned by a composite
> > scanner (scan-composite:). Here is some more documentation:
> > http://paxrunner.ops4j.org/display/paxrunner/Composite+provisioning
> > * it can include any other provisioning specs so you can scan from karaf
> > features, simple text files containing bundles urls, maven poms,
> directories
> > containing bundles, zips containing jars, any bundle referenced by url.
> > * it can include references to another composite scanners.
> > * there are a bunch of such files in Pax Runner repository:
> > http://paxrunner.ops4j.org/space/Pax+Runner+profiles+list (
> >
> https://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/org/ops4j/pax/runner/profiles/
> > )
> > * the whole functionality about using this scanners is extracted out of
> pax
> > runner into pax scanner project
>
> Does the scanner run in the framework process? I think for isolation
> reasons it make sense to make the framework a very thin client with
> very few dependencies installed, this ensures that when you debug
> you're actually debugging your code and not some accidental collision
> with pre resolved bundles in the framework. Consider the case where
> you'd want to debug pax scanner for example? Or more likely some other
> application that happens to share dependencies with pax-scanner and
> you want to ensure you're debugging precisely your set of bundle
> dependencies.
>
> >
> > Now related to the part where you launch an osgi framework you may want
> to
> > take a look at pax runner eclipse plugin that allows you to start any OSS
> > framework / any version and we can discuss about any features you may
> need.
>
> I'll take a look, that's basically what I'm trying to write a gui for
> at the moment - but I would love not to have to reinvent this
> particular wheel as it involves a lot of GUI code that I can do but
> always feels a little like pulling teeth ;)
>
> >
> > About install/update/uninstall bundles in the external running framework
> you
> > may want to look at Pax Exam RBC (remote bundle context) that we use it
> to
> > allow the install/uninstall of bundles from outside of the process (RMI)
> +
> > allows to make calls to services in the remote process. Again, if any
> > special needs, let me know.
>
> That sounds similar to something I've started here too i.e. a launcher
> for Sigil that uses a socket based approach to control the framework
> remotely:
>
>
> http://svn.apache.org/viewvc/felix/trunk/sigil/common/runtime/src/org/apache/felix/sigil/common/runtime/Client.java?view=markup
>
> The point about using sockets was to again reduce the dependencies on
> the framework to a minimum. This does seem to have some overlap with
> the pax exam functionality. Maybe there's some mileage in coming up
> with a common model for this?
>
> >
> > About ivy is just a matter (I think) of implementing an url handler as we
> > did for maven. Actually we have an issue there to support it but yet
> there
> > was not requested.
>
> As per other comments - does this imply the url handler is installed
> in the remote framework?
>
> Thx for the info.
>
> Regards,
>
> Dave
>
> >
> > HTH
> >
> > On Tue, Oct 6, 2009 at 11:20 AM, David Savage <david.savage@paremus.com
> >wrote:
> >
> >> Hi there,
> >>
> >> I'm currently looking into how to set up a launch configuration for
> >> Sigil development in the IDE and one idea that seems quite attractive
> >> is to reuse the Karaf features format to list the bundles that the
> >> user wishes to install in the framework. The use case I'm looking to
> >> solve is initial boot of an OSGi framework from the IDE with a pre
> >> configured set of bundles. Once the framework is running it will be
> >> possible to install and uninstall individual bundles via the IDE to
> >> allow for update of classes during debug. But this initial step allows
> >> us to boot a framework into a known state.
> >>
> >> Some areas that I'm a little hazy about...
> >>
> >> * Editor support for features files - is there any available plugins
> >> for Eclipse in this area?
> >> * Extensions to the karaf format to support sigil projects (ivy
> >> dependencies?)
> >> * Support for Karaf features from a remote process - how tied is the
> >> org/apache/felix/karaf/features/*.java code to a local framework? I
> >> think it makes sense drive this from an external process vs installing
> >> Karaf in the framework as this would allow us to debug Karaf. This
> >> would involve having a Karaf driver in the IDE that understands the
> >> Karaf features file format and uses it to make install and start
> >> commands into the external framework process.
> >>
> >> The other idea that sprang to mind was the pax runner profile format.
> >> Can anyone comment on the relative pros and cons of each format?
> >>
> >> Regards,
> >>
> >> Dave
> >>
> >
> >
> >
> > --
> > Alin Dreghiciu
> > Software Developer
> > My profile: http://www.linkedin.com/in/alindreghiciu
> > My blog: http://adreghiciu.blogspot.com
> > http://www.ops4j.org - New Energy for OSS Communities - Open
> Participation
> > Software.
> > http://www.qi4j.org - New Energy for Java - Domain Driven Development.
> >
>



-- 
Alin Dreghiciu
Software Developer
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.

Re: Karaf features + Sigil launch

[David Savage <da...@paremus.com>]

On Tue, Oct 6, 2009 at 10:27 AM, Alin Dreghiciu <ad...@gmail.com> wrote:
> I do not want to compare the two formats so here fact about the "profile"

Fair enough, yep I realized just after I sent my mail this could be
asking for trouble - that is not my intention just to figure out what
is the "best" way to achieve this.

> format: * profile format is the format that can be scanned by a composite
> scanner (scan-composite:). Here is some more documentation:
> http://paxrunner.ops4j.org/display/paxrunner/Composite+provisioning
> * it can include any other provisioning specs so you can scan from karaf
> features, simple text files containing bundles urls, maven poms, directories
> containing bundles, zips containing jars, any bundle referenced by url.
> * it can include references to another composite scanners.
> * there are a bunch of such files in Pax Runner repository:
> http://paxrunner.ops4j.org/space/Pax+Runner+profiles+list (
> https://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/org/ops4j/pax/runner/profiles/
> )
> * the whole functionality about using this scanners is extracted out of pax
> runner into pax scanner project

Does the scanner run in the framework process? I think for isolation
reasons it make sense to make the framework a very thin client with
very few dependencies installed, this ensures that when you debug
you're actually debugging your code and not some accidental collision
with pre resolved bundles in the framework. Consider the case where
you'd want to debug pax scanner for example? Or more likely some other
application that happens to share dependencies with pax-scanner and
you want to ensure you're debugging precisely your set of bundle
dependencies.

>
> Now related to the part where you launch an osgi framework you may want to
> take a look at pax runner eclipse plugin that allows you to start any OSS
> framework / any version and we can discuss about any features you may need.

I'll take a look, that's basically what I'm trying to write a gui for
at the moment - but I would love not to have to reinvent this
particular wheel as it involves a lot of GUI code that I can do but
always feels a little like pulling teeth ;)

>
> About install/update/uninstall bundles in the external running framework you
> may want to look at Pax Exam RBC (remote bundle context) that we use it to
> allow the install/uninstall of bundles from outside of the process (RMI) +
> allows to make calls to services in the remote process. Again, if any
> special needs, let me know.

That sounds similar to something I've started here too i.e. a launcher
for Sigil that uses a socket based approach to control the framework
remotely:

http://svn.apache.org/viewvc/felix/trunk/sigil/common/runtime/src/org/apache/felix/sigil/common/runtime/Client.java?view=markup

The point about using sockets was to again reduce the dependencies on
the framework to a minimum. This does seem to have some overlap with
the pax exam functionality. Maybe there's some mileage in coming up
with a common model for this?

>
> About ivy is just a matter (I think) of implementing an url handler as we
> did for maven. Actually we have an issue there to support it but yet there
> was not requested.

As per other comments - does this imply the url handler is installed
in the remote framework?

Thx for the info.

Regards,

Dave

>
> HTH
>
> On Tue, Oct 6, 2009 at 11:20 AM, David Savage <da...@paremus.com>wrote:
>
>> Hi there,
>>
>> I'm currently looking into how to set up a launch configuration for
>> Sigil development in the IDE and one idea that seems quite attractive
>> is to reuse the Karaf features format to list the bundles that the
>> user wishes to install in the framework. The use case I'm looking to
>> solve is initial boot of an OSGi framework from the IDE with a pre
>> configured set of bundles. Once the framework is running it will be
>> possible to install and uninstall individual bundles via the IDE to
>> allow for update of classes during debug. But this initial step allows
>> us to boot a framework into a known state.
>>
>> Some areas that I'm a little hazy about...
>>
>> * Editor support for features files - is there any available plugins
>> for Eclipse in this area?
>> * Extensions to the karaf format to support sigil projects (ivy
>> dependencies?)
>> * Support for Karaf features from a remote process - how tied is the
>> org/apache/felix/karaf/features/*.java code to a local framework? I
>> think it makes sense drive this from an external process vs installing
>> Karaf in the framework as this would allow us to debug Karaf. This
>> would involve having a Karaf driver in the IDE that understands the
>> Karaf features file format and uses it to make install and start
>> commands into the external framework process.
>>
>> The other idea that sprang to mind was the pax runner profile format.
>> Can anyone comment on the relative pros and cons of each format?
>>
>> Regards,
>>
>> Dave
>>
>
>
>
> --
> Alin Dreghiciu
> Software Developer
> My profile: http://www.linkedin.com/in/alindreghiciu
> My blog: http://adreghiciu.blogspot.com
> http://www.ops4j.org - New Energy for OSS Communities - Open Participation
> Software.
> http://www.qi4j.org - New Energy for Java - Domain Driven Development.
>

Re: Karaf features + Sigil launch

[Alin Dreghiciu <ad...@gmail.com>]

I do not want to compare the two formats so here fact about the "profile"
format: * profile format is the format that can be scanned by a composite
scanner (scan-composite:). Here is some more documentation:
http://paxrunner.ops4j.org/display/paxrunner/Composite+provisioning
* it can include any other provisioning specs so you can scan from karaf
features, simple text files containing bundles urls, maven poms, directories
containing bundles, zips containing jars, any bundle referenced by url.
* it can include references to another composite scanners.
* there are a bunch of such files in Pax Runner repository:
http://paxrunner.ops4j.org/space/Pax+Runner+profiles+list (
https://scm.ops4j.org/repos/ops4j/projects/pax/runner-repository/org/ops4j/pax/runner/profiles/
)
* the whole functionality about using this scanners is extracted out of pax
runner into pax scanner project

Now related to the part where you launch an osgi framework you may want to
take a look at pax runner eclipse plugin that allows you to start any OSS
framework / any version and we can discuss about any features you may need.

About install/update/uninstall bundles in the external running framework you
may want to look at Pax Exam RBC (remote bundle context) that we use it to
allow the install/uninstall of bundles from outside of the process (RMI) +
allows to make calls to services in the remote process. Again, if any
special needs, let me know.

About ivy is just a matter (I think) of implementing an url handler as we
did for maven. Actually we have an issue there to support it but yet there
was not requested.

HTH

On Tue, Oct 6, 2009 at 11:20 AM, David Savage <da...@paremus.com>wrote:

> Hi there,
>
> I'm currently looking into how to set up a launch configuration for
> Sigil development in the IDE and one idea that seems quite attractive
> is to reuse the Karaf features format to list the bundles that the
> user wishes to install in the framework. The use case I'm looking to
> solve is initial boot of an OSGi framework from the IDE with a pre
> configured set of bundles. Once the framework is running it will be
> possible to install and uninstall individual bundles via the IDE to
> allow for update of classes during debug. But this initial step allows
> us to boot a framework into a known state.
>
> Some areas that I'm a little hazy about...
>
> * Editor support for features files - is there any available plugins
> for Eclipse in this area?
> * Extensions to the karaf format to support sigil projects (ivy
> dependencies?)
> * Support for Karaf features from a remote process - how tied is the
> org/apache/felix/karaf/features/*.java code to a local framework? I
> think it makes sense drive this from an external process vs installing
> Karaf in the framework as this would allow us to debug Karaf. This
> would involve having a Karaf driver in the IDE that understands the
> Karaf features file format and uses it to make install and start
> commands into the external framework process.
>
> The other idea that sprang to mind was the pax runner profile format.
> Can anyone comment on the relative pros and cons of each format?
>
> Regards,
>
> Dave
>



-- 
Alin Dreghiciu
Software Developer
My profile: http://www.linkedin.com/in/alindreghiciu
My blog: http://adreghiciu.blogspot.com
http://www.ops4j.org - New Energy for OSS Communities - Open Participation
Software.
http://www.qi4j.org - New Energy for Java - Domain Driven Development.