You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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)?
The text was updated successfully, but these errors were encountered:
Currently, the only transitive dependency is
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
to
META-INF/MANIFEST.MF
inarpack_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 fromarpack_combined_all
internally (intW
and the like)?The text was updated successfully, but these errors were encountered: