felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: Donation of Sigil project to Felix
Date Wed, 06 May 2009 09:34:54 GMT
+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 <mcculls@gmail.com> wrote:
> 2009/5/6 David Savage <david.savage@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 <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.
>>
>>
>> -------------------------------------------------------------------------------------
>>
>



-- 
Karl Pauls
karlpauls@gmail.com

Mime
View raw message