https://github.com/apache/incubator-seata/issues/5781 Based on the problem described in this issue, the sqlparser module does not need to deal with compatibility issues. In theory, starting from the version with DruidIsolationClassLoader, the spi extended by the user will be invalid. Yes, unless packaged into seata-all, if it can be packaged into seata-all, the source code must be compiled, and the source code can be compiled. In theory, it is not difficult for them to change the package path. So the compatibility issue theory of ioseata's sqlparser No processing is required.
Jianbin Chen, githubId: funky-eyes yixia <[email protected]> 于 2024年3月8日周五 21:59写道： > Most of the apache package compatibility migration has been completed and > needs to be reviewed. > > There are 10 folders in total. > > [image: image.png] > > Min Ji is responsible for the common, config, core, and discovery folders; > Te Wang responsible for the non-datasource modules, spring folder, and > saga folder in the rm folder; > funky-eyes is responsible for the datasource module, sqlparser folder, tm, > and integration folder in rm > > In addition, regarding SPI compatibility, we have reached the following > consensus. I am also responsible for this part of the work: > > 1) Our compatible scope is the SPI that users may use > 2) Most of the io.seata compatible interfaces should inherit the interface > of apache seata > 3) We will load all implementations of all apache.seata and io.seata > interfaces. The scenario io.seata with the same name covers the > implementation of apache.seata, and the log reminds >
