Donation of Sigil project to Felix

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

Hi Felix Dev,

I recently attended the OSGi Dev Con and chatted to some of you there
about OSGi development tooling. From these conversations there seemed
to be some interest in a donation of code from the Sigil project as a
sub project of Felix. I understand the process to achieve this is via
an initial email discussion here on the list, which then moves to a
vote if there is enough interest...So here goes...

I guess firstly it's worth explaining what Sigil is and what it isn't
and why we're donating it.

Sigil is an OSGi development tooling framework for IDE (eclipse) and
headless build (ant/ivy). Our website with more info can be found
here: http://sigil.codecauldron.org. We have had a number of
contributions outside of Paremus in the form of issues, bug fixes and
documentation.

Whilst Sigil integrates with eclipse the intention is not to be a
replacement for PDE, though at the moment it has some comparable
features, in the long term I'd like to see both projects sharing
common code base if at all possible. It is not the intention to be an
uber framework either - ideally just specify a number of core API's
for extension and let other projects, PDE, Maven, Ivy, etc do there
own thing in their own space.

The purpose of the donation is to open up the development to a wider
community to make OSGi development tooling better for all users.

To better understand what it is we are considering donating, here are
a list of the main functional features contained in Sigil which are
relevant to generic OSGi development.

* Common properties file - sigil.properties is a human
readable/editable (no xml) file that defines properties such as bsn,
version, package imports, fragments, contents etc.

* Project inheritance - sigil projects can inherit properties from
parent projects (e.g. usecase - leaf nodes don't have to specify
version ranges over and over - define in parent instead)

* Repository Abstraction - API to allow plugin of different repository
providers adapts filesystem and obr at present

* Resolver - uses OSGi semantics (i.e. import package, require-bundle,
fragment-host, etc) to find bundles from repository for addition to
classpath, indexing etc

* Built on BND - In the end the sigil builder takes the rules defined
in sigil and generates BND instructions - ensures spec compliance

* Eclipse Integration
 - Code completion - uses resolver and repositories to propose java
code completion options
 - Search - trivial search integration - lots of improvement could be
done here...
 - Dependency visualisation - graphical view of bundle dependencies
 - Repository browser - graphical view of repository contents
 - Project Model - PDE like front page
 - Version Policies - Rules for working with version ranges in
workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc

* Ivy Integration
 - Ivy resolver plugin that understands sigil.properties and uses
resolver to provide artifacts.

* JUnit test integration - trivial test runner (uses bundle
introspection to find "test bundles") expose tests via command line -
reliant on newton CLI (but easy to port to other CLI)

Outside of these features there are a number of other features which
are specific to our product and are probably less of interest to felix

* SCA integration - likely replaced by eclipse STP integration in
medium term and hence no longer part of Sigil
* IDE runtime integration - currently only works with the newton runtime

There are a couple of outstanding issues which need attention in the
short term and it would be interesting to here opinions from other
OSGi users on other improvements.

* Multiple bundle projects: currently the ivy build can build projects
which create more than one bundle, however the representation of this
is difficult in the UI. Is this a good/bad/ugly idea? Other options?
(I have some ideas but to verbose to list here)
* IDE and Ivy do not share repository config (they use same repository
classes but config needs to be done twice)

In the medium to long term I'm interested in...

* Repository integration - Maven, SVN, etc...
* Extension to other IDE's (netbeans, intellij, etc)
* Integration with other resolvers (ideally resolvers becomes an API),
P2, Felix OBR, Nimble from Paremus
* Code completion in iPOJO, Spring, DS etc...don't need to reinvent
wheel, just tie in with existing tools

What are the next steps if there is any interest from the Felix community?

* For code that is not of interest how can this be managed - should we
donate all code and then prune later - or do we need to prune early?
* Commiter status - in order that any donation does not stagnate it
would be useful to have at least one committer to apache from paremus.
Either/both myself or Derek Baum would be happy to undertake this
role...
* IP clearance - all code was developed by Paremus, but understand
donation needs proper procedures - need to understand process etc.

Hope that's of interest...

Regards,

Dave

-- 
-------------------------------------------------------------------------------------

Paremus Limited. Registered in England. Registration No. 4181472

Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA

Postal Address: 107-111 Fleet Street, London, EC4A 2AB

The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.

If you received this in error, please contact the sender and delete
the material from any computer.

-------------------------------------------------------------------------------------

Re: Donation of Sigil project to Felix

[Karl Pauls <ka...@gmail.com>]

On Fri, May 8, 2009 at 9:25 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
> Hi Dave,
>
> On May 8, 2009, at 10:33 , David Savage wrote:
>
>> Couple of comments inline but in general I get the impression there is
>> interest in taking this further?
>
> Yes, so far I've only seen positive responses!
>
>> I'll assume yes and start work to
>> make a partially cleaned up branch available as an issue. I say
>> partially as I can easilly remove the runtime integration as it is a
>> stand alone module and it is the only part that depends explicitly on
>> newton. If sigil gets accepted we can think about how best to replace
>> this for general osgi runtimes. I may remove the SCA bit now - but
>> won't go overboard as this is a bit more entangled vs being it's own
>> module (we can tidy this up in the medium term should it be an issue).
>
> Ok.
>
>>>>>> - Version Policies [...]
>>>
>>> I've been talking with a couple of people who are doing more research
>>> into
>>> the automated versioning of OSGi bundles, doing all kinds of bytecode
>>> analysis to determine the scope of changes. Again, for the longer term it
>>> would be nice if tools like these could be integrated (if only to
>>> validate
>>> if the version numbers you stuck on your packages and bundles are
>>> correct,
>>> based on the policy you use).
>>
>> As I say I know the PDE guys have done something already in this area
>> - perhaps if we can convince them to make it into a stand alone
>> library would save some reinvention...
>
> Yes, they have a system that does this, but some of the research I'm talking
> about takes this some steps further. Oh well, that's probably something
> worth discussing in the future.
>
>> can apache projects link to
>> eclipse licenced projects?
>
> As far as I know, yes.

Yes, linking is ok.

regards,

Karl

