search

luhenry / netlib

An high-performance, hardware-accelerated implementation of Netlib in Java
Other
64 stars 12 forks source link

Automatic Module Name for arpack_combined_all #22

Open uhoefel opened 1 year ago

uhoefel commented 1 year ago

Currently, the only transitive dependency is 

<dependency>
  <groupId>net.sourceforge.f2j</groupId>
  <artifactId>arpack_combined_all</artifactId>
  <version>0.1</version>
</dependency>

This is also the only dependency java complains about if one uses the module system, as it has no automatic module name. In principle, I think the fix is quite easy: One can just add 

Automatic-Module-Name: <whatever.stable.name.picked>

to META-INF/MANIFEST.MF in arpack_combined_all-0.1.jar. This would be backwards compatible, except for projects that already use JPMS (they would have to change their requires clause, but then, at least it would be a stable name and no more warnings). If the chosen stable name matches the name based on the jar there would be no backwards incomatibility, but this is unsafe as there is no control over the domain.

Now, I could easily upload that myself, but I think it would be nicer if it would be under the same "umbrella" (dev.ludovic...) as netlib.

Is that an option at all? If yes, should I upload it in my namespace (and would you be willing to switch to this dependency?) or would you upload it in yours?

Edit: It is also worth thinking about whether exposing types from arpack_combined_all is future-proof anyway. I think this package was uploaded ten years ago, and the code it contains is even from 2008 or something like this, so clearly not maintained. Maybe it would be good to wrap the exposed types and just use the types from arpack_combined_all internally (intW and the like)?

Syyllinen commented 1 year ago

Related to above, there might also be licensing issue with arpack_combined_all:0.1

When you download this artifact from Maven central https://repo1.maven.org/maven2/net/sourceforge/f2j/arpack_combined_all/0.1/ and extract it, you can find org/j_paine/formatter/CJFormat.class file and the assumed source code file of this Java class is https://github.com/barak/f2j/blob/master/jlapack-3.1.1/src/util/org/j_paine/formatter/CJFormat.java#L8

CJFormat.java file has following License:

  • Permission to use, copy, modify, and distribute this
  • software and its documentation for NON-COMMERCIAL purposes
  • and without fee is hereby granted provided that this
  • copyright notice appears in all copies.

So maybe it would be best to get rid of this transitive dependency once and for all.