[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: AW: [jwt-dev] problem in the WE
|
Hello,
of course if we decide to do this than it will be at some point in the
distant future, just wanted to hear your opinion about this issue.
Regards,
Chris
> -----Ursprüngliche Nachricht-----
> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
> Im Auftrag von Florian Lautenbacher
> Gesendet: Mittwoch, 13. Mai 2009 11:04
> An: 'Java Workflow Toolbox'
> Betreff: AW: AW: AW: [jwt-dev] problem in the WE
>
> Hi there,
>
> I agree that the conf-model-we-extensions should be separate so that
> this
> plugin can be disabled and nobody sees the ManageProfiles-tab if it is
> in a
> specific case more confusing than helpful.
>
> I also agree that too many plugins make it more difficult to maintain
> the
> existing code. But as we declared them as API I think we should not
> change
> them now unnecessarily. There might be some point at a time when
> companies
> request to have these plugins combined then we can discuss that issue
> again.
> But for the moment I think we have enough other work for Galileo, that
> I
> would not like to start some more refactoring.
> So I vote for leaving all plugins as they are now.
>
> Best regards,
>
> Florian
>
> -----Ursprüngliche Nachricht-----
> Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx]
> Im
> Auftrag von Marc Dutoo
> Gesendet: 13 May 2009 10:56
> An: Java Workflow Toolbox
> Betreff: 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
> >
> _______________________________________________
> 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
