Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
Im Auftrag von Marc Dutoo
Gesendet: Dienstag, 12. Mai 2009 15:08
An: Java Workflow Toolbox
Betreff: Re: AW: [jwt-dev] problem in the WE
I understand there are too much project in your workspace. Actually, in
mine I feel it's the same !
However, there are tooling solutions like workspaces or working spaces
(kinda like project categories) that addresses this issue well in
So projects must not be merged because of such a development
problem. Rather, they *can* be merged if there are
* no separate use case,
* and induces no excessive coupling
* nor architectural oversimplification (meaning, better a fine
grained architecture than a simple one that has a lot of code mashed
In our case, I'd say there is at least a generic use case where someone
wants to parse and read the jwt format in its own runtime using the EMF
plugin in standalone mode. He could not do that if the JWT model
had dependencies on SWT etc.
Moreover separating model and edit is common practice, and I'd rather
push for more granularity than for less. As Mickael said, we've seen
what pain the opposite brings when we try to make it evolve.
However it is possible that EMF.edit projects do not add any such
dependency but I'm not sure it still allows standalone use... ?
Christian Saad a écrit :
just a quick question: I've got a problem running the HEAD version
the WE because of an error in the plugin.xml: It complains that the
dnd extension point cannot be found. Do you have this problem too
I edited a bit in the plugin.xml and suddenly it went away although
did I mess something up?
I don't have such problem...
shows no changes... Strange...
In a completely different matter, I'm currently wondering, since WE
now depends on the conf and property plugins, if we could combine
into one or two plugins (throw together model and edit code and
even properties and conf if they're needed anyway) as to prevent
separation into too many single plugins. I don't know about you but
always get confused with too many projects in my workspace ;) Also
could simplify the version management in the future and clear up
If we merge model and edit code, there will be one day where we will
CVS a bit. What's you opinion?
have to go back and separate them, just as it is now happening for
I'm however in favor of merging conf and property, since they are
actually the same feature, and than someone who consumes aspects
For sure it will be easier for us to develop with less plugins, but
will be more difficult for extenders to consume JWT. Then, we have
careful about such huge refactorings. Moreover, models are part of
APIs, which means that we must do everything necessary to avoid
(APIs and containment plugins) version to change.
IMHO, version management will be more difficult if we merge plugins
Hmm, the reason why I thought we could merge model and edit code was
if we create unjustified coupling.
currently can't think of a scenario where one needs to have themseparated.
With the metamodel I was actually going for the put-all-model-stuff-together
approach, so it currently contains ecore, templates, generated modeland
edit and the commands which are not specific to the WE so thateverything
for generating, using, editing and displaying (in the sense ofof the
itemproviders) the model is in one place, which I think in the case
core model makes really sense but maybe not for the conf-model? I'mjust a
bit concerned that as the code is split up into more and more placesthe
project in a whole may become more difficult for us to maintain.
jwt-dev mailing list
jwt-dev mailing list