[buckminster-dev] Re: Dependency Visualization

[Johannes Utzig <mail@xxxxxxxxx>]

Hi Thomas,

I'm done now with the code clean up and submitted it as a bugzilla 
attachment:
See:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=282569

Best regards,
Johannes

Thomas Hallgren schrieb:
> Hi Johannes,
>
> Johannes Utzig wrote:
> > ... 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,...?
> Actually, what I'm after is things that might be significant in your 
> initial contribution. The EPL affinity is such a thing and if you want 
> to retain your own copyright, you need to do that too before your 
> initial submission.
>
> The code will be reformatted according to the Buckminster Formatting 
> rules and the project will have preferences set that will enforce this 
> before it's checked in.
>
> > 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.
> Of course it must be tested before we decide to release it but one 
> important aspect of testing is to let the community at large get their 
> hands on it and start hammering. Since this is a viewer, the bugs found 
> in it will not be disruptive, so I'd rather see that happen sooner 
> rather then later.
>
> > 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"
> Right. The only added dependencies here are the two zest bundles. The 
> rest is already required from our own UI bundle.
>
> Regards,
> Thomas Hallgren