[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[buckminster-dev] Re: Dependency Visualization
|
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