Bug#866845: libidw-java FTBFS: PropertyMapImpl.java:383: error: unmappable character for encoding ASCII

[tony mancill]

On Mon, Jul 03, 2017 at 12:51:27PM +0200, Emmanuel Bourg wrote:
> Le 3/07/2017 à 11:48, Markus Koschany a écrit :
> 
> > So if I understand correctly all pure javahelper packages are safe as
> > long as they have defined the encoding already?
> 
> Yes, but I'm under the impression that no javahelper based package does
> so (a code search on "JH_JAVADOC_OPTS" returns only javatools).
> 
> > I don't understand the maven-debian-helper case though. The
> > project.build.sourceEncoding in my maven.properties file won't override
> > the new default UTF-8 value anymore?
> 
> I'm not sure about that. I just know that the command line parameter
> overrides the property in pom.xml.
> 
> Note that if maven.properties could override the property set by
> maven-debian-helper, we would have many cases where maven-debian-helper
> sets the encoding to UTF-8, the pom.xml sets the encoding to ISO-8859-1
> (but is ignored), and we would have to add the encoding in
> debian/maven.properties to ensure it still compiles. That would be
> counter-productive since upstream already configured the encoding properly.

Hmm... I can see the predicament.  Ideally, we would have a test to only
provide a default if the encoding wasn't already configured somewhere in
the build toolchain.  As an alternative, could we detect that javac or
javadoc is running without -encoding and fail the build?  (Or at least
warn prominently?)  This would be akin to a policy that an encoding must
be specified.

In event, I'm also strongly in favor of UTF-8 as default if we can
provide one, and I am willing to help with a conversion if we need it.

Cheers,
tony
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20170703/a4f73a6e/attachment-0001.sig>