felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Donation of Sigil project to Felix
Date Wed, 06 May 2009 10:31:35 GMT
Hello David,

First, thanks for offering this codebase to Felix! More tooling is  
definitely a good thing for OSGi.

On May 5, 2009, at 10:17 , David Savage wrote:

> 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.

One model I am interested in is support for having a whole "class  
space" in a single Eclipse project, instead of having to have one  
project per bundle. Would these tools allow such a setup? Judging from  
a comment further down in your mail:

> * 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)

I would say "yes". We use this model internally for many OSGi projects  
we do and it allows us to easily redefine the packaging of projects.  
The "downside" mainly being that you have to have one consistent class  
space (but in most applications that is what you want anyway). I  
definitely would not mind discussing this some more. Btw, the Apache  
Ace project will be an example of this build structure, that should be  
visible to all soon.

> * Repository Abstraction - API to allow plugin of different repository
> providers adapts filesystem and obr at present

Does this include an API to "upload" new bundles to a repository?

> - Dependency visualisation - graphical view of bundle dependencies

Others have commented on this, having a view of all kinds of  
dependencies would be nice. Package and service dependencies, but also  
things like visualisation of events, wires (as in WireAdmin), ...

> - 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

Would this include defining a policy and validating if changes in  
bundles are consistent with this policy (making sure a bugfix is only  
a bugfix and does not introduce any change in exported / API packages)?

> What are the next steps if there is any interest from the Felix  
> community?

In short, add code to Jira issue, submit Software Grant.

> * 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?

Since donating code has some administrative / legal overhead, I would  
advise you to donate everything in one go. Other then that, I have no  
real preference for pruning before or after, except maybe the  
community might be of help with the process (even though you are  
probably most familiar with the codebase).

> * 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...

I'm sure we will gladly accept anybody who demonstrates that they  
maintain the code as a committer (we've done so with various other  
contributions in the past).

Greetings, Marcel


Mime
View raw message