> Greetings, Marcel
>
>



-- 
Karl Pauls
karlpauls@gmail.com

Re: Donation of Sigil project to Felix

[Marcel Offermans <ma...@luminis.nl>]

Hi Dave,

On May 8, 2009, at 10:33 , David Savage wrote:

> Couple of comments inline but in general I get the impression there is
> interest in taking this further?

Yes, so far I've only seen positive responses!

> I'll assume yes and start work to
> make a partially cleaned up branch available as an issue. I say
> partially as I can easilly remove the runtime integration as it is a
> stand alone module and it is the only part that depends explicitly on
> newton. If sigil gets accepted we can think about how best to replace
> this for general osgi runtimes. I may remove the SCA bit now - but
> won't go overboard as this is a bit more entangled vs being it's own
> module (we can tidy this up in the medium term should it be an issue).

Ok.

>>>>> - Version Policies [...]
>> I've been talking with a couple of people who are doing more  
>> research into
>> the automated versioning of OSGi bundles, doing all kinds of bytecode
>> analysis to determine the scope of changes. Again, for the longer  
>> term it
>> would be nice if tools like these could be integrated (if only to  
>> validate
>> if the version numbers you stuck on your packages and bundles are  
>> correct,
>> based on the policy you use).
>
> As I say I know the PDE guys have done something already in this area
> - perhaps if we can convince them to make it into a stand alone
> library would save some reinvention...

Yes, they have a system that does this, but some of the research I'm  
talking about takes this some steps further. Oh well, that's probably  
something worth discussing in the future.

> can apache projects link to
> eclipse licenced projects?

As far as I know, yes.

Greetings, Marcel

Re: Donation of Sigil project to Felix

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

Hi Marcel,

Couple of comments inline but in general I get the impression there is
interest in taking this further? I'll assume yes and start work to
make a partially cleaned up branch available as an issue. I say
partially as I can easilly remove the runtime integration as it is a
stand alone module and it is the only part that depends explicitly on
newton. If sigil gets accepted we can think about how best to replace
this for general osgi runtimes. I may remove the SCA bit now - but
won't go overboard as this is a bit more entangled vs being it's own
module (we can tidy this up in the medium term should it be an issue).

Regards,

Dave

On Thu, May 7, 2009 at 8:52 PM, Marcel Offermans
<ma...@luminis.nl> wrote:
> Hello Dave,
>
> On May 6, 2009, at 16:34 , David Savage wrote:
>
>>>> * Multiple bundle projects: currently the ivy build can build projects
>>>> which create more than one bundle, however the representation of this
>>>> is difficult in the UI. Is this a good/bad/ugly idea? Other options?
>>>> (I have some ideas but to verbose to list here)
>>>
>>> I would say "yes". We use this model internally for many OSGi projects we
>>> do
>>> and it allows us to easily redefine the packaging of projects. The
>>> "downside" mainly being that you have to have one consistent class space
>>> (but in most applications that is what you want anyway). I definitely
>>> would
>>> not mind discussing this some more. Btw, the Apache Ace project will be
>>> an
>>> example of this build structure, that should be visible to all soon.
>>
>> So the answer is kind of grey at the moment - in the server side build
>> we do support multiple bundles per project, but currently the IDE
>> ignores this. The reason for this is purely related to user interation
>> with the UI vs any strong anthropic principles ;) in that the
>> representation of a multi bundle project is difficult in the UI.
>
>> The model I've been thinking of to do this is having one PDE (like)
>> page per bundle. This could be represented as tabs or completely
>> different pages. The downside of tabs is that the user disappears
>> under a see of tabs if not done well) The downside of different pages
>> is that in a trivial case this means having multiple files in the
>> workspace - which could be viewed as overkill...
>
> In our Ant based build we currently have a single file that defines all
> bundles. Based on that, we could probably come up with some kind of UI for
> easily creating bundles, mapping packages onto bundles. I'm no interaction
> designer, but it might make sense to get one involved for something like
> this.

Yep this was part of our thinking the sigil.properties file is the
place where you define the bundle(s) and it is up to what ever build
system (ant/ivy/maven/eclipse/netbeans/etc) how it represents this in
it's space. In opening this up to a larger open-source community,
we're much more likely to pick up good ideas and skill sets if we all
bang our heads together...

>
>> In the long term if we can make this work well in the UI and on the
>> filesystem I'm definately in favour of it...
>
> Agreed, this is something that needs some more thought first.
>
>>>> - Version Policies - Rules for working with version ranges in
>>>> workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc
>>>
>>> Would this include defining a policy and validating if changes in bundles
>>> are consistent with this policy (making sure a bugfix is only a bugfix
>>> and
>>> does not introduce any change in exported / API packages)?
>>
>> Um nope, though I understand PDE does this - it's more for the
>> importer to decide how they want to manage the import ranges in their
>> workspace. Basically you can define a workspace policy for how imports
>> are generated based on user input - instead of having to always state
>> you want to do [1.0.0,*) or [1.0.0,2.0.0) or [1.0.0,1.1.0) you can
>> specify a general rule that when you specify x.y.z as the root version
>> you depend on how the following range is generated...
>
> Ok, that's a very nice start.
>
>> So if I say (using quick fix) import 1.0.1, my workspace rule could be
>> configured to automatically translate this into [1.0.1,1.1.0). This
>> makes it easier to define policies for working with imports...again
>> this rabit whole is kind of deep but it's an attempt to make working
>> with OSGi import ranges easier for the user.
>
> I've been talking with a couple of people who are doing more research into
> the automated versioning of OSGi bundles, doing all kinds of bytecode
> analysis to determine the scope of changes. Again, for the longer term it
> would be nice if tools like these could be integrated (if only to validate
> if the version numbers you stuck on your packages and bundles are correct,
> based on the policy you use).

As I say I know the PDE guys have done something already in this area
- perhaps if we can convince them to make it into a stand alone
library would save some reinvention...can apache projects link to
eclipse licenced projects?

>
> Greetings, Marcel
>
>



-- 
-------------------------------------------------------------------------------------

Paremus Limited. Registered in England. Registration No. 4181472

Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA

