felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Savage <dave.sav...@paremus.com>
Subject Re: Donation of Sigil project to Felix
Date Wed, 06 May 2009 14:34:50 GMT
Hi Marcel,

Some comments inline...

Regards,

Dave

On Wed, May 6, 2009 at 11:31 AM, Marcel Offermans
<marcel.offermans@luminis.nl> wrote:
> 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.

So the answer is kind of grey at the moment - in the server side build
we do support multiple bundles per project, but currently the IDE
ignores this. The reason for this is purely related to user interation
with the UI vs any strong anthropic principles ;) in that the
representation of a multi bundle project is difficult in the UI.

The model I've been thinking of to do this is having one PDE (like)
page per bundle. This could be represented as tabs or completely
different pages. The downside of tabs is that the user disappears
under a see of tabs if not done well) The downside of different pages
is that in a trivial case this means having multiple files in the
workspace - which could be viewed as overkill...

In the long term if we can make this work well in the UI and on the
filesystem I'm definately in favour of it...

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

Not at the moment but it's something I've debated and could definitely
be a medium term goal...

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

Sure - I think we are just at the entrance to this rabit hole...

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

Um nope, though I understand PDE does this - it's more for the
importer to decide how they want to manage the import ranges in their
workspace. Basically you can define a workspace policy for how imports
are generated based on user input - instead of having to always state
you want to do [1.0.0,*) or [1.0.0,2.0.0) or [1.0.0,1.1.0) you can
specify a general rule that when you specify x.y.z as the root version
you depend on how the following range is generated...

So if I say (using quick fix) import 1.0.1, my workspace rule could be
configured to automatically translate this into [1.0.1,1.1.0). This
makes it easier to define policies for working with imports...again
this rabit whole is kind of deep but it's an attempt to make working
with OSGi import ranges easier for the user.

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



-- 
-------------------------------------------------------------------------------------

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.

-------------------------------------------------------------------------------------

Mime
View raw message