[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ease-dev] Definition of org.eclipse.ease.module.platform.Selector lost?
|
On 01.09.2014 14:28, GAUFILLET, PIERRE wrote:
I have one major remark: you have gathered in only one module all modelling modules. It means that if you need only EASE for Ecore scripting, you will anyway depends on UML and Papyrus (which increases the size of the product and may induce compatibility issues). I suggest therefore to re-split the module into o.e.e.modules.modeling, o.e.e.modules.modeling.uml and o.e.e.modules.modeling.papyrus.
Modeling stuff was spread over several plugins (not only mentioned
modules), so I merged it into one. I was not aware of your use-case
here, so feel free to re-split it and group it into separate features.
Still this means you might want to move some of the base classes, too.
I moved the modeling stuff as I want to keep the core repository focused
on basic UIs and script engines. This keeps developers focused on the
goal and target platforms & dependencies slim. The modules repo on the
other hand is open for lots of extensions and can be seen as an
incubator for new modules to emerge. On the long run I would like to see
core functionality integrated into the release train. Then eg. the
papyrus project could contribute its scripting modules within the
papyrus repositories.
Back to the modeling modules: as said, they need some cleanup, so I'd
rather leave this to someone with deeper knowledge of the use cases.
eg:
* UMLModule exports just a single method. Ev. this would fit into one of
the oter modeling modules?
* DialogModule and WorkbenchModule are not exported as modules. There
are only few dependencies to these classes. Both contain
similar/identical methods
* NotationModule does not export anything at all. Still we register it
as a module - why?
* should SelectorService be a real eclipse/UI service (or an OSGI one)?
Currently its just a singleton
* classes in editors subpackage are never used
* some parameter names in exported methods do not match parameter names
of signature (with java 8 we might get rid of parameter names at all as
this might be done via reflection, but this needs some more investigations)
quite a list of refactoring potential. These points shall just show up
that simply re-splitting will not do the job. It needs someone involved
with these methods and who understands the use cases behind (which I do
not).
Regarding the FIXME tag in Papyrus module, I suggest removing completely the else statement from line 132 to 136 as the implementation of this method is anyway really partial.
done
At last, I have spotted a double copyright header in WorkbenchModule.java that should probably be fixed.
done
best regards
Christian
