pkm-api issueshttps://gitlab.ow2.org/decoder/pkm-api/-/issues2021-09-16T07:12:58Zhttps://gitlab.ow2.org/decoder/pkm-api/-/issues/2Add a notion of transaction?2021-09-16T07:12:58ZVirgile PrevostoAdd a notion of transaction?the pkm-api insertion and update scripts tend to perform several database operations (insertions/deletions/updates). Thus, if something goes wrong in the middle of the script, the database may be left in an incoherent state. Normally, do...the pkm-api insertion and update scripts tend to perform several database operations (insertions/deletions/updates). Thus, if something goes wrong in the middle of the script, the database may be left in an incoherent state. Normally, doing an update again should take care of that, but it might be good to add a notion of transition at some point.
Note however that transitions seems to have appeared only in MongoDB 4.0Armand PUCCETTIArmand PUCCETTIhttps://gitlab.ow2.org/decoder/pkm-api/-/issues/23Provide releases for production deployment (and API versioning)2021-11-05T17:16:12ZPierre-Yves GibelloProvide releases for production deployment (and API versioning)The PKM is currently deployed in production on a server at OW2, and the development goes on.
It seems impossible to guess which version of the API is running on the production server, and if it is compatible or not with the latest devel...The PKM is currently deployed in production on a server at OW2, and the development goes on.
It seems impossible to guess which version of the API is running on the production server, and if it is compatible or not with the latest development version.
Releases with stable APIs are necessary: only tagged releases should be deployed on the production server(s).https://gitlab.ow2.org/decoder/pkm-api/-/issues/25OpenJml tool: dependency resolution errors2021-09-16T07:33:20ZPierre-Yves GibelloOpenJml tool: dependency resolution errorsOpenJml tries to resolve external dependencies (packages and classes), and they are probably not in the classpath: it is a problem of integrating OpenJml with the tool, as it requires access to the whole java project classpath (and not j...OpenJml tries to resolve external dependencies (packages and classes), and they are probably not in the classpath: it is a problem of integrating OpenJml with the tool, as it requires access to the whole java project classpath (and not just one file).
Moreover, this includes internal and external dependencies: the dependency tree may have to be download (using maven and/or other build mechanism(s) ?).
Concerning internal dependencies, scanning the whole project would be sufficient: or even trying to guess which files to scan - at least, imports + current package ?
The way OpenJml itself resolves dependencies is (scarcely) described here:
http://www.openjml.org/documentation/paths.shtml
Example of OpenJml errors returned by OpenJml tool (these ones concern internal dependencies: one package import, and one class reference), as stored in "Logs" PKM collection:
```
{
"_id" : ObjectId("606eb767bbf80a0042e4b707"),
"tool" : "OpenJML typeChecking",
"details" : {
"numberOfErrors" : 2,
"numberOfWarings" : 0
},
"status" : true,
"type" : "Log",
"messages" : [
"java%2Fmtsj%2Fapi%2Fsrc%2Fmain%2Fjava%2Fcom%2Fdevonfw%2Fapplication%2Fmtsj%2Fbookingmanagement%2Fcommon%2Fapi%2Fto%2FBookingCto.java Downloaded Succesfully!",
"OpenJML Analysis Success!",
"OpenJML Results Parsed Success!"
],
"warnings" : [],
"errors" : [
{
"line" : 9,
"messageType" : "Error",
"sourceCode" : "import com.devonfw.module.basic.common.api.to.AbstractCto;",
"description" : " package com.devonfw.module.basic.common.api.to does not exist"
},
{
"line" : 14,
"messageType" : "Error",
"sourceCode" : "public class BookingCto extends AbstractCto {",
"moreInfo" : "symbol: class AbstractCto",
"description" : " cannot find symbol"
}
],
"nature of report" : "OpenJML Analysis report",
"start running time" : ISODate("2021-04-08T07:57:25.000Z"),
"end running time" : ISODate("2021-04-08T07:57:27.000Z")
}
```
Note: the current Dockerfile for OpenJml tool includes hard-coded download of dependencies for a specific demo scenario: this has to be replaced by a generic mechanism applicable to any project.https://gitlab.ow2.org/decoder/pkm-api/-/issues/30Frama-C bogus column numbers in source code locations2021-10-22T06:01:35ZGilles MouchardFrama-C bogus column numbers in source code locationsFrama-C generates out-of-range column numbers (pos_cnum) in source code locations: e.g. 106170.Frama-C generates out-of-range column numbers (pos_cnum) in source code locations: e.g. 106170.Armand PUCCETTIArmand PUCCETTI