Postal Address: 107-111 Fleet Street, London, EC4A 2AB

The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.

If you received this in error, please contact the sender and delete
the material from any computer.

-------------------------------------------------------------------------------------

Re: Donation of Sigil project to Felix

[Marcel Offermans <ma...@luminis.nl>]

Hello Dave,

On May 6, 2009, at 16:34 , David Savage wrote:

>>> * Multiple bundle projects: currently the ivy build can build  
>>> projects
>>> which create more than one bundle, however the representation of  
>>> this
>>> is difficult in the UI. Is this a good/bad/ugly idea? Other options?
>>> (I have some ideas but to verbose to list here)
>>
>> I would say "yes". We use this model internally for many OSGi  
>> projects we do
>> and it allows us to easily redefine the packaging of projects. The
>> "downside" mainly being that you have to have one consistent class  
>> space
>> (but in most applications that is what you want anyway). I  
>> definitely would
>> not mind discussing this some more. Btw, the Apache Ace project  
>> will be an
>> example of this build structure, that should be visible to all soon.
>
> So the answer is kind of grey at the moment - in the server side build
> we do support multiple bundles per project, but currently the IDE
> ignores this. The reason for this is purely related to user interation
> with the UI vs any strong anthropic principles ;) in that the
> representation of a multi bundle project is difficult in the UI.

> The model I've been thinking of to do this is having one PDE (like)
> page per bundle. This could be represented as tabs or completely
> different pages. The downside of tabs is that the user disappears
> under a see of tabs if not done well) The downside of different pages
> is that in a trivial case this means having multiple files in the
> workspace - which could be viewed as overkill...

In our Ant based build we currently have a single file that defines  
all bundles. Based on that, we could probably come up with some kind  
of UI for easily creating bundles, mapping packages onto bundles. I'm  
no interaction designer, but it might make sense to get one involved  
for something like this.

> In the long term if we can make this work well in the UI and on the
> filesystem I'm definately in favour of it...

Agreed, this is something that needs some more thought first.

>>> - Version Policies - Rules for working with version ranges in
>>> workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc
>>
>> Would this include defining a policy and validating if changes in  
>> bundles
>> are consistent with this policy (making sure a bugfix is only a  
>> bugfix and
>> does not introduce any change in exported / API packages)?
>
> Um nope, though I understand PDE does this - it's more for the
> importer to decide how they want to manage the import ranges in their
> workspace. Basically you can define a workspace policy for how imports
> are generated based on user input - instead of having to always state
> you want to do [1.0.0,*) or [1.0.0,2.0.0) or [1.0.0,1.1.0) you can
> specify a general rule that when you specify x.y.z as the root version
> you depend on how the following range is generated...

Ok, that's a very nice start.

> So if I say (using quick fix) import 1.0.1, my workspace rule could be
> configured to automatically translate this into [1.0.1,1.1.0). This
> makes it easier to define policies for working with imports...again
> this rabit whole is kind of deep but it's an attempt to make working
> with OSGi import ranges easier for the user.

I've been talking with a couple of people who are doing more research  
into the automated versioning of OSGi bundles, doing all kinds of  
bytecode analysis to determine the scope of changes. Again, for the  
longer term it would be nice if tools like these could be integrated  
(if only to validate if the version numbers you stuck on your packages  
and bundles are correct, based on the policy you use).

Greetings, Marcel

Re: Donation of Sigil project to Felix

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

Hi Marcel,

Some comments inline...

Regards,

Dave

On Wed, May 6, 2009 at 11:31 AM, Marcel Offermans
<ma...@luminis.nl> wrote:
> Hello David,
>
> First, thanks for offering this codebase to Felix! More tooling is
> definitely a good thing for OSGi.
>
> On May 5, 2009, at 10:17 , David Savage wrote:
>
>> Whilst Sigil integrates with eclipse the intention is not to be a
>> replacement for PDE, though at the moment it has some comparable
>> features, in the long term I'd like to see both projects sharing
>> common code base if at all possible. It is not the intention to be an
>> uber framework either - ideally just specify a number of core API's
>> for extension and let other projects, PDE, Maven, Ivy, etc do there
>> own thing in their own space.
>
> One model I am interested in is support for having a whole "class space" in
> a single Eclipse project, instead of having to have one project per bundle.
> Would these tools allow such a setup? Judging from a comment further down in
> your mail:
>
>> * Multiple bundle projects: currently the ivy build can build projects
>> which create more than one bundle, however the representation of this
>> is difficult in the UI. Is this a good/bad/ugly idea? Other options?
>> (I have some ideas but to verbose to list here)
>
> I would say "yes". We use this model internally for many OSGi projects we do
> and it allows us to easily redefine the packaging of projects. The
> "downside" mainly being that you have to have one consistent class space
> (but in most applications that is what you want anyway). I definitely would
> not mind discussing this some more. Btw, the Apache Ace project will be an
> example of this build structure, that should be visible to all soon.

So the answer is kind of grey at the moment - in the server side build
we do support multiple bundles per project, but currently the IDE
ignores this. The reason for this is purely related to user interation
with the UI vs any strong anthropic principles ;) in that the
representation of a multi bundle project is difficult in the UI.

The model I've been thinking of to do this is having one PDE (like)
page per bundle. This could be represented as tabs or completely
different pages. The downside of tabs is that the user disappears
under a see of tabs if not done well) The downside of different pages
is that in a trivial case this means having multiple files in the
workspace - which could be viewed as overkill...

In the long term if we can make this work well in the UI and on the
filesystem I'm definately in favour of it...

>
>> * Repository Abstraction - API to allow plugin of different repository
>> providers adapts filesystem and obr at present
>
> Does this include an API to "upload" new bundles to a repository?

Not at the moment but it's something I've debated and could definitely
be a medium term goal...

>
>> - Dependency visualisation - graphical view of bundle dependencies
>
> Others have commented on this, having a view of all kinds of dependencies
> would be nice. Package and service dependencies, but also things like
> visualisation of events, wires (as in WireAdmin), ...

Sure - I think we are just at the entrance to this rabit hole...

