Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Automatic Module Name for arpack_combined_all #22

Open
uhoefel opened this issue Nov 1, 2023 · 1 comment
Open

Automatic Module Name for arpack_combined_all #22

uhoefel opened this issue Nov 1, 2023 · 1 comment

Comments

@uhoefel
Copy link
Contributor

uhoefel commented Nov 1, 2023

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
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants