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 1k0UGn-00029X-73 for pljava-dev@arkaria.postgresql.org; Tue, 28 Jul 2020 18:24:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1k0UGm-0002Uy-74 for pljava-dev@arkaria.postgresql.org; Tue, 28 Jul 2020 18:24:08 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k0UGl-0002Ur-Ul for pljava-dev@lists.postgresql.org; Tue, 28 Jul 2020 18:24:08 +0000 Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1k0UGj-00046q-Ge for pljava-dev@lists.postgresql.org; Tue, 28 Jul 2020 18:24:07 +0000 Received: by mail-ej1-x633.google.com with SMTP id w9so21605070ejc.8 for ; Tue, 28 Jul 2020 11:24:05 -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=KpGGunX7yE0z2eNBXVQSBhxGYQs+M7DkVR2Dyw45CUs=; b=Ad9WAvdYhOzPR9OgNBAEF+MRY/cOZXqPO+EhBxgO6+CNpO/iBFhUkjLX3xW4ZUljvS xKxl41ZjkuWQ5yDFr8i5Z9bPgkYO9LYxbpqps90baESnnAaFXcf1zBqXGQSpcv7vPHuj RJtlb7bRLNwqzFa0vJCZdO/xUiHKmf1msKq8ti6dteMphitgtDb67Fo2Q4s8Dh/TAWNn 14TPor+NMDsuzdERsZ9W5VYefH0s+zBVIz15yG87zq2VsnAkqwyhmtcMfXPk57A5Iey/ /pXFFE82Ba4TH26ULT5mPbVd/glD1G4hybTGOu7aJ6d7D9Izj8WQf0F887uwcwAUICH1 zf/Q== 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=KpGGunX7yE0z2eNBXVQSBhxGYQs+M7DkVR2Dyw45CUs=; b=P7WGXsMptEdm7xppvYtyUUd5zdot+sNLa2SGQk/56dHgovFREmw6F8DrLM/rdYX/f2 bYcsZ3YdFcPy3LQ6W57wADqrUcOqfSE6an+7h9XkBiE7Mxe0bSL3QBeFC4VUxAGRnnrZ vaHoZcuW9CaaHdFoo5MdtaAahl6dWGePypmI0oPZr0ePINM0l7fRy5y3Sk7YPjqKJlBk 4Ti/oiJgMcVKjjdoQFFUMuPRhhPJy1He7Vvy+76zcjY5m9YAkMuh9bBgJhmCqwHEUY7E 1c81V0ltfWl5+9K05qdhOpazElQmtsspMbzoXiaWTRDCKjiUuPwr5h22+la4ZbPTPkmQ +/+A== X-Gm-Message-State: AOAM531zyYR2u+S7hcIhlgOSTLS0JsguqT9NKH1Lej0JoLYLMgCV/DJk l3BD2lNMhUYc6qXj7peryQJBMxwRdsfxgEkELbeGxIQx X-Google-Smtp-Source: ABdhPJzFNBhiWPQa0I0MFLjfWF91NZu0U/ivuSJ3nWumepIXkZ0NQJnmsnqPB3OEXg/7IR0G6ctf3rz6VmR9b3vRPUU= X-Received: by 2002:a17:906:2296:: with SMTP id p22mr26121292eja.510.1595960643938; Tue, 28 Jul 2020 11:24:03 -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: <5F1F88E0.2050305@anastigmatix.net> From: Kartik Ohri Date: Tue, 28 Jul 2020 23:53:49 +0530 Message-ID: Subject: Re: PL/Java new build plugin To: Chapman Flack Cc: pljava-dev@lists.postgresql.org Content-Type: multipart/alternative; boundary="00000000000041eb1105ab848b35" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --00000000000041eb1105ab848b35 Content-Type: text/plain; charset="UTF-8" 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 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 > --00000000000041eb1105ab848b35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 28, 2020 at 7:39 AM Chapman F= lack <chap@anastigmatix.net= > 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 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
--00000000000041eb1105ab848b35--