Commit message (Collapse) | Author | Age | Files | Lines | |
---|---|---|---|---|---|
* | Initial move to SnakeYAML Engine | Charles Oliver Nutter | 2023-01-13 | 1 | -1/+1 |
| | | | | | | | | | | | | | | | See jruby/jruby#7570 for some of the justification for this move. We only require the parser from SnakeYAML, but in the original form it is encumbered with Java object serialization code that keeps getting flagged as a CVE risk. We disagree with the assessment, at least as it pertains to JRuby (we do not use the code in question) but our inclusion of the library continues to get flagged by auditing tools. This commit starts the process of moving to the successor library, SnakeYAML Engine. The parser API is largely unchanged, except as seen in this commit. No Java exceptions are thrown, but a number of Psych tests fail (possibly due to Engine being YAML 1.2 only). | ||||
* | no need to supply jruby itself to the classpath | Christian Meier | 2015-05-28 | 1 | -2/+0 |
| | |||||
* | little ruby-maven related improvements | Christian Meier | 2015-05-06 | 1 | -1/+1 |
| | | | | | * pass in the snakeyaml.version via the commandline * use the jruby version which runs rake for the java compilation as well | ||||
* | setup java platform gem | Christian Meier | 2015-02-26 | 1 | -0/+9 |
use maven to resolve jar dependencies for compilation. setup jar-dependencies to install the snakeyaml jar when installing the gem via rubygems or bundler. added java code to reflect the snakeyaml vesion which got finally loaded into the jruby-classloader. |