>
>> - Version Policies - Rules for working with version ranges in
>> workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc
>
> Would this include defining a policy and validating if changes in bundles
> are consistent with this policy (making sure a bugfix is only a bugfix and
> does not introduce any change in exported / API packages)?

Um nope, though I understand PDE does this - it's more for the
importer to decide how they want to manage the import ranges in their
workspace. Basically you can define a workspace policy for how imports
are generated based on user input - instead of having to always state
you want to do [1.0.0,*) or [1.0.0,2.0.0) or [1.0.0,1.1.0) you can
specify a general rule that when you specify x.y.z as the root version
you depend on how the following range is generated...

So if I say (using quick fix) import 1.0.1, my workspace rule could be
configured to automatically translate this into [1.0.1,1.1.0). This
makes it easier to define policies for working with imports...again
this rabit whole is kind of deep but it's an attempt to make working
with OSGi import ranges easier for the user.

>
>> What are the next steps if there is any interest from the Felix community?
>
> In short, add code to Jira issue, submit Software Grant.
>
>> * For code that is not of interest how can this be managed - should we
>> donate all code and then prune later - or do we need to prune early?
>
> Since donating code has some administrative / legal overhead, I would advise
> you to donate everything in one go. Other then that, I have no real
> preference for pruning before or after, except maybe the community might be
> of help with the process (even though you are probably most familiar with
> the codebase).
>
>> * Commiter status - in order that any donation does not stagnate it
>> would be useful to have at least one committer to apache from paremus.
>> Either/both myself or Derek Baum would be happy to undertake this
>> role...
>
> I'm sure we will gladly accept anybody who demonstrates that they maintain
> the code as a committer (we've done so with various other contributions in
> the past).
>
> Greetings, Marcel
>
>



-- 
-------------------------------------------------------------------------------------

Paremus Limited. Registered in England. Registration No. 4181472

Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA

Postal Address: 107-111 Fleet Street, London, EC4A 2AB

The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.

If you received this in error, please contact the sender and delete
the material from any computer.

-------------------------------------------------------------------------------------

Re: Donation of Sigil project to Felix

[Marcel Offermans <ma...@luminis.nl>]

Hello David,

First, thanks for offering this codebase to Felix! More tooling is  
definitely a good thing for OSGi.

On May 5, 2009, at 10:17 , David Savage wrote:

> Whilst Sigil integrates with eclipse the intention is not to be a
> replacement for PDE, though at the moment it has some comparable
> features, in the long term I'd like to see both projects sharing
> common code base if at all possible. It is not the intention to be an
> uber framework either - ideally just specify a number of core API's
> for extension and let other projects, PDE, Maven, Ivy, etc do there
> own thing in their own space.

One model I am interested in is support for having a whole "class  
space" in a single Eclipse project, instead of having to have one  
project per bundle. Would these tools allow such a setup? Judging from  
a comment further down in your mail:

> * Multiple bundle projects: currently the ivy build can build projects
> which create more than one bundle, however the representation of this
> is difficult in the UI. Is this a good/bad/ugly idea? Other options?
> (I have some ideas but to verbose to list here)

I would say "yes". We use this model internally for many OSGi projects  
we do and it allows us to easily redefine the packaging of projects.  
The "downside" mainly being that you have to have one consistent class  
space (but in most applications that is what you want anyway). I  
definitely would not mind discussing this some more. Btw, the Apache  
Ace project will be an example of this build structure, that should be  
visible to all soon.

> * Repository Abstraction - API to allow plugin of different repository
> providers adapts filesystem and obr at present

Does this include an API to "upload" new bundles to a repository?

> - Dependency visualisation - graphical view of bundle dependencies

Others have commented on this, having a view of all kinds of  
dependencies would be nice. Package and service dependencies, but also  
things like visualisation of events, wires (as in WireAdmin), ...

> - Version Policies - Rules for working with version ranges in
> workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc

Would this include defining a policy and validating if changes in  
bundles are consistent with this policy (making sure a bugfix is only  
a bugfix and does not introduce any change in exported / API packages)?

> What are the next steps if there is any interest from the Felix  
> community?

In short, add code to Jira issue, submit Software Grant.

> * For code that is not of interest how can this be managed - should we
> donate all code and then prune later - or do we need to prune early?

Since donating code has some administrative / legal overhead, I would  
advise you to donate everything in one go. Other then that, I have no  
real preference for pruning before or after, except maybe the  
community might be of help with the process (even though you are  
probably most familiar with the codebase).

> * Commiter status - in order that any donation does not stagnate it
> would be useful to have at least one committer to apache from paremus.
> Either/both myself or Derek Baum would be happy to undertake this
> role...

I'm sure we will gladly accept anybody who demonstrates that they  
maintain the code as a committer (we've done so with various other  
contributions in the past).

Greetings, Marcel

Re: Donation of Sigil project to Felix

[Karl Pauls <ka...@gmail.com>]

+1

I agree that Sigil sounds very interesting and I think it would be a
cool project to have at felix. Whatever makes developing bundles
easier I'm all in favour off.

regards,

Karl

