Re: PL/Java new build plugin

On Tue, Jul 28, 2020 at 11:53 PM Kartik Ohri <kartikohri13(at)gmail(dot)com> wrote:

> 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 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
>>
>