Re: PL/Java new build plugin

On 07/30/20 11:37, Kartik Ohri wrote:
> To clarify, I have exposed the instance and written the snippet using
> Doxia sink to generate the html file in the pom.xml. I meant that we could
> factor out the sink part in a default method in an interface and expose it
> to javascript for providing an alternate implementation if wanted. It is
> this part I am unsure of how to do.

Ah, got it.

Right now, nothing is jumping out at me as an obvious way to supply a
default implementation for a generic report. (Not even thinking of the
mechanics of doing it just now, only the wider question of what such a
default method would do.) I would say that's a bit of refactoring that
isn't needed now, but some future day if there has been some experience
using the mojo to script both Javadoc and some other sort of report,
what turns out to be common between those uses might supply ideas for
a refactoring then.

I am a little disappointed that the Sink methods return void instead of
the sink, so they can't be used fluently; if I were looking for one
simple way to make the script snippet end up prettier, I might consider
writing a wrapper class that's like Sink but with methods returning this,
so the script can be written in a fluent style.

However, writing such a wrapper for an interface with nearly 200 methods
sounds like a job for an extremely boring rainy day, definitely not a
priority for right now.

If I were writing such a wrapper, I might also consider wrapping each
foo()/foo_() pair of start/end methods as a single method that takes
a lambda generating the content inside, so misnesting would not be
possible. (If I'm not mistaken, there's a bit of misnesting in your
snippets, sectionTitle_ before link_ ... a nicer API would leave no
need to think about that.)

But probably there are better areas to polish right now. A generic
scripting mojo can't really know "you're going to want the jar path
for a dependency named pljava-api, I'll put that in a variable for you";
it just needs to expose some way to get the project object so the
script can do such lookups.

I am probably also passing the Javadoc -d option the wrong way
(hardcoding ${basedir}/target/site/apidocs). Probably should just
tack on "apidocs" to report.getReportOutputDirectory() (using something
like toPath().resolve("apidocs") so the tacking-on is platform-aware.

Likewise, what I was passing to -encoding and -docencoding
should probably come from report.getInputEncoding() and
report.getOutputEncoding(), respectively. All that should
be straightforward with the report instance exposed.

Hmm, but those encoding methods are protected; the script might not
have access. Accessible versions might have to be supplied.

Regards,
-Chap