Re: PL/Java new build plugin

From: Kartik Ohri <kartikohri13(at)gmail(dot)com>
To: Chapman Flack <chap(at)anastigmatix(dot)net>
Cc: pljava-dev(at)lists(dot)postgresql(dot)org
Subject: Re: PL/Java new build plugin
Date: 2020-07-28 18:23:49
Message-ID: CAASLQ4PyG-YvKUTYdqfuQW8yGL+t_93b1i2CMTusoYHbZ0ZTMg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

On Tue, Jul 28, 2020 at 7:39 AM Chapman Flack <chap(at)anastigmatix(dot)net> 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
>

In response to

Responses

Browse pljava-dev by date

  From Date Subject
Next Message Kartik Ohri 2020-07-28 19:14:07 Re: PL/Java new build plugin
Previous Message Chapman Flack 2020-07-28 02:09:36 Re: PL/Java new build plugin