Differences between classmate 1.3.4 and 1.5.1

[Mantas Gridinas]

Yo!

I'm trying to resolve my dependency tree issues using maven enforcer plugin and I've come into a bit of a pickle. Enforcer plugin reports the following:

```

Dependency convergence error for com.fasterxml:classmate:1.5.1 paths to dependency are:
+-lt.saltyjuice.dragas:discord-tournament-accepter:2.2.0-SNAPSHOT
  +-lt.saltyjuice.dragas:discord-core:2.2.0-SNAPSHOT
    +-org.hibernate:hibernate-core:5.4.15.Final
      +-com.fasterxml:classmate:1.5.1
and
+-lt.saltyjuice.dragas:discord-tournament-accepter:2.2.0-SNAPSHOT
  +-lt.saltyjuice.dragas:eternal-witness-validator-api:2.2.0-SNAPSHOT
    +-org.hibernate.validator:hibernate-validator:6.1.5.Final
      +-com.fasterxml:classmate:1.3.4
```

As the snippet shows, I depend on both hibernate-core and hibernate-validator. The validator version depends on 1.3.4 version while actual hibernate depends on 1.5.1. Is it safe to exclude the 1.3.4 dependency and force validator depend on the newer version? In addition, does the java module name differ between the two versions, in case hibernate-validator or hibernate-core depend on classmate's module name? (Not that it matters for hibernate-core because it's an automatic module, as seen by their POM...)

Cheers.

[Tatu Saloranta]

On Wed, Jul 29, 2020 at 7:30 AM Mantas Gridinas <mgri...@gmail.com> wrote:
>
> Yo!
>

Hi there!

So, first, yes, 1.3.4 and 1.5.1 APIs should be compatible enough
(project does follow SemVer), so anything that works against 1.3.4
should work with 1.5.1 too (reverse may or may not work as minor
versions add functionality but chances are even downgrade would work).

As to module name... 1.3.4 added "Automatic Module Name" for simplest
compatibility with module system;
but 1.5.1 added full module-info (using Moditect plug-in). But both
define module name as "com.fasterxml.classmate",
no change between versions, so it might just work; however, my
knowledge about workings of Java module system is quite limited.
I know there are some differences between jars that only define
Automatic Module Name, and those with full module-info.class.

-+ Tatu +-

[Mantas Gridinas]

Do you have plans to move to module-info.java declaration from
moditect plugin? In case I remember correctly (though this might be
outdated by now), moditect prevented usage of jlink tool, which
produces a minimal java development kit + your dependencies archive,
provided that you don't depend on automatic modules.

See: https://docs.oracle.com/en/java/javase/11/tools/jlink.html

> --
> You received this message because you are subscribed to the Google Groups "java-classmate-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to java-classmate-u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/java-classmate-users/CAL4a10id2_76js1YCVMY2n%2BpF5KUKPvicgMJ_PJFgoPgm9LTNw%40mail.gmail.com.

[Tatu Saloranta]

On Thu, Jul 30, 2020 at 11:58 AM Mantas Gridinas <mgri...@gmail.com> wrote:
>
> Do you have plans to move to module-info.java declaration from
> moditect plugin? In case I remember correctly (though this might be
> outdated by now), moditect prevented usage of jlink tool, which
> produces a minimal java development kit + your dependencies archive,
> provided that you don't depend on automatic modules.
>
> See: https://docs.oracle.com/en/java/javase/11/tools/jlink.html

Since I think that would require increasing the minimum JDK
requirement from Java 6 to Java 11, no,
I have no plans to do that. Moditect allows build using JDK 8 (and
targeting even earlier versions) which is
the main selling point.

But I did not think moditect-generated module-info should prevent use
of JLink; I thought it has been used
successfully with Jackson which also uses Moditect for module-info
inclusion (for similar reasons).

-+ Tatu +-