2009/5/6 David Savage <[email protected]> > 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 <[email protected]> > 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. > > > ------------------------------------------------------------------------------------- >
