Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-dev] "clean up" again

A must watch for everyone that participated in the discussion: https://archive.fosdem.org/2013/schedule/event/challenges_libreoffice/ Even if you watched it already please do it again and think about the thread again.

On Mon, Jun 1, 2020 at 2:30 PM Manoj Palat <manoj.palat@xxxxxxxxxx> wrote:
+1 of course.

Regards,
Manoj

-----jdt-dev-bounces@xxxxxxxxxxx wrote: -----
To: jdt-dev@xxxxxxxxxxx
From: Stephan Herrmann
Sent by: jdt-dev-bounces@xxxxxxxxxxx
Date: 06/01/2020 03:07PM
Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again

+1 with one clarification (should be obvious):

as for every bug, also here it's the responsibility of the reporter to give
reason, why a proposed change is relevant.

Stephan

On 01.06.20 09:37, Sarika Sinha wrote:
>
> As a learning from this episode, let us vote for creation of bug as mandatory
> for all components in JDT - Core/Debug/UI/Docs/APT/Text.
> +1 (Implicit from me)
>
>
> Note: It hardly takes 20 seconds to create a bug and we all know the advantages.
>
>
> Thanks & Regards,
> Sarika
>
>
> -----jdt-dev-bounces@xxxxxxxxxxx <mailto:-----jdt-dev-bounces@xxxxxxxxxxx>
> wrote: -----
> To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx
> <mailto:jdt-dev@xxxxxxxxxxx>>
> From: "Manoj Palat"
> Sent by: jdt-dev-bounces@xxxxxxxxxxx <mailto:jdt-dev-bounces@xxxxxxxxxxx>
> Date: 06/01/2020 11:53AM
> Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again
>
> ---Snip from Stephan Herrmannn---
>  >From here I think that it's clear that every change in JDT should start with a
>  >bugzilla entry, and this entry should start with a problem description. If we
>  >don't agree on smth being a problem, then obviously there is no reason for a
>  >change. Without a reason there will be no code change in the master branch.
>
> Augmenting to what Stephan mentioned: From a previous discussion alongwith Lars,
> Stephan, and others a few months back we had
> agreed that for every cleanup in JDT Core there will be a bug, and based on the
> discussion, the bug will have a [cleanup] tag, only then we will proceed and
> also that these
> cleanups will be taken up only in M1. There will be a limit on the number of
> mass cleanups that goes in at a time as well
> and that the fixing of these cleanup bugs will not be counted for committer
> election. And these guidelines have been adhered to largely in
> JDT Core, thanks to all! I agree completely with Stephan on this and would think
> the rest of JDT (other
> than Core) will also be benefitted if we follow a bug-for-a-cleanup policy.
>
>
>  >This explicitly opens up for the case where some code section is beyond repair
>  >by normal means: If a certain code area is incomprehensible or does not allow a
>  >decent fix for a known bug, then this structure can be a problem in itself,
>  >worth cleaning up.
> We do have multiple examples here, for example, Mateusz Matela - He redesigned
> the formatter completely,
> and stayed on to fix and improve the same - and even now, after several years,
> he actively fixes and
> enhances the redesigned code - This was a "real code cleanup" or actually code
> transformation which made
> a significant improvement together with his continued and focused commitment.
> Till, another name Jay
> mentioned focused on specific parts of JDT and the cleanups if any proposed by
> these, would take into account
> the programmatic improvements as well as the effects/clients of their "owned"
> modules, and would turn out to
> be more "informed" decisions. That said, this isn't a blocker for mass cleanup,
> will continue to attend to mass cleanups
> as mentioned in the first paragraph.
>
> Thanks,
> Manoj.
>
> -----jdt-dev-bounces@xxxxxxxxxxx <mailto:-----jdt-dev-bounces@xxxxxxxxxxx>
> wrote: -----
> To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx
> <mailto:jdt-dev@xxxxxxxxxxx>>
> From: "Jayaprakash Arthanareeswaran"
> Sent by: jdt-dev-bounces@xxxxxxxxxxx <mailto:jdt-dev-bounces@xxxxxxxxxxx>
> Date: 06/01/2020 09:26AM
> Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again
>
>  >I do agree with internal API usages, even my self I have used
>  >internal APIs in a few of my plugins in Eclipse JDT. I'm not saying
>  >we should not do that, but we should have a process of promoting such
>  >most wanted internal APIs into external APIs to be more maintainable.
>  >And internal API users must have some CI jobs to make sure the
>  >upstream is breaking things for you. So we can raise those as soon as
>  >possible rather than waiting until an RC release. And for me, this is
>  >what Continuous Integration is about.
>
> The fact that JDT is still compiled with JavaSE 8 and that it still supports
> Java compliances all the way down to 1.1 is an example of what a widely
> used project like JDT has to deal with. We, just like everyone, would like to
> shed few lines of code, drop support for older versions etc. But then, that is not
> what reality is and it will be nice if people take away this point from those
> dealing with it for years. Remember, these are the same people that
> have to rush to fix when things get broken by a mass change.
>
>  >Maybe you in JDT have a different approach in seeing quality,
>  >module design, and CI than what I used to, given the fact that you
>  >have lot of projects depending on you.
>
> Yes, JDT, especially jdt.core project has very different priorities for reasons
> that have been mentioned a few times already in this thread.
>
> I also wanted to highlight that we have had new committers coming in like
> Till, Mateusz etc. and I don't recall them requiring a clean-up work to get
> them fired. Yes, not everyone uses same methods, but at the end of the day,
> when cons outweigh pros, then we need to rethink our priorities.
>
> Regards,
> Jay
>
> -----jdt-dev-bounces@xxxxxxxxxxx <mailto:-----jdt-dev-bounces@xxxxxxxxxxx>
> wrote: -----
>
>  >To: "Eclipse JDT general developers list." <jdt-dev@xxxxxxxxxxx
> <mailto:jdt-dev@xxxxxxxxxxx>>
>  >From: Gayan Perera
>  >Sent by: jdt-dev-bounces@xxxxxxxxxxx <mailto:jdt-dev-bounces@xxxxxxxxxxx>
>  >Date: 05/31/2020 02:19PM
>  >Subject: [EXTERNAL] Re: [jdt-dev] "clean up" again
>  >
>  >I see that my last post had few raise eyebrows.
>  >
>  >I do agree with internal API usages, even my self I have used
>  >internal APIs in a few of my plugins in Eclipse JDT. I'm not saying
>  >we should not do that, but we should have a process of promoting such
>  >most wanted internal APIs into external APIs to be more maintainable.
>  >And internal API users must have some CI jobs to make sure the
>  >upstream is breaking things for you. So we can raise those as soon as
>  >possible rather than waiting until an RC release. And for me, this is
>  >what Continuous Integration is about.
>  >
>  >Maybe you in JDT have a different approach in seeing quality,
>  >module design, and CI than what I used to, given the fact that you
>  >have lot of projects depending on you.
>  >
>  >Maybe no point of raising the same thing again and again,
>  >just wasting all of our time.y
>  >
>  >Br,
>  >Gayan.
>  >On Sun, May 31, 2020 at 6:27 AM Ed Merks <ed.merks@xxxxxxxxx
> <mailto:ed.merks@xxxxxxxxx>> wrote:
>  >Stephan,
>  >
>  > Speaking as an adopter, EMF has 32 uses of org.eclipse.jdt.internal
>  >in
>  > the code base.  As such, sensitivity to adopters is very much
>  > appreciated.  I know API rights activists will cry out about API
>  > violations and argue their inviolate right to make arbitrary changes
>  >
>  > because, well, they are within their rights of course.  It seems one
>  >
>  > can't reasonably argue against such things because rights are always
>  >
>  > right.  But reality is subtle and complex, with shades or gray
>  >ruling
>  > the day.
>  >
>  > I can well imagine there are good reason why Object Teams is
>  > incestuously intertwined with JDT, so from a hundred paces away, to
>  > critique its design based purely on superficial, ideological dogma,
>  >with
>  > no actual deep understanding of that design, leaves a bad smell.
>  >Let's
>  > not do that.  Balance and respect and more important than rights and
>  >
>  > rules and there are few more deserving of respect than Stephan.
>  >
>  > Regards,
>  > Ed
>  >
>  > On 30.05.2020 14:16, Stephan Herrmann wrote:
>  > > Vetos, for sure, should be used sparingly and carefully.
>  > >
>  > > Yet, as part of their responsibility, committers need a way to
>  >reject
>  > > changes, which they assess as having negative impact on the
>  >project.
>  > >
>  > > When I wrote "For compiler tests, however, I would veto any such
>  > > change" I said so in full confidence that the active committers
>  >will
>  > > agree.
>  > >
>  > >
>  > > Regarding Object Teams, once more: this is a side issue (other
>  >than
>  > > the fact that without Object Teams I would never have started
>  > > contributing to JDT), and few people on this list have sufficient
>  > > insights into that project to seriously discuss its architecture.
>  >We
>  > > could just drop this, but I still believe there is an aspect that
>  >goes
>  > > far beyond Object Teams:
>  > >
>  > > JDT is used by *many* adopters. Putting aside all design rules and
>  >
>  > > ideology, it's a fact of life that some of them use internals of
>  >JDT,
>  > > have perhaps been doing so for a very long time. We are not going
>  >to
>  > > re-write other projects' history. On the contrary, as a courtesy
>  >to
>  > > our adopters (who are an important part of the eco system!) we
>  >should
>  > > minimize changes that are likely to cause grief and pain
>  >downstream.
>  > > By "minimize" I mean: be a bit more conservative than usual,
>  >perform
>  > > only those changes that are "necessary" in one way or other. Just
>  > > raise the bar for approval.
>  > >
>  > > BTW: we have several deleted methods brought back after adopters
>  >have
>  > > explained their problems with a change in JDT. Some of this looks
>  > > quite odd and violates a number of rules, but if it helps adopters
>  >it
>  > > helps the eco system, which is more important :)
>  > >
>  > > best,
>  > > Stephan
>  > >
>  > > On 30.05.20 10:41, Gayan Perera wrote:
>  > >> I think this was a good discussion. But i think we need to have
>  >mix
>  > >> of people when doing veto. Other wise things will never move
>  >forward
>  > >> if we are stuck with the same group who thinks in the same way.
>  > >>
>  > >> I know stephan will not agree with me. But i think object teams
>  >have
>  > >> great technical debt from what i read in this thread. A product
>  > >> should no depend on tests of another product. Moving tests from
>  >one
>  > >> junit 3 to junit4 should not impact heavily. Use test fixtures
>  > >> instead of depending raw test classes. Look at how IntelliJ
>  >platform
>  > >> has done it for plugin developers.
>  > >>
>  > >> Rather than simply depending on a test plugin and writing your
>  >tests
>  > >> on it. Its always good to have APIs which are not bounded to
>  >certain
>  > >> implementation details on test frameworks.
>  > >>
>  > >> By the way cleaning up whitespace issues and cleaning up code
>  > >> formatting in a single commit as a bulk task, I don’t understand
>  >the
>  > >> what the big issue that stephan tries to highlight.
>  > >>
>  > >> Finally if you depend on non API classes then be prepared to get
>  > >> breaking changes. It shouldn’t matter how big the product is that
>  >
>  > >> depend on non API classes.
>  > >>
>  > >> Br,
>  > >> Gayan
>  > >>
>  > >> On Fri, 29 May 2020 at 18:50, <stephan.herrmann@xxxxxxxxx
> <mailto:stephan.herrmann@xxxxxxxxx>
>  > >> <mailto:stephan.herrmann@xxxxxxxxx>> wrote:
>  > >>
>  > >>     Thanks for answers here and others.
>  > >>
>  > >>     I feel we can agree that the JUnit3 -> 4 conversion is
>  >different
>  > >> from other
>  > >>     mass changes:
>  > >>
>  > >>     * This change is done with close consideration of each
>  >individual
>  > >> case
>  > >>     rather than mechanically applying some scheme over unseen
>  >amounts
>  > >> of code.
>  > >>     * I see a tangible benefit (during development / for
>  >reporting
>  > >> etc.), with
>  > >>     just few comments:
>  > >>         - In JDT I never saw anything nearly as bad as what Alex
>  > >> linked (from
>  > >>     team.cvs)
>  > >>         - Once a new contributor realizes that he has issues with
>  >a
>  > >> new test
>  > >>     method not being picked up, this should be the kind of
>  >question
>  > >> that should
>  > >>     get a helpful hint from others in very short time. For simple
>  >
>  > >> questions like
>  > >>     this feel free to ping even in short intervals.
>  > >>         - This JUnit migration causes significant follow-up work
>  >in
>  > >> Object
>  > >>     Teams, but I was happy to get helpful explanations from
>  >Carsten
>  > >> and thus I
>  > >>     did not complain about this.
>  > >>     * Test code is just a tiny little bit less critical than main
>  >
>  > >> code. This
>  > >>     concerns cleanliness of the git history as well as bugs
>  > >> introduced by mass
>  > >>     changes (= only indirectly affecting users, while still
>  >affecting
>  > >> adopters).
>  > >>
>  > >>     I think in JDT/UI this particular activity is still ongoing,
>  >and
>  > >> I don't
>  > >>     object to its completion (I have no idea about the percentage
>  >
>  > >> completed?). I
>  > >>     hope other committers can agree, too?
>  > >>
>  > >>     For compiler tests, however, I would veto any such change.
>  >I'm a
>  > >> bit less
>  > >>     decided about other tests in JDT/Core or JDT/Debug, but I
>  >feel
>  > >> terminating
>  > >>     this activity when JDT/UI is done is a fair compromise, OK?
>  > >>
>  > >>
>  > >>     Regarding save actions, I second what Jonah said. Actually I
>  > >> think it was a
>  > >>     bug to enable any save actions that are not in sync with the
>  > >> existing code.
>  > >>
>  > >>
>  > >>     I hope with this we can tick off two items from the list as
>  >being
>  > >> not quite
>  > >>     as controversial as some may have felt.
>  > >>     Stephan
>  > >>
>  > >>
>  > >>     Am 2020-05-28 15:52, schrieb Pyves .:
>  > >>
>  > >>>     I've contributed a few patches to JDT Core and UI in the
>  >past
>  > >>> couple of
>  > >>>     years, so I'm guessing I fit in the "new contributors"
>  >category
>  > >>> and may be
>  > >>>     able to provide some insight.
>  > >>>     My first contribution was fixing bug 424214 and I faced two
>  > >>> problems
>  > >>>     related to this discussion:
>  > >>>     * I struggled to write new unit tests. At the time, I had
>  >never
>  > >>> used JUnit
>  > >>>     3 (which is understandable given that JUnit 4 was released
>  >early
>  > >>> 2006). I
>  > >>>     was probably trying to write a test method with a different
>  >naming
>  > >>>     convention and it wasn't being picked up by the framework -
>  >no
>  > >>> longer sure
>  > >>>     at this point. And as JUnit 3 was not a thing I had used, I
>  > >>> didn't even
>  > >>>     realise it was JUnit 3 (in my mind it was some bespoke
>  >Eclipse test
>  > >>>     utility running) and consequently I couldn't easily look up
>  >any
>  > >>>     documentation to solve my problems. In the end, I ended up
>  > >>> putting the
>  > >>>     tests in an existing file and copy-pasted as much possible,
>  >not
>  > >>> really
>  > >>>     understanding how things fitted together. For anyone who has
>  >
>  > >>> started
>  > >>>     writing Java in the past decade or so, these mass migrations
>  >to
>  > >>> JUnit 4,
>  > >>>     even though they touch a lot of files and introduce commit
>  > >>> noise, are useful.
>  > >>>     * I struggled to get the contribution under 1000 lines to
>  >avoid
>  > >>> the CQ.
>  > >>>     The files I changed had not been cleaned up nor touched in
>  >years,
>  > >>>     therefore some of the automatic save actions had introduced
>  > >>> additional
>  > >>>     diffs, for example import ordering. With Till Brichy's help
>  >I
>  > >>> then had to
>  > >>>     revert some of these automatic changes, just for the sake of
>  >
>  > >>> getting under
>  > >>>     the 1000 line limit in time for the M3 deadline. Note that
>  >this
>  > >>> was my
>  > >>>     very first usage of Gerrit, so reverting lines and pushing
>  >new
>  > >>> patch sets
>  > >>>     was not as straightforward for me as it would be now.
>  >"Fighting"
>  > >>> against
>  > >>>     save actions would not have been needed had the files been
>  > >>> cleaned up
>  > >>>     prior to my contribution.
>  > >>>     Admittedly, these are only two small inconveniences which
>  >some
>  > >>> of you may
>  > >>>     even consider as anecdotal, but hopefully they do illustrate
>  >
>  > >>> cases where
>  > >>>     mass cleanups can help newcomers. :)
>  > >>>     Best regards,
>  > >>>     Pierre-Yves
>  > >>>
>  > >>>     Le jeu. 28 mai 2020 à 15:08, Aleksandar Kurtakov
>  > >>> <akurtako@xxxxxxxxxx <mailto:akurtako@xxxxxxxxxx>
>  > >>>     <mailto:akurtako@xxxxxxxxxx>> a écrit :
>  > >>>
>  > >>>
>  > >>>         On Thu, May 28, 2020 at 3:07 PM Stephan Herrmann
>  > >>>         <stephan.herrmann@xxxxxxxxx <mailto:stephan.herrmann@xxxxxxxxx>
>  > >>> <mailto:stephan.herrmann@xxxxxxxxx>> wrote:
>  > >>>
>  > >>>             On 28.05.20 13:20, Aleksandar Kurtakov wrote:
>  > >>>             > On Thu, May 28, 2020 at 1:55 PM S A
>  > >>>             <simeon.danailov.andreev@xxxxxxxxx
> <mailto:simeon.danailov.andreev@xxxxxxxxx>
>  > >>>             <mailto:simeon.danailov.andreev@xxxxxxxxx>
>  > >>>             > <mailto:simeon.danailov.andreev@xxxxxxxxx
>  > >>> <mailto:simeon.danailov.andreev@xxxxxxxxx>>> wrote:
>  > >>>              > [...]
>  > >>>             >     I can't make a comment on attracting other
>  > >>> contributors in JDT.
>  > >>>             >
>  > >>>             >
>  > >>>             > That I can comment :).
>  > >>>
>  > >>>             Are you speaking from your own experience of working
>  >on
>  > >>> JDT code
>  > >>>             (as a new
>  > >>>             contributor), or are these words you put into the
>  >mouths of
>  > >>>             others? I'd
>  > >>>             appreciate if they speak for themselves.
>  > >>>
>  > >>>         I speak as the tech lead for Jeff and Roland  and
>  > >>> discussions on a
>  > >>>         weekly basis what/how/when/why to do so we can share the
>  >
>  > >>> burden in JDT
>  > >>>         with others. Being the one that have pushed for people
>  >to
>  > >>> work on JDT
>  > >>>         and the one that has followed up most of the late
>  >additions
>  > >>> to the
>  > >>>         team and specifically organizing the team work so JDT
>  >team and
>  > >>>         community can grow - yes I do speak from my own
>  >experience
>  > >>> and would
>  > >>>         dare to even say that have a broader view of the project
>  >not
>  > >>> worse
>  > >>>         than many committers.
>  > >>>         I haven't worked on JDT code itself a lot (releng fixes
>  >after
>  > >>>         incomplete fixes in JDT and -Werror addition) but I
>  >would
>  > >>> dare to say
>  > >>>         that non-trivial part of the work in the last few
>  >releases
>  > >>> has been
>  > >>>         requested by/approved by/checked by/etc. by me
>  >personally incl.
>  > >>>         freeing time for people to work on JDT and further .
>  > >>>
>  > >>>
>  > >>>             I'm willing to learn from our new contributors. It's
>  >
>  > >>> among the
>  > >>>             committers that
>  > >>>             we have to find a mode of operation that facilitates
>  >
>  > >>> collaboration
>  > >>>             and avoids
>  > >>>             stepping on each others' toes. It seems this mode
>  >has
>  > >>> not yet been
>  > >>>             found.
>  > >>>
>  > >>>              > P.S. Only whoever hasn't looked at unreadable
>  >JUnit3
>  > >>> test
>  > >>>             suites results [...]
>  > >>>
>  > >>>             I'm looking at such results [1] all the time and I
>  >see
>  > >>> no problem.
>  > >>>             Do you care
>  > >>>             to be more specific?
>  > >>>
>  > >>>
>  >https://download.eclipse.org/eclipse/downloads/drops4/R-4.15-20200305
>  >0155/testresults/html/org.eclipse.team.tests.cvs.core_ep415I-unit-win
>  >32-java8_win32.win32.x86_64_8.0.html
>  > >>>         - go even figure which test triggered the failing setup.
>  >You
>  > >>> want see
>  > >>>         it in later builds cause these specific tests have been
>  > >>> disabled and
>  > >>>         other such has been updated to JUnit4 - doing it
>  >regularly
>  > >>> when my
>  > >>>         daily look at test results spots such thing.
>  > >>>
>  > >>>
>  > >>>             Stephan
>  > >>>
>  > >>>             [1]
>  > >>>
>  >https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Gerrit/lastStableBuil
>  >d/testReport/
>  > >>>             _______________________________________________
>  > >>>             jdt-dev mailing list
>  > >>> jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> <mailto:jdt-dev@xxxxxxxxxxx>
>  > >>>             To unsubscribe from this list, visit
>  > >>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>  > >>>
>  > >>>
>  > >>>
>  > >>>         --         Alexander Kurtakov
>  > >>>         Red Hat Eclipse Team
>  > >>>         _______________________________________________
>  > >>>         jdt-dev mailing list
>  > >>> jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> <mailto:jdt-dev@xxxxxxxxxxx>
>  > >>>         To unsubscribe from this list, visit
>  > >>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>  > >>>
>  > >>>
>  > >>>     _______________________________________________
>  > >>>     jdt-dev mailing list
>  > >>> jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> <mailto:jdt-dev@xxxxxxxxxxx>
>  > >>>     To unsubscribe from this list, visit
>  > >>> https://www.eclipse.org/mailman/listinfo/jdt-dev
>  > >>
>  > >>
>  > >>     _______________________________________________
>  > >>     jdt-dev mailing list
>  > >> jdt-dev@xxxxxxxxxxx <mailto:jdt-dev@xxxxxxxxxxx> <mailto:jdt-dev@xxxxxxxxxxx>
>  > >>     To unsubscribe from this list, visit
>  > >> https://www.eclipse.org/mailman/listinfo/jdt-dev
>  > >>
>  > >>
>  > >> _______________________________________________
>  > >> 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
>  > >>
>  > >
>  > > _______________________________________________
>  > > 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
>  > _______________________________________________
>  > 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
>  > _______________________________________________
>  >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
>  >
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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
>
>
> _______________________________________________
> 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


--
Alexander Kurtakov
Red Hat Eclipse Team

Back to the top