From neugens at redhat.com  Tue Sep  3 15:53:04 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 3 Sep 2019 17:53:04 +0200
Subject: Moving to GitHub (project Skara)
In-Reply-To: <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>
References: <02c101d55f1f$acc20900$06461b00$@hirt.se>
 <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>
Message-ID: <f0a55efd-b438-7e4b-f55f-c4352e5a9c28@redhat.com>

On 30/08/2019 13:43, Klara Ward wrote:
> +1 for GitHub

I'm a bit skeptical to be honest, we should first define what the new
process will be before buying the new and shiny.

For instance, it's my understanding that we want to get rid of webrevs
and only use github pull requests, however that would put us in a
situation where jmc is different from the other openjdk projects. Emails
also give us a great overview of what the project is doing, I'm afraid
github will hide most of this making more difficult to reconstruct the
history and evolution of the project.

Of course, I do like some aspect, for a reviewer a pull request is
probably a great way to know a review is necessary, so I don't want to
just rule out this move entirely.

>From my team the consensus was that before moving to github we should
have a very clearly defined process and stick with it.

I would personally add that it would be best to not be among the early
adopters, and rather follow what the rest of the openjdk projects do, in
particular openjdk itself, since we have such a close dependency on it
and we are citizens of the same organisation.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From marcus.hirt at datadoghq.com  Tue Sep  3 16:16:16 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 3 Sep 2019 18:16:16 +0200
Subject: Moving to GitHub (project Skara)
In-Reply-To: <f0a55efd-b438-7e4b-f55f-c4352e5a9c28@redhat.com>
References: <02c101d55f1f$acc20900$06461b00$@hirt.se>
 <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>
 <f0a55efd-b438-7e4b-f55f-c4352e5a9c28@redhat.com>
Message-ID: <CAOpWGx1rT6MrZQfiBKsfLtkUyWYkV9ZjOPAdhabUQTc1OvQ6WA@mail.gmail.com>

Sure. Tuning the process as we go will certainly be possible and
likely necessary. That said, we should, of course, discuss the initial
settings to avoid as much later grief as possible.

These are some of the things I am considering for the process:
1. Reviews are required. One reviewer or two committers.
2. A bug ID will be required for each change (let's discuss if you are
of a different opinion).
3. Notifications for pushed commits will be sent to jmc-dev.
4. Pull requests will be mirrored to jmc-dev.

Kind regards,
Marcus

On Tue, Sep 3, 2019 at 5:53 PM Mario Torre <neugens at redhat.com> wrote:
>
> On 30/08/2019 13:43, Klara Ward wrote:
> > +1 for GitHub
>
> I'm a bit skeptical to be honest, we should first define what the new
> process will be before buying the new and shiny.
>
> For instance, it's my understanding that we want to get rid of webrevs
> and only use github pull requests, however that would put us in a
> situation where jmc is different from the other openjdk projects. Emails
> also give us a great overview of what the project is doing, I'm afraid
> github will hide most of this making more difficult to reconstruct the
> history and evolution of the project.
>
> Of course, I do like some aspect, for a reviewer a pull request is
> probably a great way to know a review is necessary, so I don't want to
> just rule out this move entirely.
>
> From my team the consensus was that before moving to github we should
> have a very clearly defined process and stick with it.
>
> I would personally add that it would be best to not be among the early
> adopters, and rather follow what the rest of the openjdk projects do, in
> particular openjdk itself, since we have such a close dependency on it
> and we are citizens of the same organisation.
>
> Cheers,
> Mario
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From almacdon at redhat.com  Tue Sep  3 18:56:40 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Tue, 3 Sep 2019 14:56:40 -0400
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAEBeOco2f89wiR6dCp60pEiYArOPRZ_1TFQkoP907QKend3r0g@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
 <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
 <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>
 <CAEBeOcq3rXNRWCqTxfje2CcD9wvwXAXUH6p=LyYvaOPPQUi9RA@mail.gmail.com>
 <CAEBeOco2f89wiR6dCp60pEiYArOPRZ_1TFQkoP907QKend3r0g@mail.gmail.com>
Message-ID: <CAOsn=kr1WeN64Xqkb=bOedaN3VJ+Q32gSe9dKdemOZOe6WgXaQ@mail.gmail.com>

On Wed, Aug 28, 2019 at 11:36 AM Jie Kang <jkang at redhat.com> wrote:

> On Wed, Aug 28, 2019 at 10:46 AM Jie Kang <jkang at redhat.com> wrote:
> >
> > Hi all,
> >
> > Carmine has requested I continue this work in his stead. Please find
> > an updated webrev for review below.
> >
> > Webrev: http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.00/
> > Bug: https://bugs.openjdk.java.net/browse/JMC-5473
>
> Ah; I had a mistake in the previous webrev (the TableViewer was no
> longer set), please find an updated one below. Apologies for the
> mistake.
>
> http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.01/
>
>
>
Looks good - the functionality works as it should and the uitests are
passing on both my Linux & Windows machines.

There is an unused import that can be cleaned up at:

ResultTableUi.java
- unused import GridData @ line 50

And my only other nit is that the test is placed in
"org.openjdk.jmc.flightrecorder.uitest.overview" which would be a new
package that would only have this test inside of it. It doesn't test (yet
at least) the entire Automated Analysis page so maybe it doesn't fit under
"[..].flightrecorder.uitest.pages", but maybe it belongs under
[..].flightrecorder.uitest alongside the other tests? Just a thought.


> Regards,
>
> >
> >
> > Regards
> >
> >
> >
> > On Thu, Aug 1, 2019 at 10:24 AM Carmine Vincenzo Russo
> > <carusso at redhat.com> wrote:
> > >
> > > Hi Jie,
> > >
> > > Thanks for pointing out these errors, I'll fix them and get back with
> an updated version.
> > >
> > > Thanks,
> > > Carmine
> > >
> > > On Thu, Aug 1, 2019 at 4:16 PM Jie Kang <jkang at redhat.com> wrote:
> > >>
> > >> On Thu, Aug 1, 2019 at 6:53 AM Carmine Vincenzo Russo
> > >> <carusso at redhat.com> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > The attached patch addresses the issue JMC-5473[0] in which a search
> > >> > feature for the Automated Analysis Result Table was lacking.
> > >> >
> > >> > In ResultOverview.java, I added the text component and a simple
> layout to
> > >> > give the page more consistency when the table is displayed.
> > >> > I also produced ResultOverviewTest.java to test if the table has
> > >> > components, the search feature operates, and two more to check if
> the
> > >> > behaviour is what we expect with a nonsense search and a specific
> search.
> > >> >
> > >> > A side note, since there were no tests for the Automated Analysis
> Result, I
> > >> > had to add the tab in JfrUi and allow the record analysis in two
> other
> > >> > classes, OldRecordingsVerificationTest.java and
> JfrRecordingTest.java,
> > >> > because they go through all the tabs listed in JfrUi during their
> tests.
> > >> >
> > >> > How does it look?
> > >>
> > >> Hi Carmine,
> > >>
> > >> Thanks for doing this; the tests are appreciated! I have some issues
> > >> to address below:
> > >>
> > >> diff --git
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/R
> > >> esultOverview.java
> > >>
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/ov
> > >> erview/ResultOverview.java
> > >> ---
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
> > >> erview.java
> > >> +++
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
> > >> erview.java
> > >> [...]
> > >> -
> > >> +
> > >>
> > >> * Whitespace additions like the example shown above should be removed;
> > >> there are others in the patch.
> > >>
> > >> -                       Map<Result, DataPageDescriptor> map =
> createResultMap();
> > >> +                       GridLayout layout = new GridLayout(1, true);
> > >> +                       this.form.getBody().setLayout(layout);
> > >> +                       text = new Text(form.getBody(), SWT.BORDER |
> > >> SWT.HORIZONTAL | SWT.SEARCH | SWT.RESIZE);
> > >> +                       text.setLayoutData(new GridData(SWT.FILL,
> > >> SWT.DEFAULT, true, false));
> > >> +
>  text.setMessage(Messages.ResultOverview_SEARCH_TABLE);
> > >> +
>  text.setToolTipText(Messages.ResultOverview_SEARCH_BAR);
> > >> +                       Map<Result, DataPageDescriptor> map =
> > >> createResultMap(text.getText());
> > >>                         table = new ResultTableUi(form, toolkit,
> > >> editor, loadedState, map);
> > >> +                       ModifyListener listener = new
> ModifyListener() {
> > >> +                               @Override
> > >> +                               public void modifyText(ModifyEvent e)
> {
> > >> +                                       Map<Result,
> > >> DataPageDescriptor> map = createResultMap(text.getText());
> > >> +                                       table.updateInput(map);
> > >> +                               }
> > >> +                       };
> > >> +                       text.addModifyListener(listener);
> > >>                 }
> > >> * The additions to the Table UI done above should occur in the Table
> > >> UI code, rather than in the overview which is managing the HTML UI and
> > >> the Table UI, ie. the above should be within ResultTableUi.java
> > >>
> > >> * When switching to the Table and then back to the HTML, the resulting
> > >> view is strange; see the linked image [1]. This may have to do with
> > >> how the form's layout is modified by your addition. This form is the
> > >> parent for the ResultTableUi. I would add children to it with custom
> > >> layouts, but I would not modify the 'parent' layout itself.
> > >>
> > >> https://imgur.com/a/nS1m2T2
> > >>
> > >>
> > >> Regards,
> > >>
> > >> >
> > >> > Regards,
> > >> > Carmine
> > >> >
> > >> > [0] https://bugs.openjdk.java.net/browse/JMC-5473
> > >> >
> > >> > --
> > >> > Carmine Vincenzo Russo
> > >
> > >
> > >
> > > --
> > > Carmine Vincenzo Russo
>

From kxu at redhat.com  Tue Sep  3 19:03:29 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Tue, 3 Sep 2019 15:03:29 -0400
Subject: [PATCH] JMC-655: Fix typos in Spotbugs exclude
Message-ID: <CA+tA26un+cmWgFFmcTpJbt4YWv=pA=G7pcnxK3-K8=ONq2NLjQ@mail.gmail.com>

Hello all,

Please review this trivial patch addressing JMC-6569: Fix typos in
Spotbugs exclude. [0]

This issue was discovered in the review process [1] of JMC-6555 [2].
Also, due to conflicting changes, my patch for JMC-6555 will base on
top this once it's pushed.

Kangcheng Xu

[0] https://bugs.openjdk.java.net/browse/JMC-6559
[1] https://mail.openjdk.java.net/pipermail/jmc-dev/2019-August/001358.html
[2] https://bugs.openjdk.java.net/browse/JMC-6555
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmc-6559.patch
Type: text/x-patch
Size: 3005 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20190903/6bdc769e/jmc-6559-0001.patch>

From jkang at redhat.com  Wed Sep  4 15:11:05 2019
From: jkang at redhat.com (Jie Kang)
Date: Wed, 4 Sep 2019 11:11:05 -0400
Subject: [PATCH] JMC-655: Fix typos in Spotbugs exclude
In-Reply-To: <CA+tA26un+cmWgFFmcTpJbt4YWv=pA=G7pcnxK3-K8=ONq2NLjQ@mail.gmail.com>
References: <CA+tA26un+cmWgFFmcTpJbt4YWv=pA=G7pcnxK3-K8=ONq2NLjQ@mail.gmail.com>
Message-ID: <CAEBeOcqp7meKLx18WTDKfV_x3KTQPd8_uBqCxnwbNc3hSGxJgQ@mail.gmail.com>

On Tue, Sep 3, 2019 at 3:04 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> Hello all,
>
> Please review this trivial patch addressing JMC-6569: Fix typos in
> Spotbugs exclude. [0]
>
> This issue was discovered in the review process [1] of JMC-6555 [2].
> Also, due to conflicting changes, my patch for JMC-6555 will base on
> top this once it's pushed.

There are a few whitespace additions to the updated comment that can
be removed and s/they are not remote command/they are not remote
commands/

Apart from these nits it works for me and the rule additions look okay.


Regards,

>
> Kangcheng Xu
>
> [0] https://bugs.openjdk.java.net/browse/JMC-6559
> [1] https://mail.openjdk.java.net/pipermail/jmc-dev/2019-August/001358.html
> [2] https://bugs.openjdk.java.net/browse/JMC-6555

From guru.hb at oracle.com  Wed Sep  4 15:23:34 2019
From: guru.hb at oracle.com (Guru)
Date: Wed, 4 Sep 2019 20:53:34 +0530
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update site
 landing page
Message-ID: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>

Hi,

Please review the fix for 
JBS : https://bugs.openjdk.java.net/browse/JMC-6561 <https://bugs.openjdk.java.net/browse/JMC-6561>
webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.0/> 

Root cause : JMC 7.0.0 is compiled and shipped with Eclipse 4.11 (2019-03 as default profile) where as update sites landing page still refers to Eclipse 4.7 and above as Prerequisite. 
Solution : Updated Eclipse version from 4.7 to 4.8 in the Prerequisite description in the landing page. 

Note: This fix will be applicable to jmc7 repo only (i.e. for Jmc 7.0.0 release). 

Thanks,
Guru

From marcus.hirt at datadoghq.com  Wed Sep  4 15:51:09 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Wed, 4 Sep 2019 17:51:09 +0200
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
Message-ID: <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>

Hi Guru,

The idea with having multiple platforms in the pom is that we'd like
to be able to support not only the latest version of the platform. I
don't think this change is necessary.

Kind regards,
Marcus

On Wed, Sep 4, 2019 at 5:24 PM Guru <guru.hb at oracle.com> wrote:
>
> Hi,
>
> Please review the fix for
> JBS : https://bugs.openjdk.java.net/browse/JMC-6561 <https://bugs.openjdk.java.net/browse/JMC-6561>
> webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.0/>
>
> Root cause : JMC 7.0.0 is compiled and shipped with Eclipse 4.11 (2019-03 as default profile) where as update sites landing page still refers to Eclipse 4.7 and above as Prerequisite.
> Solution : Updated Eclipse version from 4.7 to 4.8 in the Prerequisite description in the landing page.
>
> Note: This fix will be applicable to jmc7 repo only (i.e. for Jmc 7.0.0 release).
>
> Thanks,
> Guru

From guru.hb at oracle.com  Wed Sep  4 17:51:28 2019
From: guru.hb at oracle.com (Guru)
Date: Wed, 4 Sep 2019 23:21:28 +0530
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
Message-ID: <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>

Thanks Marcus, 

Please check my comments inline. 

-Guru
> On 04-Sep-2019, at 9:21 PM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> 
> Hi Guru,
> 
> The idea with having multiple platforms in the pom is that we'd like
> to be able to support not only the latest version of the platform. I
> don't think this change is necessary.
My Intent to keep Eclipse 4.11 in update site landing page is : 
1. Base Eclipse SDK version which is used for building JMC product (also the update sites, when its shipped) and tested.
2. To minimise the support or bug filed against the plugins which are not tested at the source. (I would partially agree here, as its mainly depends many factor and majorly due to a. Eclipse Backword compatibility, b. Resource or community response for the bugs encountered in the lower version of Eclipse IDE). 

If this is not justifialbe for above two condition, then I would consider Pre-requisite to Eclipse 4.8 as current jmc7 repo has target definition starting from Eclipse 4.8 (Photon) and above. 
> 
> Kind regards,
> Marcus
> 
> On Wed, Sep 4, 2019 at 5:24 PM Guru <guru.hb at oracle.com> wrote:
>> 
>> Hi,
>> 
>> Please review the fix for
>> JBS : https://bugs.openjdk.java.net/browse/JMC-6561 <https://bugs.openjdk.java.net/browse/JMC-6561>
>> webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.0/>
>> 
>> Root cause : JMC 7.0.0 is compiled and shipped with Eclipse 4.11 (2019-03 as default profile) where as update sites landing page still refers to Eclipse 4.7 and above as Prerequisite.
>> Solution : Updated Eclipse version from 4.7 to 4.8 in the Prerequisite description in the landing page.
>> 
>> Note: This fix will be applicable to jmc7 repo only (i.e. for Jmc 7.0.0 release).
>> 
>> Thanks,
>> Guru


From kxu at redhat.com  Wed Sep  4 19:48:15 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Wed, 4 Sep 2019 15:48:15 -0400
Subject: [PATCH] JMC-655: Fix typos in Spotbugs exclude
In-Reply-To: <CAEBeOcqp7meKLx18WTDKfV_x3KTQPd8_uBqCxnwbNc3hSGxJgQ@mail.gmail.com>
References: <CA+tA26un+cmWgFFmcTpJbt4YWv=pA=G7pcnxK3-K8=ONq2NLjQ@mail.gmail.com>
 <CAEBeOcqp7meKLx18WTDKfV_x3KTQPd8_uBqCxnwbNc3hSGxJgQ@mail.gmail.com>
Message-ID: <CA+tA26vy7DmkZnD6dSVTwo0WJ76x7tzHDwahJyqFrcoozYbn9g@mail.gmail.com>

