Home » Eclipse Projects » Buckminster dev » Some improvements/ideas for buckminster
| Some improvements/ideas for buckminster [message #494360] |
Fri, 30 October 2009 11:56  |
 Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
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
|
|
|
| Re: Some improvements/ideas for buckminster [message #494528 is a reply to message #494360] |
Sat, 31 October 2009 08:05  |
|
Hi Johannes,
it was indeed great to have a chance to meat fact to face. I think the ESE was great from a Buckminster perspective.
Lot's of interest and active dialogs.
Comments inline.
On 10/30/2009 12:56 PM, Johannes Utzig wrote:
> 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.
>
My maven skills are also limited so I second Johannes request here. I would really appreciate if users that have an
interest in maven support would take a step forward on this one and help us out with the requirements. Here's your
chance. What is the worst pebble in shoe right now and how should we address it?
> 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.
>
Yes, let's divide this into two ideas. A p2 repository is able to store maven artifacts without converting them first.
Using them in a PDE environment is another matter. So the issues are:
1. Put a p2 facade on a maven repository.
2. Automatic transformation of non-OSGi bundles.
I think #1 is particularly interesting since it would allow us to aggregate maven repositories together with p2
repositories. #2 is interesting too but not without complications since it implies that you make changes to the manifest
(i.e. you must re-create the jar file) which in turn means that its more then just a meta-data operation. I think #2 is
perhaps more a thing you do during a build (or materialization) then during an aggregation.
I suggest that you open two separate bugzillas for this where we can continue the discussion.
> -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?
>
I think the best alternative is to write an actor that contains the install logic. The reason it's being deferred so far
is that p2 cannot run multiple profiles in the same runtime. So using the director functionality to install things would
taint the Buckminster runtime. This is being addressed in p2 and a better solution will be available soon
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=290207).
I think a create.product actor is a great idea and I suggest you add a bugzilla for this. I'm not much in favor of
calling ant just to call on an executable that in turn is an OSGi runnable :-)
>
> -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...
>
You can already right-click and do 'Buckminster' -> 'View CSpec...' in your package explorer but perhaps I misunderstand
what you mean?
> 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?
>
Yes. You re-resolve a query :-)
Seriously. That is the way to do it. Once a component is in your workspace it may change in all kinds of ways which in
turn changes its dependencies. The good news is that the resolution is very quick. Buckminster performs such resolutions
behind the scene a lot of times.
Take a look at the method o.e.b.core.metadata.WorkspaceInfo.resolveLocal(). It uses the main resolver to resolve a
request. At the end, it returns the top resolution of the BillOfMaterials. This method could easily be broken into two.
One that retain the current behavior and the uses another internally, that would return the BOM. A dependency
visualization popup menu could then make use of the second. All the popup menu must do is to form a component request
based on context.
Deserves a bugzilla :-)
> 3. Add a key binding to quickly open the 'Invoke Action' dialog for the
> current selection (if it adapts to CSPEC)
>
Sure. Add a bugzilla.
> 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.
>
On what would you apply this filter? The component name?
Sounds to me like you would benefit more from being able to apply a filter on certain treats of the resolution, such as
readerType or the uri of the reader type.
One idea could be to leave the graph intact but highlight the components that match the filter(s) that are currently in
effect.
I think filtering in general would be a very useful addition to the dependency visualizer. The graph is often very
large. So please add a bugzilla for that.
B.t.w. did you see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=291963 ?
>
> Sorry for all that text, I was just curious what your opinion on these
> ideas are and if you have any further ideas.
>
I think "all that text" was great input. Sorry if push some more work your way by asking for a lot of bugzillas but
there are two very good reasons for doing that. Both of them positive:
1. We must have a bugzilla to continue the work and spec things out. When I ask you to enter one it is a way for me to
say - yes, let's take this to the next level.
2. You initiated the discussion and should have the credit for that so you should own the bug.
Regards,
Thomas Hallgren
|
|
|
| Re: Some improvements/ideas for buckminster [message #494568 is a reply to message #494528] |
Sat, 31 October 2009 14:50 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
Hi Thomas,
comments inline.
Thomas Hallgren schrieb:
> You can already right-click and do 'Buckminster' -> 'View CSpec...' in
> your package explorer but perhaps I misunderstand what you mean?
>
>
Yes, I can do that for my projects, I cannot do it however for things in
my target platform or let's say maven artifacts that I resolved. All
things that are not projects in my workspace are currently only
reachable with the component explorer. An Open CSpec Dialog that works
like JDTs Open Type Dialog would be handy to open any component's cspec
from anywhere.
> Take a look at the method
> o.e.b.core.metadata.WorkspaceInfo.resolveLocal(). It uses the main
> resolver to resolve a request. At the end, it returns the top resolution
> of the BillOfMaterials. This method could easily be broken into two. One
> that retain the current behavior and the uses another internally, that
> would return the BOM. A dependency visualization popup menu could then
> make use of the second. All the popup menu must do is to form a
> component request based on context.
>
> Deserves a bugzilla :-)
Great, thank you :)
> On what would you apply this filter? The component name?
> Sounds to me like you would benefit more from being able to apply a
> filter on certain treats of the resolution, such as readerType or the
> uri of the reader type.
>
I would go for name, because that's the thing I already know when I'm
wondering where component XY comes from, but readerType/URI makes sense
too of course, if you are wondering which components where resolved from
where. I'll try some things out regarding different types of
filters/highlighters and open a bugzilla where filter capabilities can
be discussed
> One idea could be to leave the graph intact but highlight the components
> that match the filter(s) that are currently in effect.
>
That's a very good idea. I'll try that.
> I think filtering in general would be a very useful addition to the
> dependency visualizer. The graph is often very large. So please add a
> bugzilla for that.
>
> B.t.w. did you see: https://bugs.eclipse.org/bugs/show_bug.cgi?id=291963 ?
>
I must have missed that one, thank you for the pointer, I'll take care
of it.
> I think "all that text" was great input. Sorry if push some more work
> your way by asking for a lot of bugzillas but there are two very good
> reasons for doing that. Both of them positive:
>
> 1. We must have a bugzilla to continue the work and spec things out.
> When I ask you to enter one it is a way for me to say - yes, let's take
> this to the next level.
> 2. You initiated the discussion and should have the credit for that so
> you should own the bug.
>
Don't apologize for asking me to create bugzillas, that's the reaction I
was hoping for, because it means you consider these points valid.
Best regards and thank you for your helpful answers,
Johannes
|
|
| |
Goto Forum:
Current Time: Fri Apr 19 12:33:05 GMT 2024
Powered by FUDForum. Page generated in 0.02225 seconds |
] 
Search
Help
Register
Login
Home
