Incompatbility with qrcode.jar 1.8 due to changed qrcode.encodeText method signature

[Kusig]

Updated to qrbill 3.0.2 which as well uses qrcode library 1.8 in maven dependency.

Now I do get an exception in QRCode.draw(..) method that the method QrCode.encodeText could not be evaluated and called.

The method signatures within QRCode.encodeText() and others did change recently from String to CharSequence and this seems now to cause the problem because the method is called with the embeddedText string type instead.

Side note: I'm using the library within Jasper with Java 1.8

[yelhouti]

Facing the same issue here, maybe you could use a fixed version here: https://github.com/manuelbl/SwissQRBill/blob/58866aae85ad9d3cb350dd190dd5fc99f06c57f4/generator/build.gradle#L137

Workaround until this is fixed:

compile "net.codecrete.qrbill:qrbill-generator:3.0.2"
    constraints {
        implementation('io.nayuki:qrcodegen:1.7.0') {
            because '1.8.0 contains a breaking change: io.nayuki.qrcodegen.QrCode.encodeText(java.lang.String, io.nayuki.qrcodegen.QrCode$Ecc) not defined'
        }
    }

[manuelbl]

Thanks for reporting this. And thanks for the workaround. I would have recommended the same workaround.

It was aware that a new version of the QR code library has been released this weekend. But I didn't expect any breaking changes as the major version number wasn't increased. I will investigate the best long-term remedy.

[manuelbl]

Contacted author of QR code library: https://github.com/nayuki/QR-Code-generator/issues/139

[saw303]

@manuelbl would it be better to declare a fixed version instead of relying to a semantic versioning range [1.6.0,1.999999]?

having ranged versioning makes builds hard to be reproducable. Or what is the intension by declaring ranges?

[manuelbl]

If an application uses the QR code library multiple times, e.g. indirectly via the Swiss QR bill library and also directly, locking the version number can be a disadvantage. The Swiss QR bill library would prevent (or at least make it difficult) to use a newer version of of the QR code library, which might include a required new feature.

Locking the version is also a problem if a security fix is released for the QR code library. Applications would not be able to easily upgrade. A new version of the Swiss QR bill library would be needed first.

But it of course all depends on library maintainers applying semantic versioning correctly...

[Kusig]

Here's the maven equivalent working as expected (or as before):

<dependency>
  <!-- https://github.com/manuelbl/SwissQRBill -->
  <groupId>net.codecrete.qrbill</groupId>
  <artifactId>qrbill-generator</artifactId>
  <version>3.0.2</version>
  <exclusions>
     <!-- The following lib is excluded and sticky defined before due to an incompatible new version -->
     <!-- https://github.com/manuelbl/SwissQRBill/issues/60 -->
     <exclusion>
        <groupId>io.nayuki</groupId>
        <artifactId>qrcodegen</artifactId>
    </exclusion>
  </exclusions>
</dependency>
<dependency>
  <groupId>io.nayuki</groupId>
  <artifactId>qrcodegen</artifactId>
  <version>1.7.0</version>
</dependency>

[saw303]

@manuelbl thank you for explaining. I understand the motivation and I don't want to start a debate about it. Don't get me wrong on this.

Isn't this issue demonstrating a huge downside of declaring version ranges? I mean due to an incompatible release of one of the transitive dependencies, the previously working release of the SwissQRBill doesn't work anymore or requires the workarounds for the consumers of SwissQRBill. From a library perspective this is an undesired situation.

But as mentioned. I don't wanna start a debate since I'm super happy that I found this open source project, that helps me a lot. Pointing out things is just a way of contributing.

[saw303]

@manuelbl would it be an option for you to recompile SwissQRBill and release a version 3.0.3? Or even better lock the version number of the transitive dependency?

[Kusig]

From my personal experience it is better to make dependencies sticky instead of version ranges. If one want, it could easily just overwrite the dependency with a new one by need anyhow as we do now but just the opposite way. The advantage having a predictable and stable build over long time weights more I think.

[manuelbl]

A new version of the library has been released. It fixes the versions of the two main dependencies: PDFBox and QR-code-generator. It should appear on Maven Central within a few hours.

[saw303]

@manuelbl I can confirm that the new version 3.0.3 works correctly with qrcodegen 1.8.0. Thank you for the quick fix. I guess this issue can be closed for now.

[Kusig]

Confirmed as well. Works perfectly again. Thanks very much.