Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k0V3S-0003ny-8v for pljava-dev@arkaria.postgresql.org; Tue, 28 Jul 2020 19:14:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k0V3Q-0008Rk-S0 for pljava-dev@arkaria.postgresql.org; Tue, 28 Jul 2020 19:14:24 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k0V3Q-0008Pw-GW for pljava-dev@lists.postgresql.org; Tue, 28 Jul 2020 19:14:24 +0000 Received: from mail-ej1-x62b.google.com ([2a00:1450:4864:20::62b]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k0V3O-00021G-3E for pljava-dev@lists.postgresql.org; Tue, 28 Jul 2020 19:14:23 +0000 Received: by mail-ej1-x62b.google.com with SMTP id f24so1278154ejx.6 for ; Tue, 28 Jul 2020 12:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aXkP/kLeXW5pzH7df79+lvzf6A1ZPE4649BdDEp/+Ik=; b=e1SO9W9b13bg9RZU+9+D6GPHDz3Y4T4OzzsVix+LSI0XgRGZycgHaLr1EgdaNZe6uD VWimvq+h/csgTx6tD7weqY6VSFuhFpUhsSpOpx6nNRuD/bvgE57UxJJldeGDCqaxM0D6 IF5niG5AbNC4fFqjQUhTII08Bhc15brlwlc8DfhA5V7JkpCX5L47485aHS/UGlM4u28a CTW1Dp9cgNmKM4IvJAvG9tTLP5wK0RoOUL9vYqU05zZaRrgVW9Khqr/svBr3+rIld3x6 guQBuy7MNcSZplv4gcQVWO37KEIA/81mCEhMdJYRDLH/JhlCqm/J0g4tttdpCwbzK/pW lxhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aXkP/kLeXW5pzH7df79+lvzf6A1ZPE4649BdDEp/+Ik=; b=GcWCrJ2SYDrOJCP3TZrTA6tjkYS34XjIHuoKy9B6Tlt3wo/pMzZPWuo26jJOYeI4+L Z59Ui561c7f71fl6eKLdBQsdNPJaqZaARuJ0wblrcCBI/Pf7ygy8tXjtksaz7VLHCMM0 pBwq3qVSxMr9+8oDADzqQFO7p/EY1Df+otm7uYBUZVS52N/XDCqY1/MGkXy2k7qTZWV4 HcCPifXi10QhCX4UbFXh6cnys1Q3VXz4p+TLvYge+ZC2ycs8hxUE1YgeTht7jSbjRtcP uCSmaOcnmva5/PSp//LcMuzRS4I1603HQZbzMGeFG2DyoqMqrQ12Co9BZYE5ZQy7mSUa 5icg== X-Gm-Message-State: AOAM533ixhCRVzHFjMaTTAy6UqJ6QdFbuS/NFqle+EzN7PAKDtFizd1L 0GllIoY2nTLgXAbZ1mkn1X9Zu881RZVgI7ejE7U= X-Google-Smtp-Source: ABdhPJyDdv1T+YD0u0YOV4QROu3Wf4BhWGf5OFpz50K0rCsq94h3fnrFczByUUnG/BTg6eVafFfyJGp6FfUKNeOzy5c= X-Received: by 2002:a17:907:42a0:: with SMTP id ny24mr20000707ejb.328.1595963660185; Tue, 28 Jul 2020 12:14:20 -0700 (PDT) MIME-Version: 1.0 References: <5F1735ED.6020707@anastigmatix.net> <5F1753C9.4060500@anastigmatix.net> <5F175F40.1000905@anastigmatix.net> <5F18C58F.8060204@anastigmatix.net> <5F19C36C.70905@anastigmatix.net> <5F1C6F06.2020809@anastigmatix.net> <5F1CE067.2060107@anastigmatix.net> <5F1F88E0.2050305@anastigmatix.net> In-Reply-To: From: Kartik Ohri Date: Wed, 29 Jul 2020 00:44:07 +0530 Message-ID: Subject: Re: PL/Java new build plugin To: Chapman Flack Cc: pljava-dev@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000000a339705ab853fd3" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --0000000000000a339705ab853fd3 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 28, 2020 at 11:53 PM Kartik Ohri wrote: > On Tue, Jul 28, 2020 at 7:39 AM Chapman Flack > wrote: > >> On 07/27/20 06:45, Kartik Ohri wrote: >> > Hi! The initial version of the javadoc mojo is ready. I have pushed the >> > changes. For now, I have just exposed a function using which arguments >> > could be added to the javadoc tool. I also wrote some script for making >> the >> > tool work. The javadoc tool works for pljava-api but not for pljava. I >> am >> > trying to debug this. It also works for PL/Java Examples. I have >> hardcoded >> >> That looks like a good start. I wonder if the explicit start of a >> subprocess >> could be replaced with >> javax.tools.ToolProvider.getSystemDocumentationTool() >> and the corresponding API. >> > I have made the switch from ProcessBuilder to ToolProvider and pushed the > changes. The usage is fairly simple as only a list of arguments is required > to be passed to the tool. > >> I think that could be simple enough to just directly use from the >> JavaScript, which would mean the mojo would not have to be called >> JavadocMojo or have Javadoc-specific functionality built in. It could >> concentrate on being a plugin that allows scripting of new reports in >> general to run in the site lifecycle. >> > For now, I have kept the procedure the same but using the ToolProvider API > is indeed very simple and requires only a couple of lines of code. So, we > can move those entirely to the script and make the mojo completely agnostic > to what it does as you suggest. I'll try this and let you know how it goes. > I tried this and it works well (except for the pljava module which was anyways crashing in the previous way as well). Please take a look at the latest changes and let me what other modifications are required. > > I did not try to go the interface route yet because I am not sure of the >> > order in which maven calls these methods. Because if maven calls these >> > methods before the executeReport method it would be of no use. >> >> It might (or, then again, might not) work to guard against that concern >> by factoring some initialization code into a method of its own, to be >> called from wrappers around the various interface methods. >> >> Regards, >> -Chap >> > --0000000000000a339705ab853fd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 28, 2020 at 11:53 PM Kartik O= hri <kartikohri13@gmail.com> wrote:
On 07/27= /20 06:45, Kartik Ohri wrote:
> Hi! The initial version of the javadoc mojo is ready. I have pushed th= e
> changes. For now, I have just exposed a function using which arguments=
> could be added to the javadoc tool. I also wrote some script for makin= g the
> tool work. The javadoc tool works for pljava-api but not for pljava. I= am
> trying to=C2=A0 debug this. It also works for PL/Java Examples. I have= hardcoded

That looks like a good start. I wonder if the explicit start of a subproces= s
could be replaced with javax.tools.ToolProvider.getSystemDocumentationTool(= )
and the corresponding API.
I have made the switch from= ProcessBuilder to ToolProvider and pushed the changes. The usage is fairly= simple as only a list of arguments is required to be passed to the tool.= =C2=A0
I think that could be simple enough to just directly use from the
JavaScript, which would mean the mojo would not have to be called
JavadocMojo or have Javadoc-specific functionality built in. It could
concentrate on being a plugin that allows scripting of new reports in
general to run in the site lifecycle.
For now, I have = kept the procedure the same but using the ToolProvider API is indeed very s= imple and requires only a couple of lines of code. So, we can move=C2=A0tho= se entirely to the script and make the mojo completely agnostic to what it = does as you suggest. I'll try this and let you know how it goes.=C2=A0<= /div>
I tried this and it works well (except f= or the pljava module which was anyways crashing in the previous way as well= ). Please take a look at the latest changes and let me what other modificat= ions are required.
<= div dir=3D"ltr">
> I did not try to go the interface route yet because I am not sure of t= he
> order in which maven calls these methods. Because if maven calls these=
> methods before the executeReport method it would be of no use.

It might (or, then again, might not) work to guard against that concern
by factoring some initialization code into a method of its own, to be
called from wrappers around the various interface methods.

Regards,
-Chap
--0000000000000a339705ab853fd3--