I'd rather have it in a bundle of it's own but included in the core UI feature. Perhaps that's what you meant?

*1

Guillaume Chatelet wrote:

Totally agree with you Henrik. Let's put it in the UI Bundle.

I'd rather have it in a bundle of it's own but included in the core UI feature. Perhaps that's what you meant?

Totally agree with you Henrik. Let's put it in the UI Bundle.

Regards,
Thomas Hallgren

... by 'patch' you mean just a copy of the source, right? Or how would I create a patch against a repository where the plugin is not yet checked in?

It's OK to attach a zip containing the project as a whole.

Some things to think about before you submit the code:

1. You need to add an 'about.html' file stating that the code is EPL 1.0 to the plug-in (see attachement).
2. The 'about.html' must be included in the binary build of the bundle, i.e. checked on the manifest editor 'Build' tab.
3. You probably want to add a copyright notice to the head of each source file.

That's easy enough to do, but before that I should probably put everything in a shape that's acceptable for the buckminster team and the foundation, because once it's commited it would be a lot harder to do stuff like string externalization, api-doc,... because I'd need to provide all that as separate patches, right?
Where can I look-up the things like coding guidelines, naming conventions, icon conventions,...?

There's also a really dirty implementation hack that I'd rather not see in a released version, unfortunately I couldn't find another way. I wanted to open the selected component's cspec on double click, but it turned out that you don't export the package that contains the CSpecEditorInput. I worked my way around by subclassing ViewChosenCSpecAction and invoke its run method, but that's really nasty...
Would there be another way to open a cspec, or should it stay like that?

Let it remain like that for now. This can be refactored once the patch is in.

Either way sounds fine to me, but I should point out that I'm pretty much the only person that tested this plugin so far. Bundeling it with the core UI feature could give users the impression that it's a well tested and mature feature, but maybe that's just me.

It's definetly not huge and here's a list of the dependencies:

org.eclipse.core.runtime,
org.eclipse.zest.core;bundle-version="1.1.0",
org.eclipse.zest.layouts;bundle-version="1.1.0",
org.eclipse.buckminster.ui;bundle-version="1.0.350",
org.eclipse.core.resources;bundle-version="3.5.0",
org.eclipse.ui;bundle-version="3.5.0",
org.eclipse.ui.forms;bundle-version="3.4.0",
org.eclipse.ui.ide;bundle-version="3.5.0",
org.eclipse.buckminster.core;bundle-version="1.1.350",
org.eclipse.buckminster.sax;bundle-version="1.0.0",
org.eclipse.equinox.p2.core;bundle-version="1.0.100"

Regards,
Thomas Hallgren

comments inline.

Johannes,
I tried this and I'm amazed. It looks great and I don't think it needs further improvement at this stage. It's very useful as it is and I'd like to include it in Buckminster. In order to do that, you'd have to submit the code in a bugzilla so that we can get the IP approval process going (a contribution of this size must be scrutinized by the Eclipse EMO). A bugzilla with a proper patch will also give people a chance to voice their opinion about the patch.

Some things to think about before you submit the code:

1. You need to add an 'about.html' file stating that the code is EPL 1.0 to the plug-in (see attachement).
2. The 'about.html' must be included in the binary build of the bundle, i.e. checked on the manifest editor 'Build' tab.
3. You probably want to add a copyright notice to the head of each source file.

How do we package this in Buckminster? Should we add a special 'Dependency Visualization' feature or should we simply include it in the core UI distribution? Opinions welcome.

Kind Regards,
Thomas Hallgren

Henrik Lindberg schrieb:
> I would put it in the buckminster UI unless it is (unexpectantly)
> a) huge or b) there are issues with required bundles.
>
> - henrik

It's definetly not huge and here's a list of the dependencies:

org.eclipse.core.runtime,
org.eclipse.zest.core;bundle-version="1.1.0",
org.eclipse.zest.layouts;bundle-version="1.1.0",
org.eclipse.buckminster.ui;bundle-version="1.0.350",
org.eclipse.core.resources;bundle-version="3.5.0",
org.eclipse.ui;bundle-version="3.5.0",
org.eclipse.ui.forms;bundle-version="3.4.0",
org.eclipse.ui.ide;bundle-version="3.5.0",
org.eclipse.buckminster.core;bundle-version="1.1.350",
org.eclipse.buckminster.sax;bundle-version="1.0.0",
org.eclipse.equinox.p2.core;bundle-version="1.0.100"

Thank you very much for your help and best regards,
Johannes

Johannes,
I tried this and I'm amazed.

I have not tried it, but the screnshoots look really good.

How do we package this in Buckminster? Should we add a special 'Dependency Visualization' feature or should we simply include it in the core UI distribution? Opinions welcome.

I would put it in the buckminster UI unless it is (unexpectantly)
a) huge or b) there are issues with required bundles.

- henrik

Some things to think about before you submit the code:

Kind Regards,
Thomas Hallgren

Hi,

I had some time since the last post to work an the visualization and these are the latest changes:

-better path highlighting. so far 3 kinds of relationships are implemented for highlighting:
-path to direct dependencies of the selected component
-path to components that directly require the selected component
-path to root request. (either shortest, or all)
each way of highlighting can be selectively enabled/disabled and is additive to the other selected highlightings

-tooltips on components to reveal some details -sash form between navigation tree and graph viewer
-better resize behavior
-bugfixes
-tidier code base and architecture

Unfortunately something seems to be broken in the Zest zooming support, so that feature didn't make it into the visualization just yet and it's still just registered as a bom editor because I couldn't think of other useful integration points.

Apart from that it I think it's pretty usable already and I'm curious what you want me to add/change/do before you'd consider to accept it as a contribution.

Attached are some updated screenshots to get an impression as well as the exported bundle including source code.

Remarks for the screenshots:
light green = root component (either cquery root, or drilled down)
green = path to root component
orange = direct dependencies
blue = components that directly depend on the selected component
yellow = current selection

Best regards,
Johannes

------------------------------------------------------------------------

------------------------------------------------------------------------

------------------------------------------------------------------------

Kind Regards,
Thomas Hallgren

First I would like to state my newbie status on Buckminster and I'm sorry if
posting in the wrong forum (Could not find any "Buckminster - Users" forum).

Looking at alternatives for a CI setup for multiple RCPs on a shared base
Buckminster comes out as the most obvious and mature candidate. Though I'm
very unfamiliar with it reading about the key concepts and the strong
integration with PDE gives me assurance.

Just have one small question that will help me answer if it is worth going
forth with some prototyping and in the long run abandon our existing ANT
based system...is it possible to make this work on a ClearCase env?

No need to set up views and stuff automagically but just being able to
handle resolving on views with different names. Is it possible to use
property expansion in the .rmap URIs e.g. env.CLEARCASEVIEW or
-Dclearcase.view.name=myView

Thanks
Patrik