On Tue, May 5, 2009 at 8:04 PM, Stuart McCulloch <mc...@gmail.com> wrote:
> 2009/5/6 David Savage <da...@paremus.com>
>
>> Yep that would certainly be interesting, an obvious extension is for
>> things like iPojo, Blueprint and DS as these runtime entities also
>> have dependencies (i.e. component A depends on component B etc)
>>
>> Be nice if you could switch between a module view and a service view
>> for the same set of bundles (for example).
>>
>> Whether all this needs to be in felix or just the hooks is debatable
>> but if there is a nice clean common api that is a good starting
>> point...
>>
>
> Hi Dave,
>
> Thanks for offering this donation, I'll need some time to digest it all but
> so far it looks very interesting.
>
> Also +1 for the idea of some sort of resolver API ... would make it much
> easier to research and compare resolution algorithms :)
>
> --
> Cheers, Stuart
>
> Regards,
>>
>> Dave
>>
>> On Tue, May 5, 2009 at 2:29 PM, Richard S. Hall <he...@ungoverned.org>
>> wrote:
>> > This sounds interesting.
>> >
>> > I particularly like your dependency visualizer and would like to see it
>> > extended to visualize more types of dependencies.
>> >
>> > I think we are seeing more interest in tooling lately and I think the
>> > efforts around tooling at Felix may be grow in the future, so this would
>> fit
>> > into that movement.
>> >
>> > -> richard
>> >
>> > On 5/5/09 4:17 AM, David Savage wrote:
>> >>
>> >> Hi Felix Dev,
>> >>
>> >> I recently attended the OSGi Dev Con and chatted to some of you there
>> >> about OSGi development tooling. From these conversations there seemed
>> >> to be some interest in a donation of code from the Sigil project as a
>> >> sub project of Felix. I understand the process to achieve this is via
>> >> an initial email discussion here on the list, which then moves to a
>> >> vote if there is enough interest...So here goes...
>> >>
>> >> I guess firstly it's worth explaining what Sigil is and what it isn't
>> >> and why we're donating it.
>> >>
>> >> Sigil is an OSGi development tooling framework for IDE (eclipse) and
>> >> headless build (ant/ivy). Our website with more info can be found
>> >> here: http://sigil.codecauldron.org. We have had a number of
>> >> contributions outside of Paremus in the form of issues, bug fixes and
>> >> documentation.
>> >>
>> >> Whilst Sigil integrates with eclipse the intention is not to be a
>> >> replacement for PDE, though at the moment it has some comparable
>> >> features, in the long term I'd like to see both projects sharing
>> >> common code base if at all possible. It is not the intention to be an
>> >> uber framework either - ideally just specify a number of core API's
>> >> for extension and let other projects, PDE, Maven, Ivy, etc do there
>> >> own thing in their own space.
>> >>
>> >> The purpose of the donation is to open up the development to a wider
>> >> community to make OSGi development tooling better for all users.
>> >>
>> >> To better understand what it is we are considering donating, here are
>> >> a list of the main functional features contained in Sigil which are
>> >> relevant to generic OSGi development.
>> >>
>> >> * Common properties file - sigil.properties is a human
>> >> readable/editable (no xml) file that defines properties such as bsn,
>> >> version, package imports, fragments, contents etc.
>> >>
>> >> * Project inheritance - sigil projects can inherit properties from
>> >> parent projects (e.g. usecase - leaf nodes don't have to specify
>> >> version ranges over and over - define in parent instead)
>> >>
>> >> * Repository Abstraction - API to allow plugin of different repository
>> >> providers adapts filesystem and obr at present
>> >>
>> >> * Resolver - uses OSGi semantics (i.e. import package, require-bundle,
>> >> fragment-host, etc) to find bundles from repository for addition to
>> >> classpath, indexing etc
>> >>
>> >> * Built on BND - In the end the sigil builder takes the rules defined
>> >> in sigil and generates BND instructions - ensures spec compliance
>> >>
>> >> * Eclipse Integration
>> >>  - Code completion - uses resolver and repositories to propose java
>> >> code completion options
>> >>  - Search - trivial search integration - lots of improvement could be
>> >> done here...
>> >>  - Dependency visualisation - graphical view of bundle dependencies
>> >>  - Repository browser - graphical view of repository contents
>> >>  - Project Model - PDE like front page
>> >>  - Version Policies - Rules for working with version ranges in
>> >> workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc
>> >>
>> >> * Ivy Integration
>> >>  - Ivy resolver plugin that understands sigil.properties and uses
>> >> resolver to provide artifacts.
>> >>
>> >> * JUnit test integration - trivial test runner (uses bundle
>> >> introspection to find "test bundles") expose tests via command line -
>> >> reliant on newton CLI (but easy to port to other CLI)
>> >>
>> >> Outside of these features there are a number of other features which
>> >> are specific to our product and are probably less of interest to felix
>> >>
>> >> * SCA integration - likely replaced by eclipse STP integration in
>> >> medium term and hence no longer part of Sigil
>> >> * IDE runtime integration - currently only works with the newton runtime
>> >>
>> >> There are a couple of outstanding issues which need attention in the
>> >> short term and it would be interesting to here opinions from other
>> >> OSGi users on other improvements.
>> >>
>> >> * Multiple bundle projects: currently the ivy build can build projects
>> >> which create more than one bundle, however the representation of this
>> >> is difficult in the UI. Is this a good/bad/ugly idea? Other options?
>> >> (I have some ideas but to verbose to list here)
>> >> * IDE and Ivy do not share repository config (they use same repository
>> >> classes but config needs to be done twice)
>> >>
>> >> In the medium to long term I'm interested in...
>> >>
>> >> * Repository integration - Maven, SVN, etc...
>> >> * Extension to other IDE's (netbeans, intellij, etc)
>> >> * Integration with other resolvers (ideally resolvers becomes an API),
>> >> P2, Felix OBR, Nimble from Paremus
>> >> * Code completion in iPOJO, Spring, DS etc...don't need to reinvent
>> >> wheel, just tie in with existing tools
>> >>
>> >> What are the next steps if there is any interest from the Felix
>> community?
>> >>
>> >> * For code that is not of interest how can this be managed - should we
>> >> donate all code and then prune later - or do we need to prune early?
>> >> * Commiter status - in order that any donation does not stagnate it
>> >> would be useful to have at least one committer to apache from paremus.
>> >> Either/both myself or Derek Baum would be happy to undertake this
>> >> role...
>> >> * IP clearance - all code was developed by Paremus, but understand
>> >> donation needs proper procedures - need to understand process etc.
>> >>
>> >> Hope that's of interest...
>> >>
>> >> Regards,
>> >>
>> >> Dave
>> >>
>> >>
>> >
>>
>>
>>
>> --
>>
>> -------------------------------------------------------------------------------------
>>
>> Paremus Limited. Registered in England. Registration No. 4181472
>>
>> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
>>
>> Postal Address: 107-111 Fleet Street, London, EC4A 2AB
>>
>> The information transmitted is intended only for the person(s) or
>> entity to which it is addressed and may contain confidential and/or
>> privileged material. Any review, retransmission, dissemination or
>> other use of, or taking of any action in reliance upon, this
>> information by persons or entities other than the intended recipient
>> is prohibited.
>>
>> If you received this in error, please contact the sender and delete
>> the material from any computer.
>>
>>
>> -------------------------------------------------------------------------------------
>>
>