On Wed, 4 Sep 2019 at 11:11, Jie Kang <jkang at redhat.com> wrote:
>
> On Tue, Sep 3, 2019 at 3:04 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> >
> > Hello all,
> >
> > Please review this trivial patch addressing JMC-6569: Fix typos in
> > Spotbugs exclude. [0]
> >
> > This issue was discovered in the review process [1] of JMC-6555 [2].
> > Also, due to conflicting changes, my patch for JMC-6555 will base on
> > top this once it's pushed.
>
> There are a few whitespace additions to the updated comment that can
> be removed and s/they are not remote command/they are not remote
> commands/

The attached is updated to remove whitespaces and correct my grammar.

Regards,

> Apart from these nits it works for me and the rule additions look okay.
>
>
> Regards,
>
> >
> > Kangcheng Xu
> >
> > [0] https://bugs.openjdk.java.net/browse/JMC-6559
> > [1] https://mail.openjdk.java.net/pipermail/jmc-dev/2019-August/001358.html
> > [2] https://bugs.openjdk.java.net/browse/JMC-6555
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jmc-6559.1.patch
Type: text/x-patch
Size: 3005 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/jmc-dev/attachments/20190904/b9770b66/jmc-6559.1.patch>

From marcus.hirt at datadoghq.com  Thu Sep  5 09:19:12 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Thu, 5 Sep 2019 11:19:12 +0200
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
 <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
Message-ID: <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>

Yes, we should definitely change to 4.8 for sure. Requiring 4.11 would
be over-constraining in my opinion, but Datadog is not actively
shipping binary builds, so Oracle's (and Red Hat's, Azul's and
Bell-Soft's) opinion weigh heavier here. Any thoughts from Red Hat,
Azul and/or Bell-Soft?

Kind regards,
Marcus

On Wed, Sep 4, 2019 at 7:51 PM Guru <guru.hb at oracle.com> wrote:
>
> Thanks Marcus,
>
> Please check my comments inline.
>
> -Guru
> > On 04-Sep-2019, at 9:21 PM, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> >
> > Hi Guru,
> >
> > The idea with having multiple platforms in the pom is that we'd like
> > to be able to support not only the latest version of the platform. I
> > don't think this change is necessary.
> My Intent to keep Eclipse 4.11 in update site landing page is :
> 1. Base Eclipse SDK version which is used for building JMC product (also the update sites, when its shipped) and tested.
> 2. To minimise the support or bug filed against the plugins which are not tested at the source. (I would partially agree here, as its mainly depends many factor and majorly due to a. Eclipse Backword compatibility, b. Resource or community response for the bugs encountered in the lower version of Eclipse IDE).
>
> If this is not justifialbe for above two condition, then I would consider Pre-requisite to Eclipse 4.8 as current jmc7 repo has target definition starting from Eclipse 4.8 (Photon) and above.
> >
> > Kind regards,
> > Marcus
> >
> > On Wed, Sep 4, 2019 at 5:24 PM Guru <guru.hb at oracle.com> wrote:
> >>
> >> Hi,
> >>
> >> Please review the fix for
> >> JBS : https://bugs.openjdk.java.net/browse/JMC-6561 <https://bugs.openjdk.java.net/browse/JMC-6561>
> >> webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.0/ <http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.0/>
> >>
> >> Root cause : JMC 7.0.0 is compiled and shipped with Eclipse 4.11 (2019-03 as default profile) where as update sites landing page still refers to Eclipse 4.7 and above as Prerequisite.
> >> Solution : Updated Eclipse version from 4.7 to 4.8 in the Prerequisite description in the landing page.
> >>
> >> Note: This fix will be applicable to jmc7 repo only (i.e. for Jmc 7.0.0 release).
> >>
> >> Thanks,
> >> Guru
>

From neugens at redhat.com  Thu Sep  5 14:51:30 2019
From: neugens at redhat.com (Mario Torre)
Date: Thu, 5 Sep 2019 16:51:30 +0200
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
 <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
 <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>
Message-ID: <CAJwKKma-dsyVNSc3SmGjJqf+-FRsp5KpVNKmw4WZjx11hA2SGA@mail.gmail.com>

On Thu, Sep 5, 2019 at 11:20 AM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>
> Yes, we should definitely change to 4.8 for sure. Requiring 4.11 would
> be over-constraining in my opinion, but Datadog is not actively
> shipping binary builds, so Oracle's (and Red Hat's, Azul's and
> Bell-Soft's) opinion weigh heavier here. Any thoughts from Red Hat,
> Azul and/or Bell-Soft?

I would like to be more conservative as the fast release cadence of
Eclipse is a nightmare for packaging on Linux, a lower baseline is a
lot more forgiving, especially on the current version, however I think
4.8 should be fine for the moment.

Jie should know more about the exact versioning as he did the
packaging for Fedora and RHEL and may give some better feedback, he is
away for a few days however, he will be back after Oracle Code One.

Cheers,
Mario
-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From patrick at reini.net  Thu Sep  5 18:37:03 2019
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 5 Sep 2019 20:37:03 +0200
Subject: RFR: JMC-6564 Adding release repository definition
Message-ID: <77C56243-3009-4E56-B5DF-929427E6DDB6@reini.net>

In order to have a proper POM file for deploying a release I added the according repository section to the distribution management.

- Patrick

diff -r 3482d4ee8db5 pom.xml
--- a/pom.xml	Tue Aug 27 10:51:54 2019 -0400
+++ b/pom.xml	Thu Sep 05 20:33:25 2019 +0200
@@ -96,6 +96,10 @@
 		<connection>${scmConnection}</connection>
 	</scm>
 	<distributionManagement>
+		<repository>
+			<id>jmc-publish-snapshot</id>
+			<url>${release.repo}</url>
+		</repository>



From marcus at hirt.se  Thu Sep  5 18:40:19 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Thu, 5 Sep 2019 20:40:19 +0200
Subject: Sv: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <CAJwKKma-dsyVNSc3SmGjJqf+-FRsp5KpVNKmw4WZjx11hA2SGA@mail.gmail.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
 <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
 <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>
 <CAJwKKma-dsyVNSc3SmGjJqf+-FRsp5KpVNKmw4WZjx11hA2SGA@mail.gmail.com>
Message-ID: <003c01d56419$5e212c50$1a6384f0$@hirt.se>

Hi Guru,

Would changing to 4.8 be okay for you?

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Mario Torre
Skickat: den 5 september 2019 16:52
Till: Marcus Hirt <marcus.hirt at datadoghq.com>
Kopia: jmc-dev at openjdk.java.net
?mne: Re: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update site landing page

On Thu, Sep 5, 2019 at 11:20 AM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>
> Yes, we should definitely change to 4.8 for sure. Requiring 4.11 would 
> be over-constraining in my opinion, but Datadog is not actively 
> shipping binary builds, so Oracle's (and Red Hat's, Azul's and
> Bell-Soft's) opinion weigh heavier here. Any thoughts from Red Hat, 
> Azul and/or Bell-Soft?

I would like to be more conservative as the fast release cadence of Eclipse is a nightmare for packaging on Linux, a lower baseline is a lot more forgiving, especially on the current version, however I think
4.8 should be fine for the moment.

Jie should know more about the exact versioning as he did the packaging for Fedora and RHEL and may give some better feedback, he is away for a few days however, he will be back after Oracle Code One.

Cheers,
Mario
--
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From patrick at reini.net  Thu Sep  5 19:10:00 2019
From: patrick at reini.net (Patrick Reinhart)
Date: Thu, 5 Sep 2019 21:10:00 +0200
Subject: RFR: JMC-6564 Adding release repository definition
In-Reply-To: <77C56243-3009-4E56-B5DF-929427E6DDB6@reini.net>
References: <77C56243-3009-4E56-B5DF-929427E6DDB6@reini.net>
Message-ID: <E2CBD71F-ADA4-405F-B968-1258D2C584C4@reini.net>

Correcting myself?

diff -r 3482d4ee8db5 pom.xml
--- a/pom.xml	Tue Aug 27 10:51:54 2019 -0400
+++ b/pom.xml	Thu Sep 05 20:33:25 2019 +0200
@@ -96,6 +96,10 @@
		<connection>${scmConnection}</connection>
	</scm>
	<distributionManagement>
+		<repository>
+			<id>jmc-publish</id>
+			<url>${release.repo}</url>
+		</repository>


> Am 05.09.2019 um 20:37 schrieb Patrick Reinhart <patrick at reini.net>:
> 
> In order to have a proper POM file for deploying a release I added the according repository section to the distribution management.
> 
> - Patrick
> 
> diff -r 3482d4ee8db5 pom.xml
> --- a/pom.xml	Tue Aug 27 10:51:54 2019 -0400
> +++ b/pom.xml	Thu Sep 05 20:33:25 2019 +0200
> @@ -96,6 +96,10 @@
> 		<connection>${scmConnection}</connection>
> 	</scm>
> 	<distributionManagement>
> +		<repository>
> +			<id>jmc-publish-snapshot</id>
> +			<url>${release.repo}</url>
> +		</repository>
> 
> 


From marcus at hirt.se  Thu Sep  5 19:13:25 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Thu, 5 Sep 2019 21:13:25 +0200
Subject: Sv: RFR: JMC-6564 Adding release repository definition
In-Reply-To: <E2CBD71F-ADA4-405F-B968-1258D2C584C4@reini.net>
References: <77C56243-3009-4E56-B5DF-929427E6DDB6@reini.net>
 <E2CBD71F-ADA4-405F-B968-1258D2C584C4@reini.net>
Message-ID: <006b01d5641d$fe24ee40$fa6ecac0$@hirt.se>

Looks good to me!

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Patrick Reinhart
Skickat: den 5 september 2019 21:10
Till: jmc-dev at openjdk.java.net
?mne: Re: RFR: JMC-6564 Adding release repository definition

Correcting myself?

diff -r 3482d4ee8db5 pom.xml
--- a/pom.xml	Tue Aug 27 10:51:54 2019 -0400
+++ b/pom.xml	Thu Sep 05 20:33:25 2019 +0200
@@ -96,6 +96,10 @@
		<connection>${scmConnection}</connection>
	</scm>
	<distributionManagement>
+		<repository>
+			<id>jmc-publish</id>
+			<url>${release.repo}</url>
+		</repository>


> Am 05.09.2019 um 20:37 schrieb Patrick Reinhart <patrick at reini.net>:
> 
> In order to have a proper POM file for deploying a release I added the according repository section to the distribution management.
> 
> - Patrick
> 
> diff -r 3482d4ee8db5 pom.xml
> --- a/pom.xml	Tue Aug 27 10:51:54 2019 -0400
> +++ b/pom.xml	Thu Sep 05 20:33:25 2019 +0200
> @@ -96,6 +96,10 @@
> 		<connection>${scmConnection}</connection>
> 	</scm>
> 	<distributionManagement>
> +		<repository>
> +			<id>jmc-publish-snapshot</id>
> +			<url>${release.repo}</url>
> +		</repository>
> 
> 



From marcus at hirt.se  Thu Sep  5 19:18:24 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Thu, 05 Sep 2019 19:18:24 +0000
Subject: hg: jmc/jmc: JMC-6564: Add distribution management section for
 release versions
Message-ID: <201909051918.x85JIOcl019389@aojmv0008.oracle.com>

Changeset: 751cae255f84
Author:    hirt <marcus at hirt.se>
Date:      2019-09-05 21:18 +0200
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/751cae255f84

JMC-6564: Add distribution management section for release versions
Reviewed-by: hirt
Contributed-by: reinhapa

! pom.xml


From neugens at redhat.com  Fri Sep  6 11:07:52 2019
From: neugens at redhat.com (Mario Torre)
Date: Fri, 6 Sep 2019 13:07:52 +0200
Subject: Moving to GitHub (project Skara)
In-Reply-To: <CAOpWGx1rT6MrZQfiBKsfLtkUyWYkV9ZjOPAdhabUQTc1OvQ6WA@mail.gmail.com>
References: <02c101d55f1f$acc20900$06461b00$@hirt.se>
 <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>
 <f0a55efd-b438-7e4b-f55f-c4352e5a9c28@redhat.com>
 <CAOpWGx1rT6MrZQfiBKsfLtkUyWYkV9ZjOPAdhabUQTc1OvQ6WA@mail.gmail.com>
Message-ID: <81532e04-47e9-fe93-8eb4-5c9871454c88@redhat.com>

On 03/09/2019 18:16, Marcus Hirt wrote:
> Sure. Tuning the process as we go will certainly be possible and
> likely necessary. That said, we should, of course, discuss the initial
> settings to avoid as much later grief as possible.
> 
> These are some of the things I am considering for the process:
> 1. Reviews are required. One reviewer or two committers.
> 2. A bug ID will be required for each change (let's discuss if you are
> of a different opinion).
> 3. Notifications for pushed commits will be sent to jmc-dev.
> 4. Pull requests will be mirrored to jmc-dev.

I think #4 is where I'm a bit worried. While I think it makes sense for
people to use the usual github workflow if they want to, one key point
of project Skara was the promise that we didn't have to think about it.

For JMC that may not be so important, but it will be paramount for
OpenJDK, so we should play the same game with the same rules.

I fear the enforcement to create forks and branches for each and every
commit may be overkill, especially when you already work on four or five
different project versions at the same time, and currently github
doesn't allow to simply clone, create a patch and send it to list for
discussion, it forces you to use the browser interface with a multi-step
approach where you first fork, then patch, then commit and then manually
go over github to create the pull request. It's overkill.

So before we commit to this, I need to fully understand to what extent
the workflow will change from the current one.

Again, I'm well aware that JMC may adapt more easily given the overall
linearity of the project, but the reason why we would be early adopters
is to test and try out skara for OpenJDK, so we need to be sure our work
will translate to a smoother experience for OpenJDK as for JMC.

Cheers,
Mario

> Kind regards,
> Marcus
> 
> On Tue, Sep 3, 2019 at 5:53 PM Mario Torre <neugens at redhat.com> wrote:
>>
>> On 30/08/2019 13:43, Klara Ward wrote:
>>> +1 for GitHub
>>
>> I'm a bit skeptical to be honest, we should first define what the new
>> process will be before buying the new and shiny.
>>
>> For instance, it's my understanding that we want to get rid of webrevs
>> and only use github pull requests, however that would put us in a
>> situation where jmc is different from the other openjdk projects. Emails
>> also give us a great overview of what the project is doing, I'm afraid
>> github will hide most of this making more difficult to reconstruct the
>> history and evolution of the project.
>>
>> Of course, I do like some aspect, for a reviewer a pull request is
>> probably a great way to know a review is necessary, so I don't want to
>> just rule out this move entirely.
>>
>> From my team the consensus was that before moving to github we should
>> have a very clearly defined process and stick with it.
>>
>> I would personally add that it would be best to not be among the early
>> adopters, and rather follow what the rest of the openjdk projects do, in
>> particular openjdk itself, since we have such a close dependency on it
>> and we are citizens of the same organisation.
>>
>> Cheers,
>> Mario
>>
>> --
>> Mario Torre
>> Associate Manager, Software Engineering
>> Red Hat GmbH <https://www.redhat.com>
>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From marcus.hirt at datadoghq.com  Fri Sep  6 12:56:48 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 6 Sep 2019 14:56:48 +0200
Subject: Moving to GitHub (project Skara)
In-Reply-To: <81532e04-47e9-fe93-8eb4-5c9871454c88@redhat.com>
References: <02c101d55f1f$acc20900$06461b00$@hirt.se>
 <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>
 <f0a55efd-b438-7e4b-f55f-c4352e5a9c28@redhat.com>
 <CAOpWGx1rT6MrZQfiBKsfLtkUyWYkV9ZjOPAdhabUQTc1OvQ6WA@mail.gmail.com>
 <81532e04-47e9-fe93-8eb4-5c9871454c88@redhat.com>
Message-ID: <CAOpWGx2oaziU_nm-vDaZY_2Rq5_Ee4rJ7ZV9qQVL+DCA=VgNXQ@mail.gmail.com>

Hi Mario,

The normal way to do this is to have one fork that you work in, for
all your PRs. Branching is a very quick operation, and anyone involved
in open source projects on GitHub will already know this workflow
intimately. IMHO it's rather easy and painless, and comes with a lot
of advantages. For JMC, the move would mean that the need for setting
up a webrev script, generating the webrev, rsyncing it to a folder
(with versioning done by folder name) goes away. The need to then
compose a properly formatted e-mail, link to the webrev and then send
it out to the mailing list goes away.

Other advantages include using an environment known to most developers
out there - an environment not requiring any OpenJDK special scripts
or workflows (easy on-boarding of new developers), contributors
getting recognition where it matters (many companies/recruiters go
look at GitHub commit history), starting using git (hg tool support is
starting to wane) etc. Also, awesomely enough, the project can start
using GitHub integrations like CI infrastructure to have tests run
before allowing to merge etc.

