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 Thu, 07 May 2009 19:52:09 GMT
Hello Dave,

On May 6, 2009, at 16:34 , David Savage wrote:

>>> * 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 our Ant based build we currently have a single file that defines  
all bundles. Based on that, we could probably come up with some kind  
of UI for easily creating bundles, mapping packages onto bundles. I'm  
no interaction designer, but it might make sense to get one involved  
for something like this.

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

Agreed, this is something that needs some more thought first.

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

Ok, that's a very nice start.

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

I've been talking with a couple of people who are doing more research  
into the automated versioning of OSGi bundles, doing all kinds of  
bytecode analysis to determine the scope of changes. Again, for the  
longer term it would be nice if tools like these could be integrated  
(if only to validate if the version numbers you stuck on your packages  
and bundles are correct, based on the policy you use).

Greetings, Marcel

View raw message