An Oomph Targlet definition is not a layer of abstraction on top
of a .target.
Oomph targlet technology is directly an alternative
implementation of an ITargetDefinition. It's more efficient
(shared bundle pool), it's more resilient (failure to resolve
doesn't leave you with no resolved target at all), it's more
flexible (supports version ranges and resolves workspace
dependencies without repeating precisely the dependencies that are
already present in every project's features and manifests), it's
more expressive (one definition can be used for multiple different
baselines), and it supports composition (so you can work with more
than one project's target definition without reauthoring the whole
thing). It's not just a fancier syntax and it's not a layer of
abstraction on top of something else. In my not so humble
opinion it's one of the crown jewels of Oomph.
For those technologies that can only consume a .target
serialization format (Tycho being the only notable example) rather
than use the ITargetDefinition API directly, Oomph can generate a
.target file for that purpose, but Oomph itself doesn't need such
a file. I.e., the generated .target file is not a layer of
abstraction but rather a bridge for Tycho.
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.
FWIW, I share the opinion that adding another layer on top of
.target is a layer too much. Yes, there are more fancy
alternatives to XML available but that does not necessarily mean
we have to add another layer to support them. I too would like
to see the issue addresses directly in PDE.
In an ideal world, such improvements
would have directly happened in PDE and the .target format
and editor...
Keep in mind that it's not just PDE but PDE plus Tycho plus
potentially p2. Thus, three different projects would need to
be touched (depending on the feature/limitation you want to
remove). Three different legacy code based. Three different
project teams to communicate with.
IMO, this is a symptom of our
community (and maybe all communities): people try to fix
things by creating an upper layer without the limitations
rather that fixing what needs to be fixed.
You are making a good point. However, you should
know it's by far not as easy as you write it.
As someone who tries fixing things where they should
be fixed, let me heat up the discussion:
-----
Even if you go the extra mile and work yourself into
an existing, legacy code base - there is simply no guarantee
today your change will get in. It is way easier to build
something outside of a project - especially outside of PDE.
First it was not the right strategy - committers had large
visions and particular ideas how to implement things - after you
came up with a patch. Then it became lack of resources. Later on
it was inexperience with that particular area of the code base.
Frankly, the only one that is really trying is Lars
and he admits that he does not know anything about the code
base. He was the only one who cares about a patch I submitted to
PDE weeks ago. Is this really the strategy?
FWIW, I see Eike has two reviews open with p2. Both
opened 2014. No feedback. Nothing. So again, how do you want to
motivate people fixing what and where it needs to be fixed?
----
Crazy idea, what if we just grant commit rights for
all project to every member of the AC. I trust every single one
of them of doing the right thing. If it's not working out, i.e.
bad/poor communication, abuse of power, than they don't belong
to the AC.
_______________________________________________
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.
