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 Fri, 08 May 2009 08:33:10 GMT
Hi Marcel,

Couple of comments inline but in general I get the impression there is
interest in taking this further? I'll assume yes and start work to
make a partially cleaned up branch available as an issue. I say
partially as I can easilly remove the runtime integration as it is a
stand alone module and it is the only part that depends explicitly on
newton. If sigil gets accepted we can think about how best to replace
this for general osgi runtimes. I may remove the SCA bit now - but
won't go overboard as this is a bit more entangled vs being it's own
module (we can tidy this up in the medium term should it be an issue).



On Thu, May 7, 2009 at 8:52 PM, Marcel Offermans
<marcel.offermans@luminis.nl> wrote:
> 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.

Yep this was part of our thinking the sigil.properties file is the
place where you define the bundle(s) and it is up to what ever build
system (ant/ivy/maven/eclipse/netbeans/etc) how it represents this in
it's space. In opening this up to a larger open-source community,
we're much more likely to pick up good ideas and skill sets if we all
bang our heads together...

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

As I say I know the PDE guys have done something already in this area
- perhaps if we can convince them to make it into a stand alone
library would save some reinvention...can apache projects link to
eclipse licenced projects?

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


View raw message