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-30 20:13:41 |
Message-ID: | CAASLQ4Ny+VWWH=_AR+=7gjXinUScybraOJxBUaG5AmLZmx+NPQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pljava-dev |
>
> 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.
>
I saw you had used project.build.sourceEncoding which is the default value
of inputEncoding [1]. Only if this value is null, the getInputEncoding
method returns ReaderFactory.FILE_ENCODING [2]. But since javadoc is not
complaining in the current implementation, the null case does not
apply. So, this will be probably redundant. A similar argument for output
encoding, it uses a different value which can also be interpolated directly
in the pom. Should I still expose public methods calling these ?
[1] :
https://maven.apache.org/shared/maven-reporting-impl/xref/org/apache/maven/reporting/AbstractMavenReport.html#L86
[2] :
https://maven.apache.org/shared/maven-reporting-impl/xref/org/apache/maven/reporting/AbstractMavenReport.html#L303
Regards,
Kartik
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2020-07-30 20:34:03 | Re: PL/Java new build plugin |
Previous Message | Chapman Flack | 2020-07-30 17:28:23 | Re: PL/Java new build plugin |