[buckminster-dev] Re: Dependency Visualization

[Johannes Utzig <mail@xxxxxxxxx>]

Hi Thomas, hi Henrik,

comments inline.

Thomas Hallgren schrieb:
> 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.
I'm glad that you want to include it, that's great. One dumb question 
about that: 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?

> 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?

> 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

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.

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"


Until I hear more from you I'll add some java-doc, comments, do some 
code formatting, see if I can paint some better icons (I suck at that 
:)), externalize the strings, add the copyright statement and the licence.


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