-- 
Karl Pauls
karlpauls@gmail.com

Re: Donation of Sigil project to Felix

[Stuart McCulloch <mc...@gmail.com>]

2009/5/6 David Savage <da...@paremus.com>

> Yep that would certainly be interesting, an obvious extension is for
> things like iPojo, Blueprint and DS as these runtime entities also
> have dependencies (i.e. component A depends on component B etc)
>
> Be nice if you could switch between a module view and a service view
> for the same set of bundles (for example).
>
> Whether all this needs to be in felix or just the hooks is debatable
> but if there is a nice clean common api that is a good starting
> point...
>

Hi Dave,

Thanks for offering this donation, I'll need some time to digest it all but
so far it looks very interesting.

Also +1 for the idea of some sort of resolver API ... would make it much
easier to research and compare resolution algorithms :)

-- 
Cheers, Stuart

Regards,
>
> Dave
>
> On Tue, May 5, 2009 at 2:29 PM, Richard S. Hall <he...@ungoverned.org>
> wrote:
> > This sounds interesting.
> >
> > I particularly like your dependency visualizer and would like to see it
> > extended to visualize more types of dependencies.
> >
> > I think we are seeing more interest in tooling lately and I think the
> > efforts around tooling at Felix may be grow in the future, so this would
> fit
> > into that movement.
> >
> > -> richard
> >
> > On 5/5/09 4:17 AM, David Savage wrote:
> >>
> >> Hi Felix Dev,
> >>
> >> I recently attended the OSGi Dev Con and chatted to some of you there
> >> about OSGi development tooling. From these conversations there seemed
> >> to be some interest in a donation of code from the Sigil project as a
> >> sub project of Felix. I understand the process to achieve this is via
> >> an initial email discussion here on the list, which then moves to a
> >> vote if there is enough interest...So here goes...
> >>
> >> I guess firstly it's worth explaining what Sigil is and what it isn't
> >> and why we're donating it.
> >>
> >> Sigil is an OSGi development tooling framework for IDE (eclipse) and
> >> headless build (ant/ivy). Our website with more info can be found
> >> here: http://sigil.codecauldron.org. We have had a number of
> >> contributions outside of Paremus in the form of issues, bug fixes and
> >> documentation.
> >>
> >> Whilst Sigil integrates with eclipse the intention is not to be a
> >> replacement for PDE, though at the moment it has some comparable
> >> features, in the long term I'd like to see both projects sharing
> >> common code base if at all possible. It is not the intention to be an
> >> uber framework either - ideally just specify a number of core API's
> >> for extension and let other projects, PDE, Maven, Ivy, etc do there
> >> own thing in their own space.
> >>
> >> The purpose of the donation is to open up the development to a wider
> >> community to make OSGi development tooling better for all users.
> >>
> >> To better understand what it is we are considering donating, here are
> >> a list of the main functional features contained in Sigil which are
> >> relevant to generic OSGi development.
> >>
> >> * Common properties file - sigil.properties is a human
> >> readable/editable (no xml) file that defines properties such as bsn,
> >> version, package imports, fragments, contents etc.
> >>
> >> * Project inheritance - sigil projects can inherit properties from
> >> parent projects (e.g. usecase - leaf nodes don't have to specify
> >> version ranges over and over - define in parent instead)
> >>
> >> * Repository Abstraction - API to allow plugin of different repository
> >> providers adapts filesystem and obr at present
> >>
> >> * Resolver - uses OSGi semantics (i.e. import package, require-bundle,
> >> fragment-host, etc) to find bundles from repository for addition to
> >> classpath, indexing etc
> >>
> >> * Built on BND - In the end the sigil builder takes the rules defined
> >> in sigil and generates BND instructions - ensures spec compliance
> >>
> >> * Eclipse Integration
> >>  - Code completion - uses resolver and repositories to propose java
> >> code completion options
> >>  - Search - trivial search integration - lots of improvement could be
> >> done here...
> >>  - Dependency visualisation - graphical view of bundle dependencies
> >>  - Repository browser - graphical view of repository contents
> >>  - Project Model - PDE like front page
> >>  - Version Policies - Rules for working with version ranges in
> >> workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc
> >>
> >> * Ivy Integration
> >>  - Ivy resolver plugin that understands sigil.properties and uses
> >> resolver to provide artifacts.
> >>
> >> * JUnit test integration - trivial test runner (uses bundle
> >> introspection to find "test bundles") expose tests via command line -
> >> reliant on newton CLI (but easy to port to other CLI)
> >>
> >> Outside of these features there are a number of other features which
> >> are specific to our product and are probably less of interest to felix
> >>
> >> * SCA integration - likely replaced by eclipse STP integration in
> >> medium term and hence no longer part of Sigil
> >> * IDE runtime integration - currently only works with the newton runtime
> >>
> >> There are a couple of outstanding issues which need attention in the
> >> short term and it would be interesting to here opinions from other
> >> OSGi users on other improvements.
> >>
> >> * Multiple bundle projects: currently the ivy build can build projects
> >> which create more than one bundle, however the representation of this
> >> is difficult in the UI. Is this a good/bad/ugly idea? Other options?
> >> (I have some ideas but to verbose to list here)
> >> * IDE and Ivy do not share repository config (they use same repository
> >> classes but config needs to be done twice)
> >>
> >> In the medium to long term I'm interested in...
> >>
> >> * Repository integration - Maven, SVN, etc...
> >> * Extension to other IDE's (netbeans, intellij, etc)
> >> * Integration with other resolvers (ideally resolvers becomes an API),
> >> P2, Felix OBR, Nimble from Paremus
> >> * Code completion in iPOJO, Spring, DS etc...don't need to reinvent
> >> wheel, just tie in with existing tools
> >>
> >> What are the next steps if there is any interest from the Felix
> community?
> >>
> >> * For code that is not of interest how can this be managed - should we
> >> donate all code and then prune later - or do we need to prune early?
> >> * Commiter status - in order that any donation does not stagnate it
> >> would be useful to have at least one committer to apache from paremus.
> >> Either/both myself or Derek Baum would be happy to undertake this
> >> role...
> >> * IP clearance - all code was developed by Paremus, but understand
> >> donation needs proper procedures - need to understand process etc.
> >>
> >> Hope that's of interest...
> >>
> >> Regards,
> >>
> >> Dave
> >>
> >>
> >
>
>
>
> --
>
> -------------------------------------------------------------------------------------
>
> Paremus Limited. Registered in England. Registration No. 4181472
>
> Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA
>
> Postal Address: 107-111 Fleet Street, London, EC4A 2AB
>
> The information transmitted is intended only for the person(s) or
> entity to which it is addressed and may contain confidential and/or
> privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon, this
> information by persons or entities other than the intended recipient
> is prohibited.
>
> If you received this in error, please contact the sender and delete
> the material from any computer.
>
>
> -------------------------------------------------------------------------------------
>

