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