Kind regards,
Marcus

On Fri, Sep 6, 2019 at 1:07 PM Mario Torre <neugens at redhat.com> wrote:
>
> On 03/09/2019 18:16, Marcus Hirt wrote:
> > Sure. Tuning the process as we go will certainly be possible and
> > likely necessary. That said, we should, of course, discuss the initial
> > settings to avoid as much later grief as possible.
> >
> > These are some of the things I am considering for the process:
> > 1. Reviews are required. One reviewer or two committers.
> > 2. A bug ID will be required for each change (let's discuss if you are
> > of a different opinion).
> > 3. Notifications for pushed commits will be sent to jmc-dev.
> > 4. Pull requests will be mirrored to jmc-dev.
>
> I think #4 is where I'm a bit worried. While I think it makes sense for
> people to use the usual github workflow if they want to, one key point
> of project Skara was the promise that we didn't have to think about it.
>
> For JMC that may not be so important, but it will be paramount for
> OpenJDK, so we should play the same game with the same rules.
>
> I fear the enforcement to create forks and branches for each and every
> commit may be overkill, especially when you already work on four or five
> different project versions at the same time, and currently github
> doesn't allow to simply clone, create a patch and send it to list for
> discussion, it forces you to use the browser interface with a multi-step
> approach where you first fork, then patch, then commit and then manually
> go over github to create the pull request. It's overkill.
>
> So before we commit to this, I need to fully understand to what extent
> the workflow will change from the current one.
>
> Again, I'm well aware that JMC may adapt more easily given the overall
> linearity of the project, but the reason why we would be early adopters
> is to test and try out skara for OpenJDK, so we need to be sure our work
> will translate to a smoother experience for OpenJDK as for JMC.
>
> Cheers,
> Mario
>
> > Kind regards,
> > Marcus
> >
> > On Tue, Sep 3, 2019 at 5:53 PM Mario Torre <neugens at redhat.com> wrote:
> >>
> >> On 30/08/2019 13:43, Klara Ward wrote:
> >>> +1 for GitHub
> >>
> >> I'm a bit skeptical to be honest, we should first define what the new
> >> process will be before buying the new and shiny.
> >>
> >> For instance, it's my understanding that we want to get rid of webrevs
> >> and only use github pull requests, however that would put us in a
> >> situation where jmc is different from the other openjdk projects. Emails
> >> also give us a great overview of what the project is doing, I'm afraid
> >> github will hide most of this making more difficult to reconstruct the
> >> history and evolution of the project.
> >>
> >> Of course, I do like some aspect, for a reviewer a pull request is
> >> probably a great way to know a review is necessary, so I don't want to
> >> just rule out this move entirely.
> >>
> >> From my team the consensus was that before moving to github we should
> >> have a very clearly defined process and stick with it.
> >>
> >> I would personally add that it would be best to not be among the early
> >> adopters, and rather follow what the rest of the openjdk projects do, in
> >> particular openjdk itself, since we have such a close dependency on it
> >> and we are citizens of the same organisation.
> >>
> >> Cheers,
> >> Mario
> >>
> >> --
> >> Mario Torre
> >> Associate Manager, Software Engineering
> >> Red Hat GmbH <https://www.redhat.com>
> >> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From neugens at redhat.com  Fri Sep  6 13:29:40 2019
From: neugens at redhat.com (Mario Torre)
Date: Fri, 6 Sep 2019 15:29:40 +0200
Subject: Moving to GitHub (project Skara)
In-Reply-To: <CAOpWGx2oaziU_nm-vDaZY_2Rq5_Ee4rJ7ZV9qQVL+DCA=VgNXQ@mail.gmail.com>
References: <02c101d55f1f$acc20900$06461b00$@hirt.se>
 <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>
 <f0a55efd-b438-7e4b-f55f-c4352e5a9c28@redhat.com>
 <CAOpWGx1rT6MrZQfiBKsfLtkUyWYkV9ZjOPAdhabUQTc1OvQ6WA@mail.gmail.com>
 <81532e04-47e9-fe93-8eb4-5c9871454c88@redhat.com>
 <CAOpWGx2oaziU_nm-vDaZY_2Rq5_Ee4rJ7ZV9qQVL+DCA=VgNXQ@mail.gmail.com>
Message-ID: <431bbe2c-2938-61f3-558b-7cb996281579@redhat.com>

On 06/09/2019 14:56, Marcus Hirt wrote:
> Hi Mario,
> 
> The normal way to do this is to have one fork that you work in, for
> all your PRs. Branching is a very quick operation, and anyone involved
> in open source projects on GitHub will already know this workflow
> intimately.

Branching may be quick, but maintaing a fork isn't simple. Also 80% of
the work we do is based on fixing short lived issues, the remaining 20%
involves significant work, that may already happen in a forked
repository. The difference here is between being forced the overhead of
maintaining a fork and the external steps of using the web interface to
submit and merge the work done on each forked repository, with the
occasional need to have one. It's fine to keep those as option for
people who want them, but we shouldn't be all forced to adapt.

I'm not very happy to change to the dictation of another tooling imposed
workflow to be honest.

> Other advantages include using an environment known to most developers
> out there - an environment not requiring any OpenJDK special scripts
> or workflows (easy on-boarding of new developers), contributors
> getting recognition where it matters (many companies/recruiters go
> look at GitHub commit history), starting using git (hg tool support is
> starting to wane) etc.

Well, except that we are already OpenJDK developers, so we already know
all the tooling and workflow. It's exactly why I resist the GitHub way,
it may be nice for some but not for all.

Maintaining versions of webrevs is indeed a problem, but the process of
creating them is trivial and can be done via command line from the same
location you do the coding work, i.e. I don't need to
clone/fork/merge/remember to merge with a different repository too/then
open the browser click around until I find the right place and create a
pull request. If you use rsync you don't even need to create versions,
just keep overriding the same location.

> Also, awesomely enough, the project can start
> using GitHub integrations like CI infrastructure to have tests run
> before allowing to merge etc.

We already have most of this infrastructure in place, so if anything we
would need to spend time and resources to adapt it.

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From guru.hb at oracle.com  Mon Sep  9 09:23:55 2019
From: guru.hb at oracle.com (Guru)
Date: Mon, 9 Sep 2019 14:53:55 +0530
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <003c01d56419$5e212c50$1a6384f0$@hirt.se>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
 <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
 <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>
 <CAJwKKma-dsyVNSc3SmGjJqf+-FRsp5KpVNKmw4WZjx11hA2SGA@mail.gmail.com>
 <003c01d56419$5e212c50$1a6384f0$@hirt.se>
Message-ID: <D5BDEC7A-AF08-4AE3-BC62-6C7F95D0165F@oracle.com>

Thank you Marcus & Mario,

Please find updated webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.1 <http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.1>

Thanks,
Guru
> On 06-Sep-2019, at 12:10 AM, Marcus Hirt <marcus at hirt.se> wrote:
> 
> Hi Guru,
> 
> Would changing to 4.8 be okay for you?
> 
> Kind regards,
> Marcus
> 
> -----Ursprungligt meddelande-----
> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Mario Torre
> Skickat: den 5 september 2019 16:52
> Till: Marcus Hirt <marcus.hirt at datadoghq.com>
> Kopia: jmc-dev at openjdk.java.net
> ?mne: Re: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update site landing page
> 
> On Thu, Sep 5, 2019 at 11:20 AM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>> 
>> Yes, we should definitely change to 4.8 for sure. Requiring 4.11 would 
>> be over-constraining in my opinion, but Datadog is not actively 
>> shipping binary builds, so Oracle's (and Red Hat's, Azul's and
>> Bell-Soft's) opinion weigh heavier here. Any thoughts from Red Hat, 
>> Azul and/or Bell-Soft?
> 
> I would like to be more conservative as the fast release cadence of Eclipse is a nightmare for packaging on Linux, a lower baseline is a lot more forgiving, especially on the current version, however I think
> 4.8 should be fine for the moment.
> 
> Jie should know more about the exact versioning as he did the packaging for Fedora and RHEL and may give some better feedback, he is away for a few days however, he will be back after Oracle Code One.
> 
> Cheers,
> Mario
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> 


From marcus.hirt at datadoghq.com  Mon Sep  9 10:07:43 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 9 Sep 2019 12:07:43 +0200
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <D5BDEC7A-AF08-4AE3-BC62-6C7F95D0165F@oracle.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
 <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
 <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>
 <CAJwKKma-dsyVNSc3SmGjJqf+-FRsp5KpVNKmw4WZjx11hA2SGA@mail.gmail.com>
 <003c01d56419$5e212c50$1a6384f0$@hirt.se>
 <D5BDEC7A-AF08-4AE3-BC62-6C7F95D0165F@oracle.com>
Message-ID: <CAOpWGx3O2NhTHbj5hEfF-O9yZOL0Zw4Ln93ak3pbBTWy6Cmj3Q@mail.gmail.com>

Looks good Guru!

Kind regards,
Marcus

On Mon, Sep 9, 2019 at 11:24 AM Guru <guru.hb at oracle.com> wrote:
>
> Thank you Marcus & Mario,
>
> Please find updated webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.1
>
> Thanks,
> Guru
>
> On 06-Sep-2019, at 12:10 AM, Marcus Hirt <marcus at hirt.se> wrote:
>
> Hi Guru,
>
> Would changing to 4.8 be okay for you?
>
> Kind regards,
> Marcus
>
> -----Ursprungligt meddelande-----
> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Mario Torre
> Skickat: den 5 september 2019 16:52
> Till: Marcus Hirt <marcus.hirt at datadoghq.com>
> Kopia: jmc-dev at openjdk.java.net
> ?mne: Re: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update site landing page
>
> On Thu, Sep 5, 2019 at 11:20 AM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>
>
> Yes, we should definitely change to 4.8 for sure. Requiring 4.11 would
> be over-constraining in my opinion, but Datadog is not actively
> shipping binary builds, so Oracle's (and Red Hat's, Azul's and
> Bell-Soft's) opinion weigh heavier here. Any thoughts from Red Hat,
> Azul and/or Bell-Soft?
>
>
> I would like to be more conservative as the fast release cadence of Eclipse is a nightmare for packaging on Linux, a lower baseline is a lot more forgiving, especially on the current version, however I think
> 4.8 should be fine for the moment.
>
> Jie should know more about the exact versioning as he did the packaging for Fedora and RHEL and may give some better feedback, he is away for a few days however, he will be back after Oracle Code One.
>
> Cheers,
> Mario
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>
>

From neugens at redhat.com  Mon Sep  9 10:17:52 2019
From: neugens at redhat.com (Mario Torre)
Date: Mon, 9 Sep 2019 12:17:52 +0200
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <CAOpWGx3O2NhTHbj5hEfF-O9yZOL0Zw4Ln93ak3pbBTWy6Cmj3Q@mail.gmail.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
 <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
 <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>
 <CAJwKKma-dsyVNSc3SmGjJqf+-FRsp5KpVNKmw4WZjx11hA2SGA@mail.gmail.com>
 <003c01d56419$5e212c50$1a6384f0$@hirt.se>
 <D5BDEC7A-AF08-4AE3-BC62-6C7F95D0165F@oracle.com>
 <CAOpWGx3O2NhTHbj5hEfF-O9yZOL0Zw4Ln93ak3pbBTWy6Cmj3Q@mail.gmail.com>
Message-ID: <CAJwKKma9fsg+QE2U3G7y49nvA1g2q-37Wy8rR8Nzg4sMcTiJDw@mail.gmail.com>

+1

Cheers,
Mario

On Mon, Sep 9, 2019 at 12:07 PM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>
> Looks good Guru!
>
> Kind regards,
> Marcus
>
> On Mon, Sep 9, 2019 at 11:24 AM Guru <guru.hb at oracle.com> wrote:
> >
> > Thank you Marcus & Mario,
> >
> > Please find updated webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.1
> >
> > Thanks,
> > Guru
> >
> > On 06-Sep-2019, at 12:10 AM, Marcus Hirt <marcus at hirt.se> wrote:
> >
> > Hi Guru,
> >
> > Would changing to 4.8 be okay for you?
> >
> > Kind regards,
> > Marcus
> >
> > -----Ursprungligt meddelande-----
> > Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Mario Torre
> > Skickat: den 5 september 2019 16:52
> > Till: Marcus Hirt <marcus.hirt at datadoghq.com>
> > Kopia: jmc-dev at openjdk.java.net
> > ?mne: Re: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update site landing page
> >
> > On Thu, Sep 5, 2019 at 11:20 AM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> >
> >
> > Yes, we should definitely change to 4.8 for sure. Requiring 4.11 would
> > be over-constraining in my opinion, but Datadog is not actively
> > shipping binary builds, so Oracle's (and Red Hat's, Azul's and
> > Bell-Soft's) opinion weigh heavier here. Any thoughts from Red Hat,
> > Azul and/or Bell-Soft?
> >
> >
> > I would like to be more conservative as the fast release cadence of Eclipse is a nightmare for packaging on Linux, a lower baseline is a lot more forgiving, especially on the current version, however I think
> > 4.8 should be fine for the moment.
> >
> > Jie should know more about the exact versioning as he did the packaging for Fedora and RHEL and may give some better feedback, he is away for a few days however, he will be back after Oracle Code One.
> >
> > Cheers,
> > Mario
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> >
> >



-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From marcus.hirt at datadoghq.com  Mon Sep  9 10:38:27 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 9 Sep 2019 12:38:27 +0200
Subject: Moving to GitHub (project Skara)
In-Reply-To: <431bbe2c-2938-61f3-558b-7cb996281579@redhat.com>
References: <02c101d55f1f$acc20900$06461b00$@hirt.se>
 <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>
 <f0a55efd-b438-7e4b-f55f-c4352e5a9c28@redhat.com>
 <CAOpWGx1rT6MrZQfiBKsfLtkUyWYkV9ZjOPAdhabUQTc1OvQ6WA@mail.gmail.com>
 <81532e04-47e9-fe93-8eb4-5c9871454c88@redhat.com>
 <CAOpWGx2oaziU_nm-vDaZY_2Rq5_Ee4rJ7ZV9qQVL+DCA=VgNXQ@mail.gmail.com>
 <431bbe2c-2938-61f3-558b-7cb996281579@redhat.com>
Message-ID: <CAOpWGx1Rs7Qwi8+vA_NyH55Wth5FuqwufetSvXz4u1owr84XGw@mail.gmail.com>

(Replying so that Erik, who just joined the mailing list, can easily
join the discussion thread.)

On Fri, Sep 6, 2019 at 3:29 PM Mario Torre <neugens at redhat.com> wrote:
>
> On 06/09/2019 14:56, Marcus Hirt wrote:
> > Hi Mario,
> >
> > The normal way to do this is to have one fork that you work in, for
> > all your PRs. Branching is a very quick operation, and anyone involved
> > in open source projects on GitHub will already know this workflow
> > intimately.
>
> Branching may be quick, but maintaing a fork isn't simple. Also 80% of
> the work we do is based on fixing short lived issues, the remaining 20%
> involves significant work, that may already happen in a forked
> repository. The difference here is between being forced the overhead of
> maintaining a fork and the external steps of using the web interface to
> submit and merge the work done on each forked repository, with the
> occasional need to have one. It's fine to keep those as option for
> people who want them, but we shouldn't be all forced to adapt.
>
> I'm not very happy to change to the dictation of another tooling imposed
> workflow to be honest.
>
> > Other advantages include using an environment known to most developers
> > out there - an environment not requiring any OpenJDK special scripts
> > or workflows (easy on-boarding of new developers), contributors
> > getting recognition where it matters (many companies/recruiters go
> > look at GitHub commit history), starting using git (hg tool support is
> > starting to wane) etc.
>
> Well, except that we are already OpenJDK developers, so we already know
> all the tooling and workflow. It's exactly why I resist the GitHub way,
> it may be nice for some but not for all.
>
> Maintaining versions of webrevs is indeed a problem, but the process of
> creating them is trivial and can be done via command line from the same
> location you do the coding work, i.e. I don't need to
> clone/fork/merge/remember to merge with a different repository too/then
> open the browser click around until I find the right place and create a
> pull request. If you use rsync you don't even need to create versions,
> just keep overriding the same location.
>
> > Also, awesomely enough, the project can start
> > using GitHub integrations like CI infrastructure to have tests run
> > before allowing to merge etc.
>
> We already have most of this infrastructure in place, so if anything we
> would need to spend time and resources to adapt it.
>
> Cheers,
> Mario
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From erik.helin at oracle.com  Mon Sep  9 12:28:15 2019
From: erik.helin at oracle.com (Erik Helin)
Date: Mon, 9 Sep 2019 14:28:15 +0200
Subject: Moving to GitHub (project Skara)
In-Reply-To: <CAOpWGx1Rs7Qwi8+vA_NyH55Wth5FuqwufetSvXz4u1owr84XGw@mail.gmail.com>
References: <02c101d55f1f$acc20900$06461b00$@hirt.se>
 <ca4d71d4-0e2e-99d5-6c8c-4a5fddb5a496@kth.se>
 <f0a55efd-b438-7e4b-f55f-c4352e5a9c28@redhat.com>
 <CAOpWGx1rT6MrZQfiBKsfLtkUyWYkV9ZjOPAdhabUQTc1OvQ6WA@mail.gmail.com>
 <81532e04-47e9-fe93-8eb4-5c9871454c88@redhat.com>
 <CAOpWGx2oaziU_nm-vDaZY_2Rq5_Ee4rJ7ZV9qQVL+DCA=VgNXQ@mail.gmail.com>
 <431bbe2c-2938-61f3-558b-7cb996281579@redhat.com>
 <CAOpWGx1Rs7Qwi8+vA_NyH55Wth5FuqwufetSvXz4u1owr84XGw@mail.gmail.com>
