[buckminster-dev] Some improvements/ideas for buckminster

[Johannes Utzig <mail@xxxxxxxxx>]

Hi,

it was really nice seeing you all in person on the summit. Too bad it's 
over already :)

I was wondering what my next contributions for buckminster could be, and 
I was having a few ideas that I'd like to get an opinion about.

-Aggregator
I really love the idea of the hybrid p2/maven repository and thankfully 
Filip explained me the functionality more in detail. Btw, how does this 
work with nested jars in OSGi bundles? Can maven handle this kind of 
packaging or are you repacking it somehow?
Now the next logical step for me (we talked about that during the ESE 
already) would be to enhance the hudson plugin to deploy these artifacts 
(or just some of them) to a local maven repository. Unfortunately I'm 
not using Maven that often, so maybe someone that follows this newsgroup 
uses OSGi bundles and Maven together and has some ideas on how such a 
support should look like.

The other thing that came to my mind was, now that the aggregator can 
transform OSGi bundles to maven artifacts and create all the maven 
metadata, why not go the other way around as well.
Some of my OSGi/Eclipse projects require Maven artifacts. I think it 
would be a cool feature to use the aggregator to mix some p2 
repositories with maven repositories and OSGiify the maven artifacts on 
the way. That way all builds could fetch their dependencies from a 
single p2 repository that was created by the aggregator.
I'm not sure though if this would create licence issues, because the 
manifest of the maven artifacts needs to be altered... If so, maybe it 
should be done like PDE does it, use the original jar as embedded jar in 
the OSGi Bundle and wrap the meta information around it.
However, I think it would be nice to have an easy automated way to turn 
maven repositories into p2 repositories with the aggregator.

-building RCPs
I think many people out there are creating RCP applications and while 
buckminster significantly simplifies the process, they currently still 
need the little ant script for the director and a cspec(x) to integrate 
this as a buckminster action. This has four downsides in my opinion:
1. You need to know how to do this (the MailApp tutorial helps a lot, 
but still...)
2. You need extra files (cspecx + build script)
3. The error reporting is not so great (Java returned 13)
4. It won't work for some paths as long as this issue in the p2 director 
app isn't resolved: https://bugs.eclipse.org/bugs/show_bug.cgi?id=291405

So I would like to add a new create.XY.product action to the 
automatically generated CSPEC when there is a product definition 
existing. I worked on that a little during the breaks in ESE and it 
shouldn't be that hard to implement, but there are three ways to 
implement this and I'm not sure which is the better approach:

1. add an ANT action and include the target to create the product in the 
build.xml shipped with buckminster. This works exactly the way it 
currently works and is easy to implement, but doesn't resolve problem 3. 
and 4. mentioned above.

2. Invoke the director application in the same VM and pass the arguments 
to its run method. This would make it possible to work around issue 
291405, but doesn't sound like a 'clean' solution

3. The Director Application isn't exactly meant for reusing it seems and 
contains a lot of logic and code. The action could be implemented from 
scratch in java code to do the same thing the director application 
currently does, but without the program argument detour. This would 
resolve the issues but also duplicate some already existing code.

So none of these alternatives are really great, what do you think?


-usablility
There are a few minor things regarding overall usabillity that I'd like 
to implement if you're ok with that:

1. Add an 'Open CSpec' dialog similar to JDT's 'Open Type' Dialog and 
assign a key binding for it. This could be helpful if you quickly want 
to see the cspec for something specific and a lot faster to use than the 
 component explorer, I think...

2. Add a new action to the Buckminster popup menu to open the dependency 
visualization without generating a bom first. Sometimes I like to see 
'how does this particular bundle make it into my component tree' and I 
think it's an unnecessary detour to first create a query, resolve it and 
save the bom before you can see the graph. Is there currently a way to 
generate an in-memory bom representing the current resolution state for 
a given component in workspace or the target platform?

3. Add a key binding to quickly open the 'Invoke Action' dialog for the 
current selection (if it adapts to CSPEC)

4. Add a regex filter to the dependency visualizer. Whenever I want to 
know: 'How does this bundle get into my resolution' I use the dependency 
visualizer for that, but it gets a challanging search if that particular 
bundle was resolved from the target platform, because it's simply too 
much in the graph to find it easily. So what I want to add is a regex 
filter on the navigation tree that also filters the graph to drill down 
easily on a specific component. The filter should leave all parents  of 
the selected components in the tree untouched and the graph should still 
display all components that lie on the paths from the selected component 
to the root of the request.


Sorry for all that text, I was just curious what your opinion on these 
ideas are and if you have any further ideas.


Best regards,
Johannes