[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