Message-ID: <f5c07676-3b13-fc9b-4291-2e8f808db28f@oracle.com>

On 9/9/19 12:38 PM, Marcus Hirt wrote:
> (Replying so that Erik, who just joined the mailing list, can easily
> join the discussion thread.)

Thanks Marcus, and thank you for inviting me to join this discussion. I 
have been following via the archives as I usually try to *not* get 
involved when projects' are discussing using Skara. Whether JMC should 
use Skara or not is the JMC project's decision and I don't want to sway 
that in any direction. That said, I'm happy to answer questions and/or 
clarify any concerns.

One thing I immediately realized following the discussion on jmc-dev is 
that I need to describe various workflows in much more detail on the 
Skara wiki [0].

> On Fri, Sep 6, 2019 at 3:29 PM Mario Torre <neugens at redhat.com> wrote:
>>
>> On 06/09/2019 14:56, Marcus Hirt wrote:
>>> Hi Mario,
>>>
>>> The normal way to do this is to have one fork that you work in, for
>>> all your PRs. Branching is a very quick operation, and anyone involved
>>> in open source projects on GitHub will already know this workflow
>>> intimately.
>>
>> Branching may be quick, but maintaing a fork isn't simple. Also 80% of
>> the work we do is based on fixing short lived issues, the remaining 20%
>> involves significant work, that may already happen in a forked
>> repository. The difference here is between being forced the overhead of
>> maintaining a fork and the external steps of using the web interface to
>> submit and merge the work done on each forked repository, with the
>> occasional need to have one. It's fine to keep those as option for
>> people who want them, but we shouldn't be all forced to adapt.
>>
>> I'm not very happy to change to the dictation of another tooling imposed
>> workflow to be honest.

Neither are we in project Skara, so it is our hope that we have managed 
to create a solution where you can pick a workflow that suits you. That 
said, and as I describe further below in this email, we could not come 
up with a workflow that was step-by-step identical to what we use today.

>>> Other advantages include using an environment known to most developers
>>> out there - an environment not requiring any OpenJDK special scripts
>>> or workflows (easy on-boarding of new developers), contributors
>>> getting recognition where it matters (many companies/recruiters go
>>> look at GitHub commit history), starting using git (hg tool support is
>>> starting to wane) etc.
>>
>> Well, except that we are already OpenJDK developers, so we already know
>> all the tooling and workflow. It's exactly why I resist the GitHub way,
>> it may be nice for some but not for all.

Yes, if an OpenJDK project makes any changes to its workflow, then that 
means change for those accustomed to the current workflow. What we have 
tried to do with Skara is to spend significant time investigating how we 
can:

1. Minimize the disruption of changing to another workflow,
2. Enable contributors to use multiple different workflows at the same
    time so that each contributor can use the workflow that suits him or
    her the best.

That said, changing to _a_ source code hosting provider (Skara supports 
multiple) will mean some slight changes for contributors that enjoy the 
current OpenJDK workflow, but I think (hope) we have managed to come up 
with something very similar. I have worked with OpenJDK for 7+ years now 
so hopefully I know something about our current practices :)

One obvious change will be the switch from Mercurial (hg) to Git. For 
those contributors wanting to stay with hg I'm happy report that hg-git 
[1] works just fine with both github.com and gitlab.com. I created the 
following small change 
https://github.com/edvbld/jmc/commit/73bd425a0f9782eaf683855c0a2169a9ba130233 
using:

$ hg clone git+ssh://github.com/edvbld/jmc
$ cd jmc
$ hg bookmark readme
$ vim README.md
$ hg commit -m 'Add information about hg-git'
$ hg push --bookmark readme

I will create a page on the Skara OpenJDK wiki describing how to set up 
Mercurial to work with a Git source code hosting provider. But yes, as 
you see, this still forces you to use bookmarks in hg (since hg-git maps 
hg bookmarks to git branches). You would also have to add a path (see 
`hg help paths`) "upstream" pointing to https://github.com/openjdk/jmc 
so that you from time to time can run `hg pull upstream` (this is 
basically all there is to keep your personal fork up to date). I also 
want to add here that we are eagerly awaiting feedback on how 
complicated/tricky contributors think the above is so that we can create 
some custom tooling to help ease the experience if necessary.

Please also note that all CLI tools developed as part of Skara supports 
hg just as well as git, we did this precisely for the contributors 
wanting to use hg-git (I'm about to send out the final parts of the 
patch enabling hg support today).

In a previous email you described not wanting to use the browser and 
this is something we care about as well. Skara has implemented extensive 
CLI tooling to allow pull requests to be created, approved and 
integrated from the command line. Continuing the above example, still 
using hg, you would execute:

$ hg pr create # will open your $EDITOR for writing the message

You can also list pull requests from the command-line:

$ hg pr list
66   Upgrade JUnit 5 to 5.5.1                        sormuras build,rfr
120  Escape quotes in shell code stored in gitconfig rose00 rfr

You can approve pull requests from the command-line:

$ hg pr approve 66

And finally you can integrate pull requests from the command-line:

$ hg pr integrate 120

All of the above of course uses the public API's of the source code 
hosting provider but none of the above forces you to use the source code 
hosting provider's web UI for interacting with the hosting provider. 
Think of the web UI as being "just another interface" to the source code 
hosting provider, many source code hosting providers have very extensive 
API's work with.

Finally, for commenting on pull requests we have bi-directional syncing 
of comments between the OpenJDK mailing lists and source code hosting 
providers. That means if someone creates a pull request then a 
corresponding RFR will be created. The RFR email will contain an 
automatically generated webrev, links to any JBS issues, direct links to 
the patch and instructions for fetching the changes for local review. We 
also wait to send out the RFR email until the pull request have passed 
jcheck so that reviewers don't waste time looking at patches that don't 
even pass jcheck. As a reviewer, if you have any comments and/or 
feedback, then you can just reply to the RFR email. I know that you, me 
and Marcus did run into some early bugs in the mailing list bridge, it 
has improved significantly since then and Robin is currently doing the 
final touches on version two of the mailing list bridge.

Please note however that you cannot directly send an RFR email like we 
do today, you need to create a pull request which will trigger the 
automatic generation of an RFR email. You must also formally approve a 
PR by using `hg pr approve` (or another tool interacting with the 
platform), just replying "Looks good" to an RFR email will not work. 
These are the steps I mentioned in the beginning of the email that 
differ from our current workflow.

This email is already long enough as it is, I will try to summarize it 
on the Skara wiki and I'm happy to provide more detailed information if 
you have any questions. I would also like to say that we would be happy 
to work with you and the JMC project to figure out what can be improved 
and how we can offer a workflow that is as similar to our current one as 
possible (for those that want to use exactly that workflow).

>> Maintaining versions of webrevs is indeed a problem, but the process of
>> creating them is trivial and can be done via command line from the same
>> location you do the coding work, i.e. I don't need to
>> clone/fork/merge/remember to merge with a different repository too/then
>> open the browser click around until I find the right place and create a
>> pull request. If you use rsync you don't even need to create versions,
>> just keep overriding the same location.

As a Reviewer in the JDK project I just want to chime in here that I do 
expect to get an incremental webrev if someone has updated their patch ;)

Thanks,
Erik

[0]: https://wiki.openjdk.java.net/display/skara#Skara-Workflows
[1]: https://bitbucket.org/durin42/hg-git/

>>> Also, awesomely enough, the project can start
>>> using GitHub integrations like CI infrastructure to have tests run
>>> before allowing to merge etc.
>>
>> We already have most of this infrastructure in place, so if anything we
>> would need to spend time and resources to adapt it.
>>
>> Cheers,
>> Mario
>>
>>
>> --
>> Mario Torre
>> Associate Manager, Software Engineering
>> Red Hat GmbH <https://www.redhat.com>
>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From guru.hb at oracle.com  Mon Sep  9 13:20:55 2019
From: guru.hb at oracle.com (guru.hb at oracle.com)
Date: Mon, 09 Sep 2019 13:20:55 +0000
Subject: hg: jmc/jmc7: JMC-6561: update Eclipse 4.8 in Prerequisites of update
 site landing page
Message-ID: <201909091320.x89DKuI9017880@aojmv0008.oracle.com>

Changeset: 27e863e9d82f
Author:    ghb <guru.hb at oracle.com>
Date:      2019-09-09 18:50 +0530
URL:       https://hg.openjdk.java.net/jmc/jmc7/rev/27e863e9d82f

JMC-6561: update Eclipse 4.8 in Prerequisites of update site landing page
Reviewed-by: hirt, neugens

! application/org.openjdk.jmc.updatesite.ide/src/main/resources/index.html
! application/org.openjdk.jmc.updatesite.ide/src/main/resources/update-site-instructions/index.html


From guru.hb at oracle.com  Mon Sep  9 13:22:01 2019
From: guru.hb at oracle.com (Guru)
Date: Mon, 9 Sep 2019 18:52:01 +0530
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <CAJwKKma9fsg+QE2U3G7y49nvA1g2q-37Wy8rR8Nzg4sMcTiJDw@mail.gmail.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
 <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
 <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>
 <CAJwKKma-dsyVNSc3SmGjJqf+-FRsp5KpVNKmw4WZjx11hA2SGA@mail.gmail.com>
 <003c01d56419$5e212c50$1a6384f0$@hirt.se>
 <D5BDEC7A-AF08-4AE3-BC62-6C7F95D0165F@oracle.com>
 <CAOpWGx3O2NhTHbj5hEfF-O9yZOL0Zw4Ln93ak3pbBTWy6Cmj3Q@mail.gmail.com>
 <CAJwKKma9fsg+QE2U3G7y49nvA1g2q-37Wy8rR8Nzg4sMcTiJDw@mail.gmail.com>
Message-ID: <927F7CB7-208D-4D3A-BF18-0100E8D75225@oracle.com>

Thanks and Please note : I have updated the Title of the bug containing Eclipse 4.8 (instead of 4.11) before pushing the changes to mercurial repo. 

Thanks,
Guru
> On 09-Sep-2019, at 3:47 PM, Mario Torre <neugens at redhat.com> wrote:
> 
> +1
> 
> Cheers,
> Mario
> 
> On Mon, Sep 9, 2019 at 12:07 PM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>> 
>> Looks good Guru!
>> 
>> Kind regards,
>> Marcus
>> 
>> On Mon, Sep 9, 2019 at 11:24 AM Guru <guru.hb at oracle.com> wrote:
>>> 
>>> Thank you Marcus & Mario,
>>> 
>>> Please find updated webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.1
>>> 
>>> Thanks,
>>> Guru
>>> 
>>> On 06-Sep-2019, at 12:10 AM, Marcus Hirt <marcus at hirt.se> wrote:
>>> 
>>> Hi Guru,
>>> 
>>> Would changing to 4.8 be okay for you?
>>> 
>>> Kind regards,
>>> Marcus
>>> 
>>> -----Ursprungligt meddelande-----
>>> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Mario Torre
>>> Skickat: den 5 september 2019 16:52
>>> Till: Marcus Hirt <marcus.hirt at datadoghq.com>
>>> Kopia: jmc-dev at openjdk.java.net
>>> ?mne: Re: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update site landing page
>>> 
>>> On Thu, Sep 5, 2019 at 11:20 AM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
>>> 
>>> 
>>> Yes, we should definitely change to 4.8 for sure. Requiring 4.11 would
>>> be over-constraining in my opinion, but Datadog is not actively
>>> shipping binary builds, so Oracle's (and Red Hat's, Azul's and
>>> Bell-Soft's) opinion weigh heavier here. Any thoughts from Red Hat,
>>> Azul and/or Bell-Soft?
>>> 
>>> 
>>> I would like to be more conservative as the fast release cadence of Eclipse is a nightmare for packaging on Linux, a lower baseline is a lot more forgiving, especially on the current version, however I think
>>> 4.8 should be fine for the moment.
>>> 
>>> Jie should know more about the exact versioning as he did the packaging for Fedora and RHEL and may give some better feedback, he is away for a few days however, he will be back after Oracle Code One.
>>> 
>>> Cheers,
>>> Mario
>>> --
>>> Mario Torre
>>> Associate Manager, Software Engineering
>>> Red Hat GmbH <https://www.redhat.com>
>>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>>> 
>>> 
> 
> 
> 
> -- 
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898


From marcus.hirt at datadoghq.com  Mon Sep  9 13:32:13 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Mon, 9 Sep 2019 15:32:13 +0200
Subject: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update
 site landing page
In-Reply-To: <927F7CB7-208D-4D3A-BF18-0100E8D75225@oracle.com>
References: <758B1926-0AE9-45FA-815A-D737F67662CB@oracle.com>
 <CAOpWGx34pnR-Lu=CbVX6r7=SqKinX2s928bzVe+kj6xUnn0VWw@mail.gmail.com>
 <CDD2C667-A958-49CF-B202-BEF5B5CFDBF4@oracle.com>
 <CAOpWGx0xMEUSsMfCgY2fqdxwhjwtY2=cFsK9x3t6yxg5Ty_bXA@mail.gmail.com>
 <CAJwKKma-dsyVNSc3SmGjJqf+-FRsp5KpVNKmw4WZjx11hA2SGA@mail.gmail.com>
 <003c01d56419$5e212c50$1a6384f0$@hirt.se>
 <D5BDEC7A-AF08-4AE3-BC62-6C7F95D0165F@oracle.com>
 <CAOpWGx3O2NhTHbj5hEfF-O9yZOL0Zw4Ln93ak3pbBTWy6Cmj3Q@mail.gmail.com>
 <CAJwKKma9fsg+QE2U3G7y49nvA1g2q-37Wy8rR8Nzg4sMcTiJDw@mail.gmail.com>
 <927F7CB7-208D-4D3A-BF18-0100E8D75225@oracle.com>
Message-ID: <CAOpWGx0eAN4me_bQXAVHm-AeaEnD_=wXuw6TjUWbZ2ZNsEPV3Q@mail.gmail.com>

Excellent. Thanks Guru!

/M

On Mon, Sep 9, 2019 at 3:22 PM Guru <guru.hb at oracle.com> wrote:
>
> Thanks and Please note : I have updated the Title of the bug containing Eclipse 4.8 (instead of 4.11) before pushing the changes to mercurial repo.
>
> Thanks,
> Guru
> > On 09-Sep-2019, at 3:47 PM, Mario Torre <neugens at redhat.com> wrote:
> >
> > +1
> >
> > Cheers,
> > Mario
> >
> > On Mon, Sep 9, 2019 at 12:07 PM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> >>
> >> Looks good Guru!
> >>
> >> Kind regards,
> >> Marcus
> >>
> >> On Mon, Sep 9, 2019 at 11:24 AM Guru <guru.hb at oracle.com> wrote:
> >>>
> >>> Thank you Marcus & Mario,
> >>>
> >>> Please find updated webrev : http://cr.openjdk.java.net/~ghb/JMC-6561/webrev.1
> >>>
> >>> Thanks,
> >>> Guru
> >>>
> >>> On 06-Sep-2019, at 12:10 AM, Marcus Hirt <marcus at hirt.se> wrote:
> >>>
> >>> Hi Guru,
> >>>
> >>> Would changing to 4.8 be okay for you?
> >>>
> >>> Kind regards,
> >>> Marcus
> >>>
> >>> -----Ursprungligt meddelande-----
> >>> Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Mario Torre
> >>> Skickat: den 5 september 2019 16:52
> >>> Till: Marcus Hirt <marcus.hirt at datadoghq.com>
> >>> Kopia: jmc-dev at openjdk.java.net
> >>> ?mne: Re: RFR: JMC-6561: update Eclipse 4.11 in Prerequisites of update site landing page
> >>>
> >>> On Thu, Sep 5, 2019 at 11:20 AM Marcus Hirt <marcus.hirt at datadoghq.com> wrote:
> >>>
> >>>
> >>> Yes, we should definitely change to 4.8 for sure. Requiring 4.11 would
> >>> be over-constraining in my opinion, but Datadog is not actively
> >>> shipping binary builds, so Oracle's (and Red Hat's, Azul's and
> >>> Bell-Soft's) opinion weigh heavier here. Any thoughts from Red Hat,
> >>> Azul and/or Bell-Soft?
> >>>
> >>>
> >>> I would like to be more conservative as the fast release cadence of Eclipse is a nightmare for packaging on Linux, a lower baseline is a lot more forgiving, especially on the current version, however I think
> >>> 4.8 should be fine for the moment.
> >>>
> >>> Jie should know more about the exact versioning as he did the packaging for Fedora and RHEL and may give some better feedback, he is away for a few days however, he will be back after Oracle Code One.
> >>>
> >>> Cheers,
> >>> Mario
> >>> --
> >>> Mario Torre
> >>> Associate Manager, Software Engineering
> >>> Red Hat GmbH <https://www.redhat.com>
> >>> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
> >>>
> >>>
> >
> >
> >
> > --
> > Mario Torre
> > Associate Manager, Software Engineering
> > Red Hat GmbH <https://www.redhat.com>
> > 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>

