felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Savage <david.sav...@paremus.com>
Subject Re: Donation of Sigil project to Felix
Date Tue, 05 May 2009 17:56:45 GMT
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



On Tue, May 5, 2009 at 2:29 PM, Richard S. Hall <heavy@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.


View raw message