Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] [ide-dev] Fixing the Target platform editor

Mickael,

Comment below.


On 22.11.2016 21:26, Mickael Istria wrote:
On 11/22/2016 08:33 PM, Ed Merks wrote:

We considered it, yes.   Then we considered what it would be like to spend many months on politics, backwards compatibility testing, arguing about design points, and so on, and so on, verses simply spending several weeks implementing something better that can coexist will without adverse impact on legacy details.  Decisions, decisions..

So if I understand correctly, contributing to PDE would have been the ideal case technically speaking, but happened to be too expensive, even for contributors as experienced as you and Eike?
No, technically speaking it doesn't much matter where such technology lives.  We did not have a need to change PDE itself.  It's extensible enough as it is and the legacy implementation is inflexible and brittle and not amenable to significant improvements.

I can for sure understand the argument why not contributing to PDE first in that case, and I hope the cost of contributing to an established project such as PDE gets lower.

In the end, the serialization of the .target file is a direct reflection of the poor implementation (model) of the ITargetDefinition.  You can't simply improve the editor nor can you implement a good design from the existing serialization.  It's just legacy, and in the end, the old design needs to remain there for compatibility.
There are strategies used in Platform to extend model/APIs without breaking existing stuff. It's not an easy problem, but it has solutions (which aren't easy neither).
Exactly, I know those solutions well.  There are a lot of I*[23456] names involved.  And what's the point in the end?   A different implementation and a more flexible model solves the problem better than the layers of baggage-approach.  That was exactly your point about one layer of abstract too many, but it's clear that such layers don't matter as long as the whole triple-decker sandwich is in one project.
Unfortunately, without really understanding it, some feel free, to characterize, in a most-humble-of-opinions-sort-of-way-of-course,  as one layer of abstraction too many. 

Did you consider looking more closely at all the details before expressing a most-humble-opinion

There is no need to go into details to understand that there is a strong duplication of concerns between all those TP formats; and that multiplying solutions for the same issue in a community such as ours can become an anti-pattern as it spread resources across multiple projects and reduce consistency and can even increase the integration cost (if Tycho wants to support all those format, it multiplies the effort, whereas if all were in PDE, there would probably be an API able to consume any of those and integration would have to be done only once for all those formats.
Tycho would only need to use the API, but that's not the design approach it has taken (I believe), so it too is an example of multiplying solutions.

In the beginning of your answer, you explain why you didn't contribute it to PDE; and there was no big technical blocker, it was all about need to find levels of agreement with current project state and "time to market". So somehow, it seems like yourself do agree that the TP work in Oomph would make sense to be in PDE, and that at that point of time, it was/is not something you were willing to do there - for the sake of productivity.
Not really no, not unless Oomph pretty much as a whole is moved into the platform, or lower still.  E.g., there is https://bugs.eclipse.org/bugs/show_bug.cgi?id=500329 to suggest the nice repository explorer could/should be moved to PDE, but it doesn't depend on PDE at all.  It's purely p2 technology, so it could be moved to Equinox.  But I notice that no one on the platform team is keen on that suggestion.  Go figure huh?

Overall the question is: where as a whole does the Oomph technology stack live?  Why does it need to move at all?

So at least, I read your mail as an acknowledgment that the TP parts of Oomph would rather be in PDE, so we somehow agree.
No, you read that wrong.
Maybe it would be the right time to consider migrating some pieces of Oomph to PDE?
No, read 500329 and consider where the Oomph technology stack belongs.



--
Mickael Istria
Eclipse developer for Red Hat Developers
My blog - My Tweets


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

IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation.  To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.

Back to the top