[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.


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

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.


-----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

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 :
Hi Mickael,

Hi Christian,

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
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
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
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
I'm however in favor of merging conf and property, since they are
actually the same feature, and than someone who consumes aspects
consume both.
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
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
With the metamodel I was actually going for the put-all-model-stuff-
approach, so it currently contains ecore, templates, generated model
edit and the commands which are not specific to the WE so that
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
project in a whole may become more difficult for us to maintain.

Best regards,

_______________________________________________ jwt-dev mailing list jwt-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/jwt-dev

jwt-dev mailing list

jwt-dev mailing list