[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