+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 <[email protected]> wrote: > 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. >> >> >> ------------------------------------------------------------------------------------- >> > -- Karl Pauls [email protected]
