The XML editor is part of WTP, a couple of layers up. Ant
support, including the Ant editor is part of the root Eclipse
project (for historic reasons). The SDK builds in the root
Eclipse project can only include what’s in that project. It’s
not a general-purpose packaging solution, like EPP.
The core Eclipse project includes at least two XML editors
(plugin.xml and ant build.xml) that are custom-built from the
ground up (for historic reasons). For architectural and
user-experience reasons, it would be best to rebase those on
the general-purpose XML editor, but no one has stepped forward
to do the necessary work.
- Konstantin
From: Andrey Loskutov
Sent: Monday, October 19, 2015 10:35 AM
To: Discussions about the IDE;Konstantin
Komissarchik;Daniel Megert
Subject: Re: [ide-dev] Ctrl-1 driven development
Thanks Konstantin!
What about the "pure" SDK builds? It
includes ant editor but not xml editor. Which product is
responsible for adding xml editor to SDK?
Am 19. Oktober 2015 18:58:30 MESZ, schrieb
Konstantin Komissarchik
<konstantin.komissarchik@xxxxxxxxxx>:
>Regarding inclusion of XML Editor in
EPP packages, here is a run-down
>of which one include it. For ones that
don’t, I have opened enhancement
>requests to consider adding it.
>
>Included
>
>Eclipse IDE for Java EE Developers
>Eclipse IDE for Java Developers
>Eclipse IDE for PHP Developers
>Eclipse IDE for Java and DSL Developers
>Eclipse IDE for RCP and RAP Developers
>Eclipse IDE for Automotive Software
Developers
>Eclipse IDE for Java and Report
Developers
>Eclipse IDE for Parallel Application
Developers
>
>Not Included
>
>Eclipse IDE for C/C++ Developers
>(https://bugs.eclipse.org/bugs/show_bug.cgi?id=480141)
>Eclipse IDE for Eclipse Committers
>(https://bugs.eclipse.org/bugs/show_bug.cgi?id=480142)
>Eclipse Modeling Tools
>(https://bugs.eclipse.org/bugs/show_bug.cgi?id=480143)
>Eclipse for Testers
>(https://bugs.eclipse.org/bugs/show_bug.cgi?id=480144)
>Eclipse for Scout Developers
>(https://bugs.eclipse.org/bugs/show_bug.cgi?id=480145)
>
>It once again strikes me that the high
number of
>minutely-differentiated packages isn’t
actually helping our users. It
>certainly reflects the result of
decentralized product planning, which
>is hurting our competitive position.
This group could work towards
>encouraging packages with largely
overlapping user profiles to merge.
>
>For instance, a combined Java IDE could
be the union of:
>
>Eclipse IDE for Java EE Developers
>Eclipse IDE for Java Developers
>Eclipse IDE for Java and DSL Developers
>Eclipse IDE for RCP and RAP Developers
>Eclipse IDE for Java and Report
Developers
>Eclipse IDE for Eclipse Committers
>Eclipse Modeling Tools
>
>A combined C++ IDE could be the union
of:
>
>Eclipse IDE for C/C++ Developers
>Eclipse IDE for Parallel Application
Developers
>
>What leads to proliferation of packages
is projects getting rejected by
>owners of an existing package. We could
consider moving the
>responsibility for defining what
packages are produced and what they
>include to one of the councils. That
doesn’t mean that every project
>that asks would get included, but
should ensure better representation
>for all projects in the decision
process. It would also provide an
>essential push-back for projects trying
to use the EPP process as a
>promotional vehicle. For instance, I
doubt that Scout is so widely used
>that it warrants inclusion in a
package, let alone it’s own package.
>
>Note that the download numbers can be
deceptive as a measure of need.
>For instance, the long flat tail of the
popularity graph currently
>floats at 23k to 27k level. This
indicates that we are likely dealing
>with roughly 20k downloads initiated by
automated actors that download
>all packages.
>
>Thanks,
>
>- Konstantin
>
>
>
>From: Daniel Megert
>Sent: Monday, October 19, 2015 8:27 AM
>To: Discussions about the IDE
>Subject: Re: [ide-dev] Ctrl-1 driven
development
>
>
>I finally caught up with that thread,
which - like so often - heavily
>diverged from the initial and
well-focused suggestion from Mickael :-)
>
>> So an easy way to improve Eclipse
IDE would be to add to the Ctrl+1
>the operations that users likes in this
very narrow context.
>This suggestion in Mickael's initial
e-mail is a very good one, and we
>can discuss which things to add via bug
480131. Please add your
>comments there.
>
>The other mentionable topics I saw in
that thread:
>
>- XML Editor
>Packages can decide to include this.
Even CDT can do so. Hence, I do
>not consider this a big issue - maybe
it should just be part of all
>packages these days. There is no need
to restructure any projects or
>move code around.
>
>- Install hell for our users
>I totally agree with this. Even with
EPP it is hard for a user to pick
>the right package, e.g. the 'Eclipse
IDE for Java Developers' package
>contains the XML Editor but 'Eclipse
IDE for Eclipse Committers ' does
>not. In our Eclipse Vision meetings
from last year our hope was that
>Oomph (the new Eclipse installer) would
help to fix this. So, maybe we
>need to push more on this. Another idea
that we discussed in those
>meetings and was also mentioned in this
thread is a hook, so that when
>a user opens a certain file and no
editor is available, we suggest to
>install the corresponding (small)
feature(s). I think the latter is
>definitely worth working on and could
qualify for FEEP.
>
>- Hard to know all our cool features
>I like the idea of more aggressively
advertising our IDE features on
>the web pages and especially on a
combined IDE page. JDT is definitely
>willing to participate here, but only
to provide the content and not
>the design. Like Doug and Ian, I don't
think FEEP money would be good
>spent here.
>
>Dani
>
>
>
>From: Mickael Istria
<mistria@xxxxxxxxxx>
>To: "'Discussions about the
IDE'" <ide-dev@xxxxxxxxxxx>,
>jdt-dev@xxxxxxxxxxx
>Date: 14.10.2015 18:21
>Subject: [ide-dev] Ctrl-1 driven
development
>Sent by:
ide-dev-bounces@xxxxxxxxxxx
>
>
>
>
>Hi all,
>
>I've spent some times asking former
Eclipse RCP developers now
>converted to the 300$/year IDE on what
they thing are the best things
>that are missing in Eclipse IDE.
>
>What they tell first is the quality of
the "quick-fixes" in IntelliJ.
>But when you get into details, what
makes the difference isn't really
>that IJ has editing/refactoring
operations that Eclipse IDE doesn't
>have, but more that IJ shows the useful
ones (and only the useful ones)
>on their Alt+Enter.
>In Eclipse, a lot of operations are
available under Source and Refactor
>context menu, but it's a lot of menus
to browse, it takes a lot of
>time, mostly requires to use mouse,
requires to read a lot of entries
>that are contextual to the editor but
not to the active selection...
>It's complicated.
>Eclipse has the very good Ctrl+1 menu,
which is basically meant to host
>such small operations that are in the
context of the selection in an
>editor. Eclipse IDE (precisely JDT UI)
already shows a few relevant
>ones, but some other good ones are
missing.
>
>So an easy way to improve Eclipse IDE
would be to add to the Ctrl+1 the
>operations that users likes in this
very narrow context. If you get
>such an idea, please report it to
JDT/UI and share it. I believe fixing
>that isn't a too difficult task, with
no risk at all, and that it would
>provide much user satisfaction. It
could even be a great topic for a
>hackathon.
>I plan to make a more direct comparison
of these quick-fixes one day
>(cannot be more precise, so don't wait
for me if you're faster) and to
>come up with a list of the ones that
are missing in Eclipse IDE to make
>this Ctrl+1 so efficent that user won't
have to dig in the context-menu
>and will always get their favorite
operation in a few keystrokes.
>
>Cheers,
--
Kind regards,
Andrey Loskutov
http://google.com/+AndreyLoskutov
