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