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...
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. Why bother improving it, when every change
will break someone somehow? Look at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=506850 as a
case in point.
Something new-and-improved is badly needed to supersede the
legacy baggage without disrupting the baggage itself. Now we
have it, in Oomph.
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?
On 22.11.2016 16:51, Mickael Istria
wrote:
On 11/22/2016 04:47 PM, Ed Merks
wrote:
The .target editor is basically unusable. It screws up IDE's
current resolved target just to open the editor. I never use it
and I cringe when I'm at a customer site and they double-click
the generated .target file that they need only for their Tycho
build.
Even if there existed a great .target editor (or there existed
an editor with a prettier syntax), the built-in
ITargetDefinition implementation itself is very poor.
Did you consider contributing enhancement to the default
implementation of ITargetDefinition or to the .target editor?
I think our community would be better off if there
were less things in the platform (PDE and JDT don't belong
there).
+1.
_______________________________________________
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.