From marcus.hirt at datadoghq.com  Tue Sep 10 12:03:33 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 10 Sep 2019 14:03:33 +0200
Subject: Review request for JMC-6546: Fixing the update sites in JMC 7.1.0
Message-ID: <CAOpWGx30L5RLUiyosj6LZRLDEePEb6aWZMGafEDPFee58u5duQ@mail.gmail.com>

Hi all,

Please review this fix for making the update sites work in JMC 7.1.0:

Jira:   https://bugs.openjdk.java.net/browse/JMC-6546
diff:
diff -r 751cae255f84
application/org.openjdk.jmc.feature.flightrecorder/feature.xml
--- a/application/org.openjdk.jmc.feature.flightrecorder/feature.xml
 Thu Sep 05 21:18:12 2019 +0200
+++ b/application/org.openjdk.jmc.feature.flightrecorder/feature.xml
 Tue Sep 10 13:50:56 2019 +0200
@@ -129,4 +129,11 @@
          version="0.0.0"
          unpack="false"/>

-</feature>
\ No newline at end of file
+   <plugin
+         id="org.hdrhistogram.HdrHistogram"
+         download-size="0"
+         install-size="0"
+         version="0.0.0"
+         unpack="false"/>
+
+</feature>

Kind regards,
Marcus

From neugens at redhat.com  Tue Sep 10 15:21:36 2019
From: neugens at redhat.com (Mario Torre)
Date: Tue, 10 Sep 2019 17:21:36 +0200
Subject: [PATCH] JMC-655: Fix typos in Spotbugs exclude
In-Reply-To: <CA+tA26vy7DmkZnD6dSVTwo0WJ76x7tzHDwahJyqFrcoozYbn9g@mail.gmail.com>
References: <CA+tA26un+cmWgFFmcTpJbt4YWv=pA=G7pcnxK3-K8=ONq2NLjQ@mail.gmail.com>
 <CAEBeOcqp7meKLx18WTDKfV_x3KTQPd8_uBqCxnwbNc3hSGxJgQ@mail.gmail.com>
 <CA+tA26vy7DmkZnD6dSVTwo0WJ76x7tzHDwahJyqFrcoozYbn9g@mail.gmail.com>
Message-ID: <b25de32c-0a23-e519-2bbf-dda601a8f613@redhat.com>

On 04/09/2019 21:48, Arvin Kangcheng Xu wrote:
> On Wed, 4 Sep 2019 at 11:11, Jie Kang <jkang at redhat.com> wrote:
>>
>> On Tue, Sep 3, 2019 at 3:04 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>>>
>>> Hello all,
>>>
>>> Please review this trivial patch addressing JMC-6569: Fix typos in
>>> Spotbugs exclude. [0]
>>>
>>> This issue was discovered in the review process [1] of JMC-6555 [2].
>>> Also, due to conflicting changes, my patch for JMC-6555 will base on
>>> top this once it's pushed.
>>
>> There are a few whitespace additions to the updated comment that can
>> be removed and s/they are not remote command/they are not remote
>> commands/
> 
> The attached is updated to remove whitespaces and correct my grammar.

Looks good to me.

Cheers,
Mario


-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898

From jmatsuok at redhat.com  Tue Sep 10 15:44:48 2019
From: jmatsuok at redhat.com (Joshua Matsuoka)
Date: Tue, 10 Sep 2019 11:44:48 -0400
Subject: [PATCH] JMC-655: Fix typos in Spotbugs exclude
In-Reply-To: <CA+tA26vy7DmkZnD6dSVTwo0WJ76x7tzHDwahJyqFrcoozYbn9g@mail.gmail.com>
References: <CA+tA26un+cmWgFFmcTpJbt4YWv=pA=G7pcnxK3-K8=ONq2NLjQ@mail.gmail.com>
 <CAEBeOcqp7meKLx18WTDKfV_x3KTQPd8_uBqCxnwbNc3hSGxJgQ@mail.gmail.com>
 <CA+tA26vy7DmkZnD6dSVTwo0WJ76x7tzHDwahJyqFrcoozYbn9g@mail.gmail.com>
Message-ID: <CAGLrAXNQSpe=qa04uQJCOrbfJCFQLpnDRg1_3CoZFtntdqRKZA@mail.gmail.com>

Hi Arvin,

Looks good to me,

Cheers,

- Josh

On Wed, Sep 4, 2019 at 3:49 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:

> On Wed, 4 Sep 2019 at 11:11, Jie Kang <jkang at redhat.com> wrote:
> >
> > On Tue, Sep 3, 2019 at 3:04 PM Arvin Kangcheng Xu <kxu at redhat.com>
> wrote:
> > >
> > > Hello all,
> > >
> > > Please review this trivial patch addressing JMC-6569: Fix typos in
> > > Spotbugs exclude. [0]
> > >
> > > This issue was discovered in the review process [1] of JMC-6555 [2].
> > > Also, due to conflicting changes, my patch for JMC-6555 will base on
> > > top this once it's pushed.
> >
> > There are a few whitespace additions to the updated comment that can
> > be removed and s/they are not remote command/they are not remote
> > commands/
>
> The attached is updated to remove whitespaces and correct my grammar.
>
> Regards,
>
> > Apart from these nits it works for me and the rule additions look okay.
> >
> >
> > Regards,
> >
> > >
> > > Kangcheng Xu
> > >
> > > [0] https://bugs.openjdk.java.net/browse/JMC-6559
> > > [1]
> https://mail.openjdk.java.net/pipermail/jmc-dev/2019-August/001358.html
> > > [2] https://bugs.openjdk.java.net/browse/JMC-6555
>

From ebaron at redhat.com  Tue Sep 10 15:53:14 2019
From: ebaron at redhat.com (Elliott Baron)
Date: Tue, 10 Sep 2019 11:53:14 -0400
Subject: Review request for JMC-6546: Fixing the update sites in JMC 7.1.0
In-Reply-To: <CAOpWGx30L5RLUiyosj6LZRLDEePEb6aWZMGafEDPFee58u5duQ@mail.gmail.com>
References: <CAOpWGx30L5RLUiyosj6LZRLDEePEb6aWZMGafEDPFee58u5duQ@mail.gmail.com>
Message-ID: <86d3b468-25f9-f3e0-f7eb-bb9b343d93e7@redhat.com>

Hi Marcus,

On 2019-09-10 8:03 a.m., Marcus Hirt wrote:
> Hi all,
> 
> Please review this fix for making the update sites work in JMC 7.1.0:
> 
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6546
> diff:
> diff -r 751cae255f84
> application/org.openjdk.jmc.feature.flightrecorder/feature.xml
> --- a/application/org.openjdk.jmc.feature.flightrecorder/feature.xml
>   Thu Sep 05 21:18:12 2019 +0200
> +++ b/application/org.openjdk.jmc.feature.flightrecorder/feature.xml
>   Tue Sep 10 13:50:56 2019 +0200
> @@ -129,4 +129,11 @@
>            version="0.0.0"
>            unpack="false"/>
> 
> -</feature>
> \ No newline at end of file
> +   <plugin
> +         id="org.hdrhistogram.HdrHistogram"
> +         download-size="0"
> +         install-size="0"
> +         version="0.0.0"
> +         unpack="false"/>
> +
> +</feature>

I confirmed that the installation succeeds after this patch. Sorry for 
missing this in the first place.

Thanks,
Elliott

From jmatsuok at redhat.com  Tue Sep 10 17:08:03 2019
From: jmatsuok at redhat.com (jmatsuok at redhat.com)
Date: Tue, 10 Sep 2019 17:08:03 +0000
Subject: hg: jmc/jmc: JMC-6559: Fix typos in Spotbugs exclude
Message-ID: <201909101708.x8AH8354006659@aojmv0008.oracle.com>

Changeset: d4f900dad2a0
Author:    jmatsuoka <jmatsuok at redhat.com>
Date:      2019-09-10 13:07 -0400
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/d4f900dad2a0

JMC-6559: Fix typos in Spotbugs exclude
Summary: Correct typos and exclude false positives
Reviewed-by: jkang, neugens, jmatsuoka
Contributed-by: Kangcheng Xu <kxu at redhat.com>

! configuration/spotbugs/spotbugs-exclude.xml


From marcus.hirt at datadoghq.com  Tue Sep 10 17:23:26 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Tue, 10 Sep 2019 19:23:26 +0200
Subject: Review request for JMC-6546: Fixing the update sites in JMC 7.1.0
In-Reply-To: <86d3b468-25f9-f3e0-f7eb-bb9b343d93e7@redhat.com>
References: <CAOpWGx30L5RLUiyosj6LZRLDEePEb6aWZMGafEDPFee58u5duQ@mail.gmail.com>
 <86d3b468-25f9-f3e0-f7eb-bb9b343d93e7@redhat.com>
Message-ID: <CAOpWGx3AuZdDQcagVGK+uEPKtcnQcCHZRECdUnGS-Guu6Hi8xQ@mail.gmail.com>

Hi Elliott,

No problem. I should have seen this in the first place, not to mention
fixed it a long time ago.

Kind regards,
Marcus

On Tue, Sep 10, 2019 at 5:53 PM Elliott Baron <ebaron at redhat.com> wrote:
>
> Hi Marcus,
>
> On 2019-09-10 8:03 a.m., Marcus Hirt wrote:
> > Hi all,
> >
> > Please review this fix for making the update sites work in JMC 7.1.0:
> >
> > Jira:   https://bugs.openjdk.java.net/browse/JMC-6546
> > diff:
> > diff -r 751cae255f84
> > application/org.openjdk.jmc.feature.flightrecorder/feature.xml
> > --- a/application/org.openjdk.jmc.feature.flightrecorder/feature.xml
> >   Thu Sep 05 21:18:12 2019 +0200
> > +++ b/application/org.openjdk.jmc.feature.flightrecorder/feature.xml
> >   Tue Sep 10 13:50:56 2019 +0200
> > @@ -129,4 +129,11 @@
> >            version="0.0.0"
> >            unpack="false"/>
> >
> > -</feature>
> > \ No newline at end of file
> > +   <plugin
> > +         id="org.hdrhistogram.HdrHistogram"
> > +         download-size="0"
> > +         install-size="0"
> > +         version="0.0.0"
> > +         unpack="false"/>
> > +
> > +</feature>
>
> I confirmed that the installation succeeds after this patch. Sorry for
> missing this in the first place.
>
> Thanks,
> Elliott

From kxu at redhat.com  Tue Sep 10 20:01:58 2019
From: kxu at redhat.com (Arvin Kangcheng Xu)
Date: Tue, 10 Sep 2019 16:01:58 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CAEBeOcp6y5GUAHsy9f=J0SKcV6m7UsqDB6VRsJNoByvWOnx0jw@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
 <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
 <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>
 <f0228d46-1528-6bca-7deb-7c496cf0ebfb@redhat.com>
 <CA+tA26uCqLWCKJvipuvKNY113afJuQM5cyRParLKXhA8HPbZCg@mail.gmail.com>
 <CA+tA26vO9y73PkmVvOpYYxgMVBvtpW7mTzshuy1X_y4SNmNPHA@mail.gmail.com>
 <CAEBeOcp6y5GUAHsy9f=J0SKcV6m7UsqDB6VRsJNoByvWOnx0jw@mail.gmail.com>
Message-ID: <CA+tA26u7qxVop=yCAcFnRB91FRbj74QhFhe99gRzGD+LBYE5XA@mail.gmail.com>

This is the latest updated patch for fixes of the following, as
mentioned earlier in this thread:

 - wildcard imports were replaced with single class imports
 - unnecessary white spaces were removed
 - indentations were changed to using tabs instead of spaces
 - removed mIsUpdatingModel guard
 - removed getHeapSize and mHeapSize in BaseViewer
 - declared setHeapSize in BaseViewer abstract
 - initialized mHeapSize to 1 to avoid division by zero
 - numbers are now rounded instead of truncated
 - number displays are now comma-separated
 - removed global jfx dependencies (javafx.osgi, p2 repo, target platforms)
 - refactored sub-component calls
 - used a more contrasting color palette for pie charts
 - fixed rotating table color
 - memory column displays 2 decimal places. add tooltips
 - fixed JavaThingPage NPE

Spotbug config typos were resolved in another issue and are now fixed and push.

Webrev:
http://cr.openjdk.java.net/~aptmac/JMC-6555/webrev.03/

Thanks to Alex for creating this webrev.

Regards,

On Thu, 29 Aug 2019 at 09:58, Jie Kang <jkang at redhat.com> wrote:
>
> On Tue, Aug 27, 2019 at 1:41 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> >
> > Hello all,
> >
> > The following is the updated webrev. Several issues mentioned in this
> > thread are addressed:
> > - wildcard imports were replaced with single class imports
> > - unnecessary white spaces were removed
> > - indentations were changed to using tabs instead of spaces
> > - removed mIsUpdatingModel guard
> > - removed getHeapSize and mHeapSize in BaseViewer
> > - declared setHeapSize in BaseViewer abstract
> > - initialized mHeapSize to 1 to avoid division by zero
> > - numbers are now rounded instead of truncated
> > - number displays are now comma-separated
> > - removed global jfx dependencies (javafx.osgi, p2 repo, target platforms)
> > - refactored sub-component calls
> > - used a more contrasting color palette for pie charts
> >
> > Webrev:
> > https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.02/
>
> Hi all,
>
> I talked with Arvin through chat for some issues but for archive
> purposes I will list them, as well as some other issues here:
>
> * The rounding of KB values close to zero makes the data completely
> lost as the result shown is 0 KB. It would be nice if it had a few
> decimal points and a tooltip that showed the exact value.
> * When entering and exiting a table entry with mouse, the colour
> palette now rotates through the colours so they can no longer match
> the pie chart
> * After the alters to the spotbugs excludes file an error [1] now
> shows up. The match for org.openjdk.jmc.joverflow.ui.FXMain was
> written incorrectly with "OR" instead of "Or" so I guess it matched
> everything. Now that it's gone, a proper exclusion needs to be added
> to keep spotbugs happy.
>
> * I have opened a JMC instance which automatically re-opens a hprof
> file I had opened in a previous run of the application. When I use
> Window -> Show View -> Other -> JOverflow -> JOverflow Instances, I
> see the instances panel load with an NPE [2]. Note if I then close and
> re-open JMC where both the hprof file and the instances panel are
> loaded, this doesn't occur.
> * After seeing the NPE in the instances panel, when clicking around
> somewhat randomly in the view of a hprof file and repeatedly pressing
> the "Reset" button in the top-right corner, I see a Problem Occurred
> pop-up showing an NPE [3]. It occurs consistently when clicking an
> element in the Object Selection table (top left corner). The "Reset"
> button also no longer causes the views to reset.
> * If I have the Instances panel open before I open a hprof file it
> seems okay for the most part. I have also checked the previous
> revision and Similar behaviour also occurs
>
> [1]
>
> [INFO] --- spotbugs-maven-plugin:3.1.10:check (default) @
> org.openjdk.jmc.commands ---
> [INFO] BugInstance size is 1
> [INFO] Error size is 0
> [INFO] Total bugs: 1
> [ERROR] org.openjdk.jmc.commands.internal.executables.Version.execute(Statement,
> PrintStream) invokes System.exit(...), which shuts down the entire
> virtual machine
> [org.openjdk.jmc.commands.internal.executables.Version] At
> Version.java:[line 47] DM_EXIT
>
> [2]
>
> java.lang.NullPointerException
> at org.openjdk.jmc.joverflow.ui.JavaThingPage.allIncluded(JavaThingPage.java:80)
> at org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:141)
> at org.openjdk.jmc.joverflow.ui.JOverflowUi.addModelListener(JOverflowUi.java:158)
> at org.openjdk.jmc.joverflow.ui.InstancesPageBookView.lambda$0(InstancesPageBookView.java:59)
> at org.openjdk.jmc.joverflow.ui.JOverflowEditor.addUiLoadedListener(JOverflowEditor.java:271)
> at org.openjdk.jmc.joverflow.ui.InstancesPageBookView.doCreatePage(InstancesPageBookView.java:59)
> [truncated...]
>
> [3]
>
> java.lang.NullPointerException
> at org.openjdk.jmc.joverflow.ui.JavaThingPage.allIncluded(JavaThingPage.java:80)
> at org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:141)
> at org.openjdk.jmc.joverflow.ui.viewers.BaseViewer.notifyFilterChangedListeners(BaseViewer.java:24)
> at org.openjdk.jmc.joverflow.ui.viewers.OverheadTypeViewer.setCurrentType(OverheadTypeViewer.java:90)
> at org.openjdk.jmc.joverflow.ui.viewers.OverheadTypeViewer.lambda$0(OverheadTypeViewer.java:33)
> at org.eclipse.jface.viewers.Viewer$1.run(Viewer.java:151)
> [truncated...]
>
>
> Regards,
>
>
> >
> > Thanks to Jie for updating the webrev.
> >

