Subject: Re: PL/Java new build plugin
To: Kartik Ohri <kartikohri13@gmail.com>
References: 
 <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@mail.gmail.com>
 <CAASLQ4PjzGVCj559r60Kw7i3uRUTzJraxBSDDsNtAt8v8_-oWQ@mail.gmail.com>
 <5F1664C5.2070700@anastigmatix.net>
 <CAASLQ4PeivyN6DkBPbgYTZmoqoOVdCDwinDFrREsXqZi2HQnWg@mail.gmail.com>
 <5F1735ED.6020707@anastigmatix.net>
 <CAASLQ4Off+PnB8FqKLokKjAkvKbW00=fjH_LxuYJOGp0_C1YAw@mail.gmail.com>
 <CAASLQ4PcU=P4ShuMJOEnQj6p7ZU0VcgJ9St6PMpXcNB_1jPQ+w@mail.gmail.com>
 <5F1753C9.4060500@anastigmatix.net>
 <CAASLQ4P_v7u5z76XWfPmVeBvQtNdraiN0MmsRRfq-eNh1O1aTA@mail.gmail.com>
 <5F175F40.1000905@anastigmatix.net>
 <CAASLQ4Ouw1hCHVtSC5XG7Fb-GoO0YAf4_PwsQc=22CvEzhQo6g@mail.gmail.com>
 <CAASLQ4MfBz2zj5gm-t+OX-8puxJvf8bSneKeUG+NuX=+CbYCLw@mail.gmail.com>
 <5F18C58F.8060204@anastigmatix.net>
 <CAASLQ4NkEDo-UAmqSwUTkCdMu+3WedKCfva5gzNTC45YcWEwNA@mail.gmail.com>
 <5F19C36C.70905@anastigmatix.net>
 <CAASLQ4M_f8cYmxfX5Jqgm9AJHsX62_Cc5pvniXjer4jAZOMOBQ@mail.gmail.com>
 <CAASLQ4Pcp24U3rkWkGvcidTfCLQEsAE1it7b3Sr_uNbgO3P9kA@mail.gmail.com>
Cc: pljava-dev@lists.postgresql.org
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <5F1C6F06.2020809@anastigmatix.net>
Date: Sat, 25 Jul 2020 13:42:30 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
 <CAASLQ4Pcp24U3rkWkGvcidTfCLQEsAE1it7b3Sr_uNbgO3P9kA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 07/25/20 12:54, Kartik Ohri wrote:
> I have been going through the maven javadoc plugin's source. It is huge and
> is over 6000 lines. Thankfully, most of it is customization things we can
> avoid. I saw that the current configuration for maven javadoc has
> exclude parameters in the pom.xml file. Now, maven uses a DirectoryScanner
> to help out with the excludes which is available as a package in maven
> shared utils. I am unable to think of a way to handle excludes with the
> inbuilt Java APIs. Should I utilise DirectoryScanner or do you have any
> other suggestions?

I honestly want something without any of that jazz at all.

The bare javadoc tool does the right thing if run with defaults and
pointed at the module descriptor.

All the pain of 5ee9b6b and 395ac0d involved finding any possible way
to prevent the maven-javadoc-plugin from making the javadoc tool do
the wrong thing.

Running the tool the right way shouldn't take more than 5 lines of JS.

A MavenReport plugin will also need to send some information to the
Doxia Sink to get the basic report page made with a link to the javadoc;
that part might take more than 5 lines of script but I'd be surprised
if more than 15.

Literally, if a mojo implements MavenReport (or extends AbstractMavenReport)
and makes the right objects available to the script engine, I don't think
much else would be needed.

I did some playing around with javax.script.Invocable (which the JS
engines implement). You can define an interface with some instance
methods, and ask the engine for an instance of it, and if the script
defined the right functions, you get a usable-in-Java implementation
of that interface, which works by calling the script functions.

You can even define an interface that has some default methods, and
it can be instantiated as long as the script defined the functions
that are needed. If the script also defines a function corresponding
to a default method, that gets used too. It works very much as one
would guess.

(I did a big double-take when I noticed you could have an interface
with a default method, get an instance from the script engine, then
eval another script that defines the missing function, and after that
the Java instance you already had starts using the script function
instead of the default!)

That might be useful for this purpose, as a MavenReport has a bunch
of methods (getName, getCategoryName, canGenerateReport,
isExternalReport, etc.) that could be given reasonable defaults for
most cases, but maybe a script should be able to override.
MavenReport itself might not be the exact right interface to use
(the mojo itself should implement that, or extend AbstractMavenReport),
but maybe the mojo should declare a similar interface with a subset
of those methods, and have that be what the script block should
be able to supply).

Regards,
-Chap