[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: [jwt-dev] problem in the WE
|
Hi Chris
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 Eclipse.
So projects must not be merged because of such a development environment
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).
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 project
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... ?
Regards,
Marc
Christian Saad a écrit :
Hi Mickael,
Hi Christian,
just a quick question: I've got a problem running the HEAD version of
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 or
did I mess something up?
I don't have such problem...
I edited a bit in the plugin.xml and suddenly it went away although compare
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
them
into one or two plugins (throw together model and edit code and maybe
even properties and conf if they're needed anyway) as to prevent the
separation into too many single plugins. I don't know about you but I
always get confused with too many projects in my workspace ;) Also it
could simplify the version management in the future and clear up the
CVS a bit. What's you opinion?
If we merge model and edit code, there will be one day where we will
have to go back and separate them, just as it is now happening for WE
metamodel.
I'm however in favor of merging conf and property, since they are
actually the same feature, and than someone who consumes aspects must
consume both.
For sure it will be easier for us to develop with less plugins, but it
will be more difficult for extenders to consume JWT. Then, we have to
be
careful about such huge refactorings. Moreover, models are part of our
APIs, which means that we must do everything necessary to avoid their
(APIs and containment plugins) version to change.
IMHO, version management will be more difficult if we merge plugins and
if we create unjustified coupling.
Hmm, the reason why I thought we could merge model and edit code was that I
currently can't think of a scenario where one needs to have them separated.
With the metamodel I was actually going for the put-all-model-stuff-together
approach, so it currently contains ecore, templates, generated model and
edit and the commands which are not specific to the WE so that everything
for generating, using, editing and displaying (in the sense of
itemproviders) the model is in one place, which I think in the case of the
core model makes really sense but maybe not for the conf-model? I'm just a
bit concerned that as the code is split up into more and more places the
project in a whole may become more difficult for us to maintain.
Best regards,
Chris
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
