On Mon, Nov 14, 2022 at 8:27 PM Christoph Läubrich
<laeubi@xxxxxxxxxxxxxx <mailto:laeubi@xxxxxxxxxxxxxx>> wrote:
Hi Eric,
disclaimer: I'm not a jdt committer (just user, some times
contributor)
but can understand some of your pain points as I was already hit by
them
(e.g. release process) so really would like some improvements in
that
area as well!
Just some thoughts here:
1) jdt.core recently enabled github discussions:
https://github.com/eclipse-jdt/eclipse.jdt.core/discussions
<https://github.com/eclipse-jdt/eclipse.jdt.core/discussions>
it might be good to split your mentioned items into separate
discussions
instead of one big "all we need to solve" as its easier to follow
more
focused discussion than one big mailing-list thread.
For Red Hat it's important to understand whether the community agrees
with us on the overall direction and is ready to accept that a good
number of things have to change, not whether change A, B.. X, Y, Z
are fine. Thus single discussion is better suited here compared to
going into technical details about possible change X.
2) If "The Eclipse team at Red Hat" has contributed in the past to
JDT I
think its fair to ask for a committer election for some of them
so they
get more influence/visibility on the JDT project.
3) If its just a matter of "how can we build / release more
independently" I can offer the JDT-Team to help out at these parts
4) There are already some effort going on to restructure JDT
(e.g. the
compiler see
https://github.com/eclipse-jdt/eclipse.jdt.core/pull/182
<https://github.com/eclipse-jdt/eclipse.jdt.core/pull/182> )
but it could need some help from people more familiar with JDT (than
me)
to push such initiatives forward, so probably your team can help
with
that as well? I think PR backlog is actually something where help is
needed.
5) For "users feel lost" I think the best is to just suggest
where/what
documentation needs improvements, its often hard to guess *what*
holds
users back e.g. the move to github has already lowered the
barrier much
I think, but for sure there are things to still improve!
best
Christoph
Am 14.11.22 um 18:21 schrieb Eric Williams:
> Hello members of the JDT community:
>
> I am the manager of the Eclipse team at Red Hat -- some of you
may know
> me from my days working on SWT-GTK. I am writing to you today to
give an
> update on Red Hat's future plans with respect to Java tooling and
JDT.
>
> The age of language support tooling specifically built for one
IDE is
> long gone. This has made us, the Eclipse team at Red Hat,
adjust our
> strategy around Java tooling development over time. Years ago, we
became
> heavily involved in Eclipse JDT.LS <http://JDT.LS>, which relies
on the Eclipse JDT
> project to provide most of the compiler and language
functionality
> underneath. Our contributions to this piece of the ecosystem have
worked
> well for years but are no longer sufficient due to considerably
reduced
> involvement in the JDT project overall.
>
> A significant cause of the decrease in contributions is the
lack of
> velocity in JDT development, which forces dependent projects, and
> potential contributors to stack workarounds in their own projects
> instead of contributing the improvements back to JDT.
Contributing
> JDT.LS <http://JDT.LS> specific fixes and improvements upstream
to JDT has been part of
> our team duties for the last few years. Unfortunately, this is
not the
> default behavior across the board, which leads us to ask each of
you for
> some fundamental changes in both JDT and its dependent project’s
practices.
>
>
> Here is a list of things that from our POV are hard requirements
for the
> projects to continue to thrive:
>
> A) Releng Improvements
> - Reorganize the JDT codebase, decouple it from Eclipse specific
> concepts (workspaces, resource model, etc.). This is already
WIP. [1]
>
> - Move the jdt.core.manipulation project to the eclipse.jdt.core
> repository, enabling a separate releng procedure that allows the
release
> of JDT core bits on demand, easing its consumption by non-Eclipse
> projects to consume it.
>
> B) Refactorings
> - A big percentage of the Java functionality is tightly coupled
with the
> Eclipse UI which makes it unusable for JDT.LS <http://JDT.LS>
(recent thread [2] on the
> topic).
>
> - JDT developers should think of core/UI separation from the very
> beginning of the implementation of a new feature, instead of
> implementing things coupled to UI, and expect to later refactor
to JDT
> core.
>
> C) Project Rules
> Many project rules prevent contributions from people not deeply
involved
> in development of the Eclipse IDE, while the overall project’s
focus
> should be adjusting rules towards better community engagement.
For
> example: “mass changes” and refactorings being accepted only
for M1
> means that integrators have to wait 2 out of every 3 months for
the next
> opportunity to have changes merged. Furthermore, the development
period
> of the Eclipse release cycle falls twice per year during vacation
> periods (summer and Christmas), when many committers are not
around to
> review changes.
>
> D) Code Modernization
> In order to attract new contributors, we must make things
easier for
> newcomers to join. Changes that help newcomers not feel lost
in the
> codebase, regardless of their immediate technical benefit, must
be as
> important as changes that technically improve the project.
>
>
> We (the Eclipse team at Red Hat) would like to ask all of you JDT
> committers if we can count on you to work together with us on the
above
> changes to modernize the project for its continued success. We
> appreciate your answers and discussions of the above
recommendations.
> Every piece of this conversation will help us adjust our team’s
strategy
> around Java IDE tooling. It will also help guide our decisions
about
> what projects to invest in, which areas will be a pain-point
for our
> team, and whether better opportunities should be pursued.
>
>
> 1: https://github.com/eclipse-jdt/eclipse.jdt.core/pull/182
<https://github.com/eclipse-jdt/eclipse.jdt.core/pull/182>
>
> 2: https://www.eclipse.org/lists/jdt-dev/msg02169.html
<https://www.eclipse.org/lists/jdt-dev/msg02169.html>
>
>
> Sincerely,
>
>
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
<https://www.eclipse.org/mailman/listinfo/jdt-dev>
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/jdt-dev