From klara at kth.se  Wed Sep 11 06:56:57 2019
From: klara at kth.se (Klara Ward)
Date: Wed, 11 Sep 2019 08:56:57 +0200
Subject: Review request for JMC-6546: Fixing the update sites in JMC 7.1.0
In-Reply-To: <CAOpWGx30L5RLUiyosj6LZRLDEePEb6aWZMGafEDPFee58u5duQ@mail.gmail.com>
References: <CAOpWGx30L5RLUiyosj6LZRLDEePEb6aWZMGafEDPFee58u5duQ@mail.gmail.com>
Message-ID: <4933f7cf-67a5-736e-7a6d-ce84340f7238@kth.se>

Looks good to me.

// klward

On 2019-09-10 14:03, Marcus Hirt wrote:
> Hi all,
>
> Please review this fix for making the update sites work in JMC 7.1.0:
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6546
> diff:
> diff -r 751cae255f84
> application/org.openjdk.jmc.feature.flightrecorder/feature.xml
> --- a/application/org.openjdk.jmc.feature.flightrecorder/feature.xml
>   Thu Sep 05 21:18:12 2019 +0200
> +++ b/application/org.openjdk.jmc.feature.flightrecorder/feature.xml
>   Tue Sep 10 13:50:56 2019 +0200
> @@ -129,4 +129,11 @@
>            version="0.0.0"
>            unpack="false"/>
>
> -</feature>
> \ No newline at end of file
> +   <plugin
> +         id="org.hdrhistogram.HdrHistogram"
> +         download-size="0"
> +         install-size="0"
> +         version="0.0.0"
> +         unpack="false"/>
> +
> +</feature>
>
> Kind regards,
> Marcus


From marcus at hirt.se  Wed Sep 11 08:43:11 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Wed, 11 Sep 2019 08:43:11 +0000
Subject: hg: jmc/jmc: JMC-6546: Fixing the update sites in JMC 7.1.0
Message-ID: <201909110843.x8B8hC47022393@aojmv0008.oracle.com>

Changeset: a339026db37b
Author:    hirt <marcus.hirt at datadoghq.com>
Date:      2019-09-11 10:42 +0200
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/a339026db37b

JMC-6546: Fixing the update sites in JMC 7.1.0
Reviewed-by: ebaron, klward

! application/org.openjdk.jmc.feature.flightrecorder/feature.xml


From marcus at hirt.se  Wed Sep 11 11:17:49 2019
From: marcus at hirt.se (Marcus Hirt)
Date: Wed, 11 Sep 2019 13:17:49 +0200
Subject: Sv: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26u7qxVop=yCAcFnRB91FRbj74QhFhe99gRzGD+LBYE5XA@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
 <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
 <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>
 <f0228d46-1528-6bca-7deb-7c496cf0ebfb@redhat.com>
 <CA+tA26uCqLWCKJvipuvKNY113afJuQM5cyRParLKXhA8HPbZCg@mail.gmail.com>
 <CA+tA26vO9y73PkmVvOpYYxgMVBvtpW7mTzshuy1X_y4SNmNPHA@mail.gmail.com>
 <CAEBeOcp6y5GUAHsy9f=J0SKcV6m7UsqDB6VRsJNoByvWOnx0jw@mail.gmail.com>
 <CA+tA26u7qxVop=yCAcFnRB91FRbj74QhFhe99gRzGD+LBYE5XA@mail.gmail.com>
Message-ID: <05a701d56892$8bcdec60$a369c520$@hirt.se>

To all JOverflow users:

Please give this patch a try!

Kind regards,
Marcus

-----Ursprungligt meddelande-----
Fr?n: jmc-dev <jmc-dev-bounces at openjdk.java.net> F?r Arvin Kangcheng Xu
Skickat: den 10 september 2019 22:02
Till: jmc-dev at openjdk.java.net
?mne: Re: RFR: JMC-6555 Convert JOverflow plugin to SWT

This is the latest updated patch for fixes of the following, as mentioned earlier in this thread:

 - wildcard imports were replaced with single class imports
 - unnecessary white spaces were removed
 - indentations were changed to using tabs instead of spaces
 - removed mIsUpdatingModel guard
 - removed getHeapSize and mHeapSize in BaseViewer
 - declared setHeapSize in BaseViewer abstract
 - initialized mHeapSize to 1 to avoid division by zero
 - numbers are now rounded instead of truncated
 - number displays are now comma-separated
 - removed global jfx dependencies (javafx.osgi, p2 repo, target platforms)
 - refactored sub-component calls
 - used a more contrasting color palette for pie charts
 - fixed rotating table color
 - memory column displays 2 decimal places. add tooltips
 - fixed JavaThingPage NPE

Spotbug config typos were resolved in another issue and are now fixed and push.

Webrev:
http://cr.openjdk.java.net/~aptmac/JMC-6555/webrev.03/

Thanks to Alex for creating this webrev.

Regards,

On Thu, 29 Aug 2019 at 09:58, Jie Kang <jkang at redhat.com> wrote:
>
> On Tue, Aug 27, 2019 at 1:41 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
> >
> > Hello all,
> >
> > The following is the updated webrev. Several issues mentioned in 
> > this thread are addressed:
> > - wildcard imports were replaced with single class imports
> > - unnecessary white spaces were removed
> > - indentations were changed to using tabs instead of spaces
> > - removed mIsUpdatingModel guard
> > - removed getHeapSize and mHeapSize in BaseViewer
> > - declared setHeapSize in BaseViewer abstract
> > - initialized mHeapSize to 1 to avoid division by zero
> > - numbers are now rounded instead of truncated
> > - number displays are now comma-separated
> > - removed global jfx dependencies (javafx.osgi, p2 repo, target 
> > platforms)
> > - refactored sub-component calls
> > - used a more contrasting color palette for pie charts
> >
> > Webrev:
> > https://cr.openjdk.java.net/~jkang/joverflow-swt/webrev.02/
>
> Hi all,
>
> I talked with Arvin through chat for some issues but for archive 
> purposes I will list them, as well as some other issues here:
>
> * The rounding of KB values close to zero makes the data completely 
> lost as the result shown is 0 KB. It would be nice if it had a few 
> decimal points and a tooltip that showed the exact value.
> * When entering and exiting a table entry with mouse, the colour 
> palette now rotates through the colours so they can no longer match 
> the pie chart
> * After the alters to the spotbugs excludes file an error [1] now 
> shows up. The match for org.openjdk.jmc.joverflow.ui.FXMain was 
> written incorrectly with "OR" instead of "Or" so I guess it matched 
> everything. Now that it's gone, a proper exclusion needs to be added 
> to keep spotbugs happy.
>
> * I have opened a JMC instance which automatically re-opens a hprof 
> file I had opened in a previous run of the application. When I use 
> Window -> Show View -> Other -> JOverflow -> JOverflow Instances, I 
> see the instances panel load with an NPE [2]. Note if I then close and 
> re-open JMC where both the hprof file and the instances panel are 
> loaded, this doesn't occur.
> * After seeing the NPE in the instances panel, when clicking around 
> somewhat randomly in the view of a hprof file and repeatedly pressing 
> the "Reset" button in the top-right corner, I see a Problem Occurred 
> pop-up showing an NPE [3]. It occurs consistently when clicking an 
> element in the Object Selection table (top left corner). The "Reset"
> button also no longer causes the views to reset.
> * If I have the Instances panel open before I open a hprof file it 
> seems okay for the most part. I have also checked the previous 
> revision and Similar behaviour also occurs
>
> [1]
>
> [INFO] --- spotbugs-maven-plugin:3.1.10:check (default) @ 
> org.openjdk.jmc.commands --- [INFO] BugInstance size is 1 [INFO] Error 
> size is 0 [INFO] Total bugs: 1 [ERROR] 
> org.openjdk.jmc.commands.internal.executables.Version.execute(Statemen
> t,
> PrintStream) invokes System.exit(...), which shuts down the entire 
> virtual machine 
> [org.openjdk.jmc.commands.internal.executables.Version] At 
> Version.java:[line 47] DM_EXIT
>
> [2]
>
> java.lang.NullPointerException
> at 
> org.openjdk.jmc.joverflow.ui.JavaThingPage.allIncluded(JavaThingPage.j
> ava:80) at 
> org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:
> 141) at 
> org.openjdk.jmc.joverflow.ui.JOverflowUi.addModelListener(JOverflowUi.
> java:158) at 
> org.openjdk.jmc.joverflow.ui.InstancesPageBookView.lambda$0(InstancesP
> ageBookView.java:59) at 
> org.openjdk.jmc.joverflow.ui.JOverflowEditor.addUiLoadedListener(JOver
> flowEditor.java:271) at 
> org.openjdk.jmc.joverflow.ui.InstancesPageBookView.doCreatePage(Instan
> cesPageBookView.java:59)
> [truncated...]
>
> [3]
>
> java.lang.NullPointerException
> at 
> org.openjdk.jmc.joverflow.ui.JavaThingPage.allIncluded(JavaThingPage.j
> ava:80) at 
> org.openjdk.jmc.joverflow.ui.JOverflowUi.updateModel(JOverflowUi.java:
> 141) at 
> org.openjdk.jmc.joverflow.ui.viewers.BaseViewer.notifyFilterChangedLis
> teners(BaseViewer.java:24) at 
> org.openjdk.jmc.joverflow.ui.viewers.OverheadTypeViewer.setCurrentType
> (OverheadTypeViewer.java:90) at 
> org.openjdk.jmc.joverflow.ui.viewers.OverheadTypeViewer.lambda$0(Overh
> eadTypeViewer.java:33) at 
> org.eclipse.jface.viewers.Viewer$1.run(Viewer.java:151)
> [truncated...]
>
>
> Regards,
>
>
> >
> > Thanks to Jie for updating the webrev.
> >


From jkang at redhat.com  Tue Sep 17 17:01:35 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 17 Sep 2019 13:01:35 -0400
Subject: RFR: JMC-6555 Convert JOverflow plugin to SWT
In-Reply-To: <CA+tA26u7qxVop=yCAcFnRB91FRbj74QhFhe99gRzGD+LBYE5XA@mail.gmail.com>
References: <CA+tA26tat69KJSHDxWAyXsOfDaftP5rs=xCyZpXddwSS++B6Ww@mail.gmail.com>
 <CAEBeOcpH9GrCAYP_0HisrVhOWpmkvssGY_iuQK4sonfc-6DH2w@mail.gmail.com>
 <CAJwKKmZU4Y53io5jzm55XHsLHt49HfP-5d_gnAUw=0EUrJgXWA@mail.gmail.com>
 <CAJwKKmbUpxXvYG5k=CRPbaB=mjkEBVjB6nD-AbetmpS-zQhkjA@mail.gmail.com>
 <CA+tA26vibYE+9SRy0MCd8P2147NKixTfLG0Rpfr0VjXmqvqujA@mail.gmail.com>
 <CAJwKKmYiaxaJ8k-vRKQkhbrx_7ri5EqD6E7k4YsttmLVkk0pww@mail.gmail.com>
 <CA+tA26vtVeACOrXKwnW_b-3tBab_8rDLD_mZhR-BrcMDV1_77w@mail.gmail.com>
 <f0228d46-1528-6bca-7deb-7c496cf0ebfb@redhat.com>
 <CA+tA26uCqLWCKJvipuvKNY113afJuQM5cyRParLKXhA8HPbZCg@mail.gmail.com>
 <CA+tA26vO9y73PkmVvOpYYxgMVBvtpW7mTzshuy1X_y4SNmNPHA@mail.gmail.com>
 <CAEBeOcp6y5GUAHsy9f=J0SKcV6m7UsqDB6VRsJNoByvWOnx0jw@mail.gmail.com>
 <CA+tA26u7qxVop=yCAcFnRB91FRbj74QhFhe99gRzGD+LBYE5XA@mail.gmail.com>
Message-ID: <CAEBeOcphE4evXbHLW0HhvM3cT0SYgEXD_5=AtxOmB4kWz-jT5w@mail.gmail.com>

On Tue, Sep 10, 2019 at 4:02 PM Arvin Kangcheng Xu <kxu at redhat.com> wrote:
>
> This is the latest updated patch for fixes of the following, as
> mentioned earlier in this thread:
>
>  - wildcard imports were replaced with single class imports
>  - unnecessary white spaces were removed
>  - indentations were changed to using tabs instead of spaces
>  - removed mIsUpdatingModel guard
>  - removed getHeapSize and mHeapSize in BaseViewer
>  - declared setHeapSize in BaseViewer abstract
>  - initialized mHeapSize to 1 to avoid division by zero
>  - numbers are now rounded instead of truncated
>  - number displays are now comma-separated
>  - removed global jfx dependencies (javafx.osgi, p2 repo, target platforms)
>  - refactored sub-component calls
>  - used a more contrasting color palette for pie charts
>  - fixed rotating table color
>  - memory column displays 2 decimal places. add tooltips
>  - fixed JavaThingPage NPE
>
> Spotbug config typos were resolved in another issue and are now fixed and push.
>
> Webrev:
> http://cr.openjdk.java.net/~aptmac/JMC-6555/webrev.03/

Hey Arvin,

Thanks for your continued efforts here! A few more small things below from me:

--- old/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/HeapDumpAction.java
2019-09-10 15:31:43.946263444 -0400
+++ new/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/HeapDumpAction.java
2019-09-10 15:31:43.864262593 -0400
-import java.io.File;
-
-import javax.management.MBeanServerConnection;
-import javax.management.ObjectName;
-
import org.eclipse.jface.dialogs.InputDialog;
import org.eclipse.jface.window.Window;
import org.eclipse.swt.SWT;
import org.eclipse.swt.widgets.Display;
import org.eclipse.swt.widgets.FileDialog;
-
import org.openjdk.jmc.common.io.IOToolkit;
import org.openjdk.jmc.rjmx.IConnectionHandle;
import org.openjdk.jmc.rjmx.IServerHandle;
@@ -56,10 +50,14 @@
import org.openjdk.jmc.ui.misc.DialogToolkit;
import org.openjdk.jmc.ui.misc.DisplayToolkit;
+import javax.management.MBeanServerConnection;
+import javax.management.ObjectName;
+import java.io.File;

The import order change here should not be made. This applies
elsewhere in the patch. I'm guessing an auto-formatter was used but
it's configuration for imports wasn't set correctly. If it's the
configuration included in the jmc repository that's a minor issue that
could be addressed separately.

--- /dev/null 2019-09-10 09:22:37.353999759 -0400
+++ new/application/org.openjdk.jmc.joverflow.ui/src/main/java/org/openjdk/jmc/joverflow/ui/JavaThingPage.java
 2019-09-10 15:31:50.541331853 -0400
@@ -0,0 +1,134 @@

