felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Donation of Sigil project to Felix
Date Tue, 05 May 2009 13:29:01 GMT
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

View raw message