[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: AW: AW: [jwt-dev] problem in the WE
|
Hi Chris
I knew that you knew but had to say it nonetheless ;)
I believe org.eclipse.ui is bad because it is an eclipse dependency that
can't be provided at runtime to a standalone EMF jar.
The conf-model has been rewritten to be independent of JWT so it should
stay separate.
However, jwt-we-conf-model.we could be merged with the JWT editor code
() because it is basically extensions to the JWT WE built using the
conf-model and its UI helpers.
Though that would mean JWT could no longer be used without aspects and
those extensions, which could maybe be a problem for old use cases -
such as AgilPro ? at least it'd be a request of you guys that it'd be
separate.
So all in all I'd say it's better for jwt-we-conf-model.we to also stay
separate.
Regards,
Marc
Christian Saad a écrit :
Hi Marc,
of course you're right, an uncomfortable feeling in the workspace does not
justify changing the architecture of the project ;) This was just to
illustrate that there might be an issue.
I also totally agree with your preconditions that must be fulfilled in order
to merge. Because of this I tried to keep the JWT metamodel as separate as
possible. It has only dependencies on
org.eclipse.core.resources, org.eclipse.ui, org.eclipse.emf.common,
org.eclipse.emf.ecore, org.eclipse.emf.edit, org.eclipse.emf.common.ui,
additional functionality like icons and visibility may be injected from the
outside.
Of course I can't be sure if merging would be really a good idea, especially
since you guys are the ones who are the experts on the conf-model and are
familiar with the use cases.
Regards,
Chris
-----Ursprüngliche Nachricht-----
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
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
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
