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
I would like to see the Repast system become a properly defined Java module with module-info.txt specifying the modules that Repast depends on and the packages that it exports.
That may be a difficult hurdle, so if it is necessary as an interim step, it may be appropriate to have Repast define an automatic module name.
Note that becoming modular would entail removing any split packages. I am not aware of many issues with split packages, but there may be some problems related to the javax.measure package, which is mostly obtained from a dependency but also has a class defined in the repast.simphony.bin_and_src.jar archive.
The text was updated successfully, but these errors were encountered:
I would recommend upgrading the dependency on org.geotools jars as part of this process. We found that release version 21.2 of geotools provides an automatic module name, while version 19.1 does not. This change would also entail migrating from uses of com.vividsolutions.jts.* in your API to uses of org.locationtech.jts.*, a change that came in version 20.x of geotools.
I would like to see the Repast system become a properly defined Java module with module-info.txt specifying the modules that Repast depends on and the packages that it exports.
That may be a difficult hurdle, so if it is necessary as an interim step, it may be appropriate to have Repast define an automatic module name.
Note that becoming modular would entail removing any split packages. I am not aware of many issues with split packages, but there may be some problems related to the javax.measure package, which is mostly obtained from a dependency but also has a class defined in the repast.simphony.bin_and_src.jar archive.
The text was updated successfully, but these errors were encountered: