[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jdt-dev] Red Hat's Future Java Tooling Plans and JDT
|
Thanks. That does sound promising and much needed...
On 15.11.2022 08:13, Aleksandar
Kurtakov wrote:
I wonder what is the
expected impact on the very large community
downstream of JDT? Just in SimRel I see ~250 bundles
downstream from
jdt.core and that's just a small sample size...
Positive. Having a vibrant community that is able to keep
up with new Java versions and make JDT better suited for
more use cases while following the current deprecation
policy or adjust that and have a decent notification period
for other cases.
After all, the same style changes in Platform is what
allowed us to still release something downstreams can build
on top of.
It's definitely not the "eternal compatibility" policy
downstreams were used to but the alternative is not better
IMHO.
On 15.11.2022 06:44, Christoph Läubrich wrote:
> > 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
>
> I agree (if it counts for anything) on the overall
direction :-)
>
> Am 14.11.22 um 20:50 schrieb Aleksandar Kurtakov:
>>
>>
>> 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
> _______________________________________________
> jdt-dev mailing list
> jdt-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jdt-dev
_______________________________________________
jdt-dev mailing list
jdt-dev@xxxxxxxxxxx
To unsubscribe from this list, visit 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