++public class JavaThingPage extends Page implements ModelListener {
+ private final JOverflowEditor mEditor;
+ private JavaThingTreeViewer mTreeViewer;

JavaThingTreeViewer is defined as "public class JavaThingTreeViewer<T
extends JavaThingItem> extends TreeViewer {". Can mTreeViewer instance
by typed to "JavaThingTreeViewer<JavaThingItem>"?

Apart from these, the patch looks pretty good!


Regards,


>
> Thanks to Alex for creating this webrev.
>
> Regards,
>

From jkang at redhat.com  Tue Sep 17 21:20:27 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 17 Sep 2019 17:20:27 -0400
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAOsn=kr1WeN64Xqkb=bOedaN3VJ+Q32gSe9dKdemOZOe6WgXaQ@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
 <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
 <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>
 <CAEBeOcq3rXNRWCqTxfje2CcD9wvwXAXUH6p=LyYvaOPPQUi9RA@mail.gmail.com>
 <CAEBeOco2f89wiR6dCp60pEiYArOPRZ_1TFQkoP907QKend3r0g@mail.gmail.com>
 <CAOsn=kr1WeN64Xqkb=bOedaN3VJ+Q32gSe9dKdemOZOe6WgXaQ@mail.gmail.com>
Message-ID: <CAEBeOcra4sE-fdv0Ctyztbems2NwiUohsn_qfJtMrDe4YaXQYg@mail.gmail.com>

On Tue, Sep 3, 2019 at 2:57 PM Alex Macdonald <almacdon at redhat.com> wrote:
>
> On Wed, Aug 28, 2019 at 11:36 AM Jie Kang <jkang at redhat.com> wrote:
>>
>> On Wed, Aug 28, 2019 at 10:46 AM Jie Kang <jkang at redhat.com> wrote:
>> >
>> > Hi all,
>> >
>> > Carmine has requested I continue this work in his stead. Please find
>> > an updated webrev for review below.
>> >
>> > Webrev: http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.00/
>> > Bug: https://bugs.openjdk.java.net/browse/JMC-5473
>>
>> Ah; I had a mistake in the previous webrev (the TableViewer was no
>> longer set), please find an updated one below. Apologies for the
>> mistake.
>>
>> http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.01/
>>
>>
>
> Looks good - the functionality works as it should and the uitests are passing on both my Linux & Windows machines.
>
> There is an unused import that can be cleaned up at:
>
> ResultTableUi.java
> - unused import GridData @ line 50

Hi Alex,

Nice catch thanks. I've removed the unused import.

>
> And my only other nit is that the test is placed in "org.openjdk.jmc.flightrecorder.uitest.overview" which would be a new package that would only have this test inside of it. It doesn't test (yet at least) the entire Automated Analysis page so maybe it doesn't fit under "[..].flightrecorder.uitest.pages", but maybe it belongs under [..].flightrecorder.uitest alongside the other tests? Just a thought.

Sure; I've moved it to be under o.o.jmc.flightrecorder.uitest. Here's
the updated webrev:

http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.02/

How does it look?


Regards,

>
>>
>> Regards,
>>
>> >
>> >
>> > Regards
>> >
>> >
>> >
>> > On Thu, Aug 1, 2019 at 10:24 AM Carmine Vincenzo Russo
>> > <carusso at redhat.com> wrote:
>> > >
>> > > Hi Jie,
>> > >
>> > > Thanks for pointing out these errors, I'll fix them and get back with an updated version.
>> > >
>> > > Thanks,
>> > > Carmine
>> > >
>> > > On Thu, Aug 1, 2019 at 4:16 PM Jie Kang <jkang at redhat.com> wrote:
>> > >>
>> > >> On Thu, Aug 1, 2019 at 6:53 AM Carmine Vincenzo Russo
>> > >> <carusso at redhat.com> wrote:
>> > >> >
>> > >> > Hi,
>> > >> >
>> > >> > The attached patch addresses the issue JMC-5473[0] in which a search
>> > >> > feature for the Automated Analysis Result Table was lacking.
>> > >> >
>> > >> > In ResultOverview.java, I added the text component and a simple layout to
>> > >> > give the page more consistency when the table is displayed.
>> > >> > I also produced ResultOverviewTest.java to test if the table has
>> > >> > components, the search feature operates, and two more to check if the
>> > >> > behaviour is what we expect with a nonsense search and a specific search.
>> > >> >
>> > >> > A side note, since there were no tests for the Automated Analysis Result, I
>> > >> > had to add the tab in JfrUi and allow the record analysis in two other
>> > >> > classes, OldRecordingsVerificationTest.java and JfrRecordingTest.java,
>> > >> > because they go through all the tabs listed in JfrUi during their tests.
>> > >> >
>> > >> > How does it look?
>> > >>
>> > >> Hi Carmine,
>> > >>
>> > >> Thanks for doing this; the tests are appreciated! I have some issues
>> > >> to address below:
>> > >>
>> > >> diff --git a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/R
>> > >> esultOverview.java
>> > >> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/ov
>> > >> erview/ResultOverview.java
>> > >> --- a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
>> > >> erview.java
>> > >> +++ b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
>> > >> erview.java
>> > >> [...]
>> > >> -
>> > >> +
>> > >>
>> > >> * Whitespace additions like the example shown above should be removed;
>> > >> there are others in the patch.
>> > >>
>> > >> -                       Map<Result, DataPageDescriptor> map = createResultMap();
>> > >> +                       GridLayout layout = new GridLayout(1, true);
>> > >> +                       this.form.getBody().setLayout(layout);
>> > >> +                       text = new Text(form.getBody(), SWT.BORDER |
>> > >> SWT.HORIZONTAL | SWT.SEARCH | SWT.RESIZE);
>> > >> +                       text.setLayoutData(new GridData(SWT.FILL,
>> > >> SWT.DEFAULT, true, false));
>> > >> +                       text.setMessage(Messages.ResultOverview_SEARCH_TABLE);
>> > >> +                       text.setToolTipText(Messages.ResultOverview_SEARCH_BAR);
>> > >> +                       Map<Result, DataPageDescriptor> map =
>> > >> createResultMap(text.getText());
>> > >>                         table = new ResultTableUi(form, toolkit,
>> > >> editor, loadedState, map);
>> > >> +                       ModifyListener listener = new ModifyListener() {
>> > >> +                               @Override
>> > >> +                               public void modifyText(ModifyEvent e) {
>> > >> +                                       Map<Result,
>> > >> DataPageDescriptor> map = createResultMap(text.getText());
>> > >> +                                       table.updateInput(map);
>> > >> +                               }
>> > >> +                       };
>> > >> +                       text.addModifyListener(listener);
>> > >>                 }
>> > >> * The additions to the Table UI done above should occur in the Table
>> > >> UI code, rather than in the overview which is managing the HTML UI and
>> > >> the Table UI, ie. the above should be within ResultTableUi.java
>> > >>
>> > >> * When switching to the Table and then back to the HTML, the resulting
>> > >> view is strange; see the linked image [1]. This may have to do with
>> > >> how the form's layout is modified by your addition. This form is the
>> > >> parent for the ResultTableUi. I would add children to it with custom
>> > >> layouts, but I would not modify the 'parent' layout itself.
>> > >>
>> > >> https://imgur.com/a/nS1m2T2
>> > >>
>> > >>
>> > >> Regards,
>> > >>
>> > >> >
>> > >> > Regards,
>> > >> > Carmine
>> > >> >
>> > >> > [0] https://bugs.openjdk.java.net/browse/JMC-5473
>> > >> >
>> > >> > --
>> > >> > Carmine Vincenzo Russo
>> > >
>> > >
>> > >
>> > > --
>> > > Carmine Vincenzo Russo

From almacdon at redhat.com  Wed Sep 18 14:58:59 2019
From: almacdon at redhat.com (Alex Macdonald)
Date: Wed, 18 Sep 2019 10:58:59 -0400
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAEBeOcra4sE-fdv0Ctyztbems2NwiUohsn_qfJtMrDe4YaXQYg@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
 <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
 <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>
 <CAEBeOcq3rXNRWCqTxfje2CcD9wvwXAXUH6p=LyYvaOPPQUi9RA@mail.gmail.com>
 <CAEBeOco2f89wiR6dCp60pEiYArOPRZ_1TFQkoP907QKend3r0g@mail.gmail.com>
 <CAOsn=kr1WeN64Xqkb=bOedaN3VJ+Q32gSe9dKdemOZOe6WgXaQ@mail.gmail.com>
 <CAEBeOcra4sE-fdv0Ctyztbems2NwiUohsn_qfJtMrDe4YaXQYg@mail.gmail.com>
Message-ID: <CAOsn=koFxsp8EQbDbggWofSCbuBktMdvdugH-T2fQJVy4aW-2Q@mail.gmail.com>

On Tue, Sep 17, 2019 at 5:20 PM Jie Kang <jkang at redhat.com> wrote:

> On Tue, Sep 3, 2019 at 2:57 PM Alex Macdonald <almacdon at redhat.com> wrote:
> >
> > On Wed, Aug 28, 2019 at 11:36 AM Jie Kang <jkang at redhat.com> wrote:
> >>
> >> On Wed, Aug 28, 2019 at 10:46 AM Jie Kang <jkang at redhat.com> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > Carmine has requested I continue this work in his stead. Please find
> >> > an updated webrev for review below.
> >> >
> >> > Webrev: http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.00/
> >> > Bug: https://bugs.openjdk.java.net/browse/JMC-5473
> >>
> >> Ah; I had a mistake in the previous webrev (the TableViewer was no
> >> longer set), please find an updated one below. Apologies for the
> >> mistake.
> >>
> >> http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.01/
> >>
> >>
> >
> > Looks good - the functionality works as it should and the uitests are
> passing on both my Linux & Windows machines.
> >
> > There is an unused import that can be cleaned up at:
> >
> > ResultTableUi.java
> > - unused import GridData @ line 50
>
> Hi Alex,
>
> Nice catch thanks. I've removed the unused import.
>
> >
> > And my only other nit is that the test is placed in
> "org.openjdk.jmc.flightrecorder.uitest.overview" which would be a new
> package that would only have this test inside of it. It doesn't test (yet
> at least) the entire Automated Analysis page so maybe it doesn't fit under
> "[..].flightrecorder.uitest.pages", but maybe it belongs under
> [..].flightrecorder.uitest alongside the other tests? Just a thought.
>
> Sure; I've moved it to be under o.o.jmc.flightrecorder.uitest. Here's
> the updated webrev:
>

Great, thanks. LGTM.


>
> http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.02/
>
> How does it look?
>
>
> Regards,
>
> >
> >>
> >> Regards,
> >>
> >> >
> >> >
> >> > Regards
> >> >
> >> >
> >> >
> >> > On Thu, Aug 1, 2019 at 10:24 AM Carmine Vincenzo Russo
> >> > <carusso at redhat.com> wrote:
> >> > >
> >> > > Hi Jie,
> >> > >
> >> > > Thanks for pointing out these errors, I'll fix them and get back
> with an updated version.
> >> > >
> >> > > Thanks,
> >> > > Carmine
> >> > >
> >> > > On Thu, Aug 1, 2019 at 4:16 PM Jie Kang <jkang at redhat.com> wrote:
> >> > >>
> >> > >> On Thu, Aug 1, 2019 at 6:53 AM Carmine Vincenzo Russo
> >> > >> <carusso at redhat.com> wrote:
> >> > >> >
> >> > >> > Hi,
> >> > >> >
> >> > >> > The attached patch addresses the issue JMC-5473[0] in which a
> search
> >> > >> > feature for the Automated Analysis Result Table was lacking.
> >> > >> >
> >> > >> > In ResultOverview.java, I added the text component and a simple
> layout to
> >> > >> > give the page more consistency when the table is displayed.
> >> > >> > I also produced ResultOverviewTest.java to test if the table has
> >> > >> > components, the search feature operates, and two more to check
> if the
> >> > >> > behaviour is what we expect with a nonsense search and a
> specific search.
> >> > >> >
> >> > >> > A side note, since there were no tests for the Automated
> Analysis Result, I
> >> > >> > had to add the tab in JfrUi and allow the record analysis in two
> other
> >> > >> > classes, OldRecordingsVerificationTest.java and
> JfrRecordingTest.java,
> >> > >> > because they go through all the tabs listed in JfrUi during
> their tests.
> >> > >> >
> >> > >> > How does it look?
> >> > >>
> >> > >> Hi Carmine,
> >> > >>
> >> > >> Thanks for doing this; the tests are appreciated! I have some
> issues
> >> > >> to address below:
> >> > >>
> >> > >> diff --git
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/R
> >> > >> esultOverview.java
> >> > >>
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/ov
> >> > >> erview/ResultOverview.java
> >> > >> ---
> a/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
> >> > >> erview.java
> >> > >> +++
> b/application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultOv
> >> > >> erview.java
> >> > >> [...]
> >> > >> -
> >> > >> +
> >> > >>
> >> > >> * Whitespace additions like the example shown above should be
> removed;
> >> > >> there are others in the patch.
> >> > >>
> >> > >> -                       Map<Result, DataPageDescriptor> map =
> createResultMap();
> >> > >> +                       GridLayout layout = new GridLayout(1,
> true);
> >> > >> +                       this.form.getBody().setLayout(layout);
> >> > >> +                       text = new Text(form.getBody(), SWT.BORDER
> |
> >> > >> SWT.HORIZONTAL | SWT.SEARCH | SWT.RESIZE);
> >> > >> +                       text.setLayoutData(new GridData(SWT.FILL,
> >> > >> SWT.DEFAULT, true, false));
> >> > >> +
>  text.setMessage(Messages.ResultOverview_SEARCH_TABLE);
> >> > >> +
>  text.setToolTipText(Messages.ResultOverview_SEARCH_BAR);
> >> > >> +                       Map<Result, DataPageDescriptor> map =
> >> > >> createResultMap(text.getText());
> >> > >>                         table = new ResultTableUi(form, toolkit,
> >> > >> editor, loadedState, map);
> >> > >> +                       ModifyListener listener = new
> ModifyListener() {
> >> > >> +                               @Override
> >> > >> +                               public void modifyText(ModifyEvent
> e) {
> >> > >> +                                       Map<Result,
> >> > >> DataPageDescriptor> map = createResultMap(text.getText());
> >> > >> +                                       table.updateInput(map);
> >> > >> +                               }
> >> > >> +                       };
> >> > >> +                       text.addModifyListener(listener);
> >> > >>                 }
> >> > >> * The additions to the Table UI done above should occur in the
> Table
> >> > >> UI code, rather than in the overview which is managing the HTML UI
> and
> >> > >> the Table UI, ie. the above should be within ResultTableUi.java
> >> > >>
> >> > >> * When switching to the Table and then back to the HTML, the
> resulting
> >> > >> view is strange; see the linked image [1]. This may have to do with
> >> > >> how the form's layout is modified by your addition. This form is
> the
> >> > >> parent for the ResultTableUi. I would add children to it with
> custom
> >> > >> layouts, but I would not modify the 'parent' layout itself.
> >> > >>
> >> > >> https://imgur.com/a/nS1m2T2
> >> > >>
> >> > >>
> >> > >> Regards,
> >> > >>
> >> > >> >
> >> > >> > Regards,
> >> > >> > Carmine
> >> > >> >
> >> > >> > [0] https://bugs.openjdk.java.net/browse/JMC-5473
> >> > >> >
> >> > >> > --
> >> > >> > Carmine Vincenzo Russo
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Carmine Vincenzo Russo
>

From hdafgard at gmail.com  Wed Sep 18 16:57:07 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Wed, 18 Sep 2019 18:57:07 +0200
Subject: Review request for JMC-6582: ItemTreeBuilder is slow and not
 interruptible
Message-ID: <CADFkdVQb8xKU4DqFaR0ayF4XxFZjaA56X3eHDYthavMsu28e5A@mail.gmail.com>

Hi all,

Please review this patch for improving the performance of the
ItemTreeBuilder encapsulation tree generation and adding functionality to
allow interrupting it.

JIRA: https://bugs.openjdk.java.net/browse/JMC-6582
Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6582/webrev.0/


Cheers,
Henrik Dafg?rd

From marcus.hirt at datadoghq.com  Thu Sep 19 08:43:32 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Thu, 19 Sep 2019 01:43:32 -0700
Subject: Review request for JMC-6582: ItemTreeBuilder is slow and not
 interruptible
In-Reply-To: <CADFkdVQb8xKU4DqFaR0ayF4XxFZjaA56X3eHDYthavMsu28e5A@mail.gmail.com>
References: <CADFkdVQb8xKU4DqFaR0ayF4XxFZjaA56X3eHDYthavMsu28e5A@mail.gmail.com>
Message-ID: <CAOpWGx0qc2sVFN6WF9+_E6D15aQtQX8Z2GRccu9yu_fjg54ViA@mail.gmail.com>

LGTM!

/M

On Wed, Sep 18, 2019 at 9:59 AM Henrik Dafg?rd <hdafgard at gmail.com> wrote:
>
> Hi all,
>
> Please review this patch for improving the performance of the
> ItemTreeBuilder encapsulation tree generation and adding functionality to
> allow interrupting it.
>
> JIRA: https://bugs.openjdk.java.net/browse/JMC-6582
> Webrev: http://cr.openjdk.java.net/~hdafgard/JMC-6582/webrev.0/
>
>
> Cheers,
> Henrik Dafg?rd

From hdafgard at gmail.com  Thu Sep 19 11:59:37 2019
From: hdafgard at gmail.com (hdafgard at gmail.com)
Date: Thu, 19 Sep 2019 11:59:37 +0000
Subject: hg: jmc/jmc: JMC-6582: ItemTreeBuilder is slow and not interruptible
Message-ID: <201909191159.x8JBxbgH010100@aojmv0008.oracle.com>

Changeset: 583a1dde37f2
Author:    hdafgard <hdafgard at gmail.com>
Date:      2019-09-18 18:47 +0200
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/583a1dde37f2

JMC-6582: ItemTreeBuilder is slow and not interruptible
Summary: Improve performance by using proper accessors and add implementable interface to allow interruption
Reviewed-by: hirt

! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/ItemTreeBuilder.java
! core/org.openjdk.jmc.flightrecorder.rules/src/main/java/org/openjdk/jmc/flightrecorder/rules/tree/TreeNode.java


From jkang at redhat.com  Thu Sep 19 13:06:14 2019
From: jkang at redhat.com (Jie Kang)
Date: Thu, 19 Sep 2019 09:06:14 -0400
Subject: RFR JMC-4262: Duplicate headers when copying thread dump text to
 clipboard
Message-ID: <CAEBeOcomawT9F_kpfdLqH2CHW6Y6OwwwwCEqbo08J2VexNWUjw@mail.gmail.com>

Hi all,

Please review this attempt to address JMC-4262. Within the constraints
of the user's selection being an ordered list, I came up with this
solution. Please let me know what you think!

Webrev: http://cr.openjdk.java.net/~jkang/jmc-4262/webrev.01/
Bug: https://bugs.openjdk.java.net/browse/JMC-4262


Regards,


From marcus.hirt at datadoghq.com  Sat Sep 21 02:28:27 2019
From: marcus.hirt at datadoghq.com (Marcus Hirt)
Date: Fri, 20 Sep 2019 19:28:27 -0700
Subject: Review request for JMC-6584: Include the Flame View by default
Message-ID: <CAOpWGx2kUOjPj0ZsRnTeyY4-G20g9LBOJGWFEF88Hfx_BqiNQw@mail.gmail.com>

Hi all,

Please review this patch to add the flame view to be available by
default. Note that even after this patch, you will still need to go to
Window->Show View->Other... and then select the Mission Control/Flame
View, and then click Open, to add the view to the perspective. We can
discuss adding it to the JMC perspective later.

Jira:   https://bugs.openjdk.java.net/browse/JMC-6584
Webrev: http://cr.openjdk.java.net/~hirt/JMC-6584/webrev.0/

Kind regards,
Marcus

From hdafgard at gmail.com  Mon Sep 23 09:58:05 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Mon, 23 Sep 2019 11:58:05 +0200
Subject: Review request for JMC-6584: Include the Flame View by default
In-Reply-To: <CAOpWGx2kUOjPj0ZsRnTeyY4-G20g9LBOJGWFEF88Hfx_BqiNQw@mail.gmail.com>
References: <CAOpWGx2kUOjPj0ZsRnTeyY4-G20g9LBOJGWFEF88Hfx_BqiNQw@mail.gmail.com>
Message-ID: <CADFkdVRcDtrH_ATtduSROASPAPNHWKUw6p6xhii4BF-ZFVNtJw@mail.gmail.com>

LGTM!


Cheers,
Henrik Dafg?rd


On Sat, 21 Sep 2019 at 04:29, Marcus Hirt <marcus.hirt at datadoghq.com> wrote:

> Hi all,
>
> Please review this patch to add the flame view to be available by
> default. Note that even after this patch, you will still need to go to
> Window->Show View->Other... and then select the Mission Control/Flame
> View, and then click Open, to add the view to the perspective. We can
> discuss adding it to the JMC perspective later.
>
> Jira:   https://bugs.openjdk.java.net/browse/JMC-6584
> Webrev: http://cr.openjdk.java.net/~hirt/JMC-6584/webrev.0/
>
> Kind regards,
> Marcus
>

From marcus at hirt.se  Mon Sep 23 10:44:12 2019
From: marcus at hirt.se (marcus at hirt.se)
Date: Mon, 23 Sep 2019 10:44:12 +0000
Subject: hg: jmc/jmc: JMC-6584: Include Flame View by default
Message-ID: <201909231044.x8NAiC1P006101@aojmv0008.oracle.com>

Changeset: 38d88ec6495f
Author:    hirt <marcus.hirt at datadoghq.com>
Date:      2019-09-23 12:43 +0200
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/38d88ec6495f

JMC-6584: Include Flame View by default
Reviewed-by: hdafgard

- application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/.project
- application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/build.properties
- application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/feature.properties
- application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/feature.xml
- application/org.openjdk.jmc.feature.flightrecorder.ext.flameview/pom.xml
! application/org.openjdk.jmc.feature.flightrecorder/feature.xml
- application/org.openjdk.jmc.flightrecorder.ext.flameview/.classpath
- application/org.openjdk.jmc.flightrecorder.ext.flameview/.project
- application/org.openjdk.jmc.flightrecorder.ext.flameview/.settings/org.eclipse.jdt.core.prefs
- application/org.openjdk.jmc.flightrecorder.ext.flameview/.settings/org.eclipse.m2e.core.prefs
- application/org.openjdk.jmc.flightrecorder.ext.flameview/META-INF/MANIFEST.MF
- application/org.openjdk.jmc.flightrecorder.ext.flameview/build.properties
- application/org.openjdk.jmc.flightrecorder.ext.flameview/icons/flame.png
- application/org.openjdk.jmc.flightrecorder.ext.flameview/icons/flame at 2x.png
- application/org.openjdk.jmc.flightrecorder.ext.flameview/plugin.properties
- application/org.openjdk.jmc.flightrecorder.ext.flameview/plugin.xml
- application/org.openjdk.jmc.flightrecorder.ext.flameview/pom.xml
- application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/tree/TraceNode.java
- application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/tree/TraceTreeUtils.java
- application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/views/FlameGraphView.java
- application/org.openjdk.jmc.flightrecorder.ext.flameview/src/main/java/org/openjdk/jmc/flightrecorder/ext/flameview/views/page.html
+ application/org.openjdk.jmc.flightrecorder.flameview/.classpath
+ application/org.openjdk.jmc.flightrecorder.flameview/.project
+ application/org.openjdk.jmc.flightrecorder.flameview/.settings/org.eclipse.jdt.core.prefs
+ application/org.openjdk.jmc.flightrecorder.flameview/.settings/org.eclipse.m2e.core.prefs
+ application/org.openjdk.jmc.flightrecorder.flameview/META-INF/MANIFEST.MF
+ application/org.openjdk.jmc.flightrecorder.flameview/build.properties
+ application/org.openjdk.jmc.flightrecorder.flameview/icons/flame.png
+ application/org.openjdk.jmc.flightrecorder.flameview/icons/flame at 2x.png
+ application/org.openjdk.jmc.flightrecorder.flameview/plugin.properties
+ application/org.openjdk.jmc.flightrecorder.flameview/plugin.xml
+ application/org.openjdk.jmc.flightrecorder.flameview/pom.xml
+ application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceNode.java
+ application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/tree/TraceTreeUtils.java
+ application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/views/FlameGraphView.java
+ application/org.openjdk.jmc.flightrecorder.flameview/src/main/java/org/openjdk/jmc/flightrecorder/flameview/views/page.html
+ application/org.openjdk.jmc.rcp.product/.settings/org.eclipse.core.resources.prefs
! application/org.openjdk.jmc.updatesite.ide/category.xml
! application/org.openjdk.jmc.updatesite.ide/feature.xml
! application/org.openjdk.jmc.updatesite.rcp/category.xml
! application/org.openjdk.jmc.updatesite.rcp/feature.xml
! application/pom.xml
! configuration/ide/eclipse/launchers/JMC-Eclipse-plug-ins-JDK-8.launch
! configuration/ide/eclipse/launchers/JMC-Eclipse-plug-ins.launch
! configuration/ide/eclipse/launchers/JMC-RCP-plug-ins-JDK-8.launch
! configuration/ide/eclipse/launchers/JMC-RCP-plug-ins.launch


From jkang at redhat.com  Tue Sep 24 17:26:32 2019
From: jkang at redhat.com (Jie Kang)
Date: Tue, 24 Sep 2019 13:26:32 -0400
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAOsn=koFxsp8EQbDbggWofSCbuBktMdvdugH-T2fQJVy4aW-2Q@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
 <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
 <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>
 <CAEBeOcq3rXNRWCqTxfje2CcD9wvwXAXUH6p=LyYvaOPPQUi9RA@mail.gmail.com>
 <CAEBeOco2f89wiR6dCp60pEiYArOPRZ_1TFQkoP907QKend3r0g@mail.gmail.com>
 <CAOsn=kr1WeN64Xqkb=bOedaN3VJ+Q32gSe9dKdemOZOe6WgXaQ@mail.gmail.com>
 <CAEBeOcra4sE-fdv0Ctyztbems2NwiUohsn_qfJtMrDe4YaXQYg@mail.gmail.com>
 <CAOsn=koFxsp8EQbDbggWofSCbuBktMdvdugH-T2fQJVy4aW-2Q@mail.gmail.com>
Message-ID: <CAEBeOcrC12bC8h4UQa6qHJpTj5gp2=Yq9w+jhXxZ2b+0NEH08A@mail.gmail.com>

On Wed, Sep 18, 2019 at 10:59 AM Alex Macdonald <almacdon at redhat.com> wrote:
>
> On Tue, Sep 17, 2019 at 5:20 PM Jie Kang <jkang at redhat.com> wrote:
>>
>> On Tue, Sep 3, 2019 at 2:57 PM Alex Macdonald <almacdon at redhat.com> wrote:
>> >
>> > On Wed, Aug 28, 2019 at 11:36 AM Jie Kang <jkang at redhat.com> wrote:
>> >>
>> >> On Wed, Aug 28, 2019 at 10:46 AM Jie Kang <jkang at redhat.com> wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> > Carmine has requested I continue this work in his stead. Please find
>> >> > an updated webrev for review below.
>> >> >
>> >> > Webrev: http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.00/
>> >> > Bug: https://bugs.openjdk.java.net/browse/JMC-5473
>> >>
>> >> Ah; I had a mistake in the previous webrev (the TableViewer was no
>> >> longer set), please find an updated one below. Apologies for the
>> >> mistake.
>> >>
>> >> http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.01/
>> >>
>> >>
>> >
>> > Looks good - the functionality works as it should and the uitests are passing on both my Linux & Windows machines.
>> >
>> > There is an unused import that can be cleaned up at:
>> >
>> > ResultTableUi.java
>> > - unused import GridData @ line 50
>>
>> Hi Alex,
>>
>> Nice catch thanks. I've removed the unused import.
>>
>> >
>> > And my only other nit is that the test is placed in "org.openjdk.jmc.flightrecorder.uitest.overview" which would be a new package that would only have this test inside of it. It doesn't test (yet at least) the entire Automated Analysis page so maybe it doesn't fit under "[..].flightrecorder.uitest.pages", but maybe it belongs under [..].flightrecorder.uitest alongside the other tests? Just a thought.
>>
>> Sure; I've moved it to be under o.o.jmc.flightrecorder.uitest. Here's
>> the updated webrev:
>
>
> Great, thanks. LGTM.
>
>>
>>
>> http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.02/
>>
>> How does it look?

Thanks for the review Alex. Could I get a second reviewer for this?


Regards,

>>
>>
>> Regards,
>>

From hdafgard at gmail.com  Thu Sep 26 09:40:09 2019
From: hdafgard at gmail.com (=?UTF-8?Q?Henrik_Dafg=C3=A5rd?=)
Date: Thu, 26 Sep 2019 11:40:09 +0200
Subject: RFR: JMC-5473: Quick search for Automated Analysis Result Table
In-Reply-To: <CAEBeOcrC12bC8h4UQa6qHJpTj5gp2=Yq9w+jhXxZ2b+0NEH08A@mail.gmail.com>
References: <CAA6KdKfeMqEh2Pie8rkC+qGjF81iFi2-v5jX_aPpqGkVwVPxMg@mail.gmail.com>
 <CAEBeOcrLXq0Y6xzb3n28Dss-TjCQjvsmpjmY+S+qvarQqeA=6g@mail.gmail.com>
 <CAA6KdKdm9Y3YR4pTcS2gj0fZwhLMd=HN13JiLHCp6KDarhgmBA@mail.gmail.com>
 <CAEBeOcq3rXNRWCqTxfje2CcD9wvwXAXUH6p=LyYvaOPPQUi9RA@mail.gmail.com>
 <CAEBeOco2f89wiR6dCp60pEiYArOPRZ_1TFQkoP907QKend3r0g@mail.gmail.com>
 <CAOsn=kr1WeN64Xqkb=bOedaN3VJ+Q32gSe9dKdemOZOe6WgXaQ@mail.gmail.com>
 <CAEBeOcra4sE-fdv0Ctyztbems2NwiUohsn_qfJtMrDe4YaXQYg@mail.gmail.com>
 <CAOsn=koFxsp8EQbDbggWofSCbuBktMdvdugH-T2fQJVy4aW-2Q@mail.gmail.com>
 <CAEBeOcrC12bC8h4UQa6qHJpTj5gp2=Yq9w+jhXxZ2b+0NEH08A@mail.gmail.com>
Message-ID: <CADFkdVTgreZ4s8F+45cU4DTxN=k9PvdNARNdNDeW8A=Adq8nZw@mail.gmail.com>

This looks good to me!


Cheers,
Henrik Dafg?rd


On Tue, 24 Sep 2019 at 19:27, Jie Kang <jkang at redhat.com> wrote:

> On Wed, Sep 18, 2019 at 10:59 AM Alex Macdonald <almacdon at redhat.com>
> wrote:
> >
> > On Tue, Sep 17, 2019 at 5:20 PM Jie Kang <jkang at redhat.com> wrote:
> >>
> >> On Tue, Sep 3, 2019 at 2:57 PM Alex Macdonald <almacdon at redhat.com>
> wrote:
> >> >
> >> > On Wed, Aug 28, 2019 at 11:36 AM Jie Kang <jkang at redhat.com> wrote:
> >> >>
> >> >> On Wed, Aug 28, 2019 at 10:46 AM Jie Kang <jkang at redhat.com> wrote:
> >> >> >
> >> >> > Hi all,
> >> >> >
> >> >> > Carmine has requested I continue this work in his stead. Please
> find
> >> >> > an updated webrev for review below.
> >> >> >
> >> >> > Webrev: http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.00/
> >> >> > Bug: https://bugs.openjdk.java.net/browse/JMC-5473
> >> >>
> >> >> Ah; I had a mistake in the previous webrev (the TableViewer was no
> >> >> longer set), please find an updated one below. Apologies for the
> >> >> mistake.
> >> >>
> >> >> http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.01/
> >> >>
> >> >>
> >> >
> >> > Looks good - the functionality works as it should and the uitests are
> passing on both my Linux & Windows machines.
> >> >
> >> > There is an unused import that can be cleaned up at:
> >> >
> >> > ResultTableUi.java
> >> > - unused import GridData @ line 50
> >>
> >> Hi Alex,
> >>
> >> Nice catch thanks. I've removed the unused import.
> >>
> >> >
> >> > And my only other nit is that the test is placed in
> "org.openjdk.jmc.flightrecorder.uitest.overview" which would be a new
> package that would only have this test inside of it. It doesn't test (yet
> at least) the entire Automated Analysis page so maybe it doesn't fit under
> "[..].flightrecorder.uitest.pages", but maybe it belongs under
> [..].flightrecorder.uitest alongside the other tests? Just a thought.
> >>
> >> Sure; I've moved it to be under o.o.jmc.flightrecorder.uitest. Here's
> >> the updated webrev:
> >
> >
> > Great, thanks. LGTM.
> >
> >>
> >>
> >> http://cr.openjdk.java.net/~jkang/jmc-5473/webrev.02/
> >>
> >> How does it look?
>
> Thanks for the review Alex. Could I get a second reviewer for this?
>
>
> Regards,
>
> >>
> >>
> >> Regards,
> >>
>

From almacdon at redhat.com  Thu Sep 26 18:48:04 2019
From: almacdon at redhat.com (almacdon at redhat.com)
Date: Thu, 26 Sep 2019 18:48:04 +0000
Subject: hg: jmc/jmc: JMC-5473: Quick search for Automated Analysis Result
 Table
Message-ID: <201909261848.x8QIm4Ev022623@aojmv0008.oracle.com>

Changeset: ceedb367dc18
Author:    Jie Kang <jkang at redhat.com>
Date:      2019-09-26 11:16 -0400
URL:       https://hg.openjdk.java.net/jmc/jmc/rev/ceedb367dc18

JMC-5473: Quick search for Automated Analysis Result Table
Reviewed-by: aptmac, hdafgard
Contributed-by: Jie Kang <jkang at redhat.com>, Carmine Vincenzo Russo <carusso at redhat.com>

! application/org.openjdk.jmc.flightrecorder.ui/src/main/java/org/openjdk/jmc/flightrecorder/ui/overview/ResultTableUi.java
! application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/JfrRecordingTest.java
! application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/OldRecordingsVerificationTest.java
+ application/uitests/org.openjdk.jmc.flightrecorder.uitest/src/test/java/org/openjdk/jmc/flightrecorder/uitest/ResultOverviewTest.java
! application/uitests/org.openjdk.jmc.test.jemmy/src/test/java/org/openjdk/jmc/test/jemmy/misc/wrappers/JfrUi.java