[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[buckminster-dev] Some improvements/ideas for buckminster
|
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