Re: Donation of Sigil project to Felix

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

Yep that would certainly be interesting, an obvious extension is for
things like iPojo, Blueprint and DS as these runtime entities also
have dependencies (i.e. component A depends on component B etc)

Be nice if you could switch between a module view and a service view
for the same set of bundles (for example).

Whether all this needs to be in felix or just the hooks is debatable
but if there is a nice clean common api that is a good starting
point...

Regards,

Dave

On Tue, May 5, 2009 at 2:29 PM, Richard S. Hall <he...@ungoverned.org> wrote:
> This sounds interesting.
>
> I particularly like your dependency visualizer and would like to see it
> extended to visualize more types of dependencies.
>
> I think we are seeing more interest in tooling lately and I think the
> efforts around tooling at Felix may be grow in the future, so this would fit
> into that movement.
>
> -> richard
>
> On 5/5/09 4:17 AM, David Savage wrote:
>>
>> Hi Felix Dev,
>>
>> I recently attended the OSGi Dev Con and chatted to some of you there
>> about OSGi development tooling. From these conversations there seemed
>> to be some interest in a donation of code from the Sigil project as a
>> sub project of Felix. I understand the process to achieve this is via
>> an initial email discussion here on the list, which then moves to a
>> vote if there is enough interest...So here goes...
>>
>> I guess firstly it's worth explaining what Sigil is and what it isn't
>> and why we're donating it.
>>
>> Sigil is an OSGi development tooling framework for IDE (eclipse) and
>> headless build (ant/ivy). Our website with more info can be found
>> here: http://sigil.codecauldron.org. We have had a number of
>> contributions outside of Paremus in the form of issues, bug fixes and
>> documentation.
>>
>> Whilst Sigil integrates with eclipse the intention is not to be a
>> replacement for PDE, though at the moment it has some comparable
>> features, in the long term I'd like to see both projects sharing
>> common code base if at all possible. It is not the intention to be an
>> uber framework either - ideally just specify a number of core API's
>> for extension and let other projects, PDE, Maven, Ivy, etc do there
>> own thing in their own space.
>>
>> The purpose of the donation is to open up the development to a wider
>> community to make OSGi development tooling better for all users.
>>
>> To better understand what it is we are considering donating, here are
>> a list of the main functional features contained in Sigil which are
>> relevant to generic OSGi development.
>>
>> * Common properties file - sigil.properties is a human
>> readable/editable (no xml) file that defines properties such as bsn,
>> version, package imports, fragments, contents etc.
>>
>> * Project inheritance - sigil projects can inherit properties from
>> parent projects (e.g. usecase - leaf nodes don't have to specify
>> version ranges over and over - define in parent instead)
>>
>> * Repository Abstraction - API to allow plugin of different repository
>> providers adapts filesystem and obr at present
>>
>> * Resolver - uses OSGi semantics (i.e. import package, require-bundle,
>> fragment-host, etc) to find bundles from repository for addition to
>> classpath, indexing etc
>>
>> * Built on BND - In the end the sigil builder takes the rules defined
>> in sigil and generates BND instructions - ensures spec compliance
>>
>> * Eclipse Integration
>>  - Code completion - uses resolver and repositories to propose java
>> code completion options
>>  - Search - trivial search integration - lots of improvement could be
>> done here...
>>  - Dependency visualisation - graphical view of bundle dependencies
>>  - Repository browser - graphical view of repository contents
>>  - Project Model - PDE like front page
>>  - Version Policies - Rules for working with version ranges in
>> workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc
>>
>> * Ivy Integration
>>  - Ivy resolver plugin that understands sigil.properties and uses
>> resolver to provide artifacts.
>>
>> * JUnit test integration - trivial test runner (uses bundle
>> introspection to find "test bundles") expose tests via command line -
>> reliant on newton CLI (but easy to port to other CLI)
>>
>> Outside of these features there are a number of other features which
>> are specific to our product and are probably less of interest to felix
>>
>> * SCA integration - likely replaced by eclipse STP integration in
>> medium term and hence no longer part of Sigil
>> * IDE runtime integration - currently only works with the newton runtime
>>
>> There are a couple of outstanding issues which need attention in the
>> short term and it would be interesting to here opinions from other
>> OSGi users on other improvements.
>>
>> * Multiple bundle projects: currently the ivy build can build projects
>> which create more than one bundle, however the representation of this
>> is difficult in the UI. Is this a good/bad/ugly idea? Other options?
>> (I have some ideas but to verbose to list here)
>> * IDE and Ivy do not share repository config (they use same repository
>> classes but config needs to be done twice)
>>
>> In the medium to long term I'm interested in...
>>
>> * Repository integration - Maven, SVN, etc...
>> * Extension to other IDE's (netbeans, intellij, etc)
>> * Integration with other resolvers (ideally resolvers becomes an API),
>> P2, Felix OBR, Nimble from Paremus
>> * Code completion in iPOJO, Spring, DS etc...don't need to reinvent
>> wheel, just tie in with existing tools
>>
>> What are the next steps if there is any interest from the Felix community?
>>
>> * For code that is not of interest how can this be managed - should we
>> donate all code and then prune later - or do we need to prune early?
>> * Commiter status - in order that any donation does not stagnate it
>> would be useful to have at least one committer to apache from paremus.
>> Either/both myself or Derek Baum would be happy to undertake this
>> role...
>> * IP clearance - all code was developed by Paremus, but understand
>> donation needs proper procedures - need to understand process etc.
>>
>> Hope that's of interest...
>>
>> Regards,
>>
>> Dave
>>
>>
>



