[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [jwt-dev] problem in the WE
|
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