-- 
-------------------------------------------------------------------------------------

Paremus Limited. Registered in England. Registration No. 4181472

Registered Office: 22-24 Broad Street, Wokingham, Berks RG40 1BA

Postal Address: 107-111 Fleet Street, London, EC4A 2AB

The information transmitted is intended only for the person(s) or
entity to which it is addressed and may contain confidential and/or
privileged material. Any review, retransmission, dissemination or
other use of, or taking of any action in reliance upon, this
information by persons or entities other than the intended recipient
is prohibited.

If you received this in error, please contact the sender and delete
the material from any computer.

-------------------------------------------------------------------------------------

Re: Donation of Sigil project to Felix

["Richard S. Hall" <he...@ungoverned.org>]

This sounds interesting.

I particularly like your dependency visualizer and would like to see it 
extended to visualize more types of dependencies.

I think we are seeing more interest in tooling lately and I think the 
efforts around tooling at Felix may be grow in the future, so this would 
fit into that movement.

-> richard

On 5/5/09 4:17 AM, David Savage wrote:
> Hi Felix Dev,
>
> I recently attended the OSGi Dev Con and chatted to some of you there
> about OSGi development tooling. From these conversations there seemed
> to be some interest in a donation of code from the Sigil project as a
> sub project of Felix. I understand the process to achieve this is via
> an initial email discussion here on the list, which then moves to a
> vote if there is enough interest...So here goes...
>
> I guess firstly it's worth explaining what Sigil is and what it isn't
> and why we're donating it.
>
> Sigil is an OSGi development tooling framework for IDE (eclipse) and
> headless build (ant/ivy). Our website with more info can be found
> here: http://sigil.codecauldron.org. We have had a number of
> contributions outside of Paremus in the form of issues, bug fixes and
> documentation.
>
> Whilst Sigil integrates with eclipse the intention is not to be a
> replacement for PDE, though at the moment it has some comparable
> features, in the long term I'd like to see both projects sharing
> common code base if at all possible. It is not the intention to be an
> uber framework either - ideally just specify a number of core API's
> for extension and let other projects, PDE, Maven, Ivy, etc do there
> own thing in their own space.
>
> The purpose of the donation is to open up the development to a wider
> community to make OSGi development tooling better for all users.
>
> To better understand what it is we are considering donating, here are
> a list of the main functional features contained in Sigil which are
> relevant to generic OSGi development.
>
> * Common properties file - sigil.properties is a human
> readable/editable (no xml) file that defines properties such as bsn,
> version, package imports, fragments, contents etc.
>
> * Project inheritance - sigil projects can inherit properties from
> parent projects (e.g. usecase - leaf nodes don't have to specify
> version ranges over and over - define in parent instead)
>
> * Repository Abstraction - API to allow plugin of different repository
> providers adapts filesystem and obr at present
>
> * Resolver - uses OSGi semantics (i.e. import package, require-bundle,
> fragment-host, etc) to find bundles from repository for addition to
> classpath, indexing etc
>
> * Built on BND - In the end the sigil builder takes the rules defined
> in sigil and generates BND instructions - ensures spec compliance
>
> * Eclipse Integration
>   - Code completion - uses resolver and repositories to propose java
> code completion options
>   - Search - trivial search integration - lots of improvement could be
> done here...
>   - Dependency visualisation - graphical view of bundle dependencies
>   - Repository browser - graphical view of repository contents
>   - Project Model - PDE like front page
>   - Version Policies - Rules for working with version ranges in
> workspace - [1.0.0,*), [1.0.0, 1.1), [1.0.0,1.0.0] etc
>
> * Ivy Integration
>   - Ivy resolver plugin that understands sigil.properties and uses
> resolver to provide artifacts.
>
> * JUnit test integration - trivial test runner (uses bundle
> introspection to find "test bundles") expose tests via command line -
> reliant on newton CLI (but easy to port to other CLI)
>
> Outside of these features there are a number of other features which
> are specific to our product and are probably less of interest to felix
>
> * SCA integration - likely replaced by eclipse STP integration in
> medium term and hence no longer part of Sigil
> * IDE runtime integration - currently only works with the newton runtime
>
> There are a couple of outstanding issues which need attention in the
> short term and it would be interesting to here opinions from other
> OSGi users on other improvements.
>
> * Multiple bundle projects: currently the ivy build can build projects
> which create more than one bundle, however the representation of this
> is difficult in the UI. Is this a good/bad/ugly idea? Other options?
> (I have some ideas but to verbose to list here)
> * IDE and Ivy do not share repository config (they use same repository
> classes but config needs to be done twice)
>
> In the medium to long term I'm interested in...
>
> * Repository integration - Maven, SVN, etc...
> * Extension to other IDE's (netbeans, intellij, etc)
> * Integration with other resolvers (ideally resolvers becomes an API),
> P2, Felix OBR, Nimble from Paremus
> * Code completion in iPOJO, Spring, DS etc...don't need to reinvent
> wheel, just tie in with existing tools
>
> What are the next steps if there is any interest from the Felix community?
>
> * For code that is not of interest how can this be managed - should we
> donate all code and then prune later - or do we need to prune early?
> * Commiter status - in order that any donation does not stagnate it
> would be useful to have at least one committer to apache from paremus.
> Either/both myself or Derek Baum would be happy to undertake this
> role...
> * IP clearance - all code was developed by Paremus, but understand
> donation needs proper procedures - need to understand process etc.
>
> Hope that's of interest...
>
> Regards,
>
> Dave
>
>