eiffel-community / eiffel-remrem-semantics Goto Github PK
View Code? Open in Web Editor NEWeiffel-remrem-semantics
Home Page: https://eiffel-community.github.io/eiffel-remrem-semantics/
License: Other
eiffel-remrem-semantics
Home Page: https://eiffel-community.github.io/eiffel-remrem-semantics/
License: Other
Given the security compliance , REM component should adhere to it.
Applicable dependencies:
Uplift of gson to 2.8.9 or later
Uplift of Jackson-databind to 2.13.3
Or more If required
Acceptance Criteria:
All security related components uplifted to the latest versions.
Test cases verified for the changes done
Function test cases verified for the changes done.
To overcome security issues
Vulnerability free code
In the template for TCT The field recipeId does not say that it's required, although it is. The template should be updated so that it is clear.
It's hard to create an event from the template since the field is required but not stated that it is.
Today eiffel-remrem-semantics library doesn't define a unit test validating generated templates.
Lack of the test caused that event version mismatch was overlooked, see eiffel-community/eiffel-remrem-generate#203.
Existence of the test prevents version mismatch between event schema and corresponding generated event.
No drawbacks identified.
Running mvn clean install -P generate-events
to generate new POJO classes will remove the copyright header in all files. Given the number of affected files it's very annoying to have to skip through those changes. We should either we rid of the copyright header or make sure the file generation prepends the generated files with the desired header.
Updating this repository as the protocol changes shouldn't be hard or require additional manual steps that can be automated.
N/A
Easier to update schemas, decreased risk of mistakes.
None.
Today the various versions are released with the same major release, so making it difficult to fix the issues identified on a protocol edition.
We have issues with older edition that needs to be addressed and we cannot upgrade to latest edition of protocol yet.
If we have branching strategy we know that the releases will be based on protocol editions and easy to fix and deliver.
Without the branching strategy it is difficult to align on the fixes needed to be applied on certain protocol editions
The Orizaba edition of the Eiffel protocol has been released and REMReM should be updated to that edition. All events have been updated in that edition.
The Orizaba edition includes a few interesting changes that we'd like to be able to use with REMReM.
N/A
REMReM clients get access to the latest event versions.
None. The changes in Orizaba are backwards compatible.
The library contains event template files (in src/main/resources/templates
) and they don't reflect changes to event schemas (in src/main/resource/schemas/input
). The templates were created for version Agen and it seems nobody touched them any more.
The event templates should match corresponding event schemas. At least one user encounter the issue: eiffel-community/eiffel-remrem-generate#203.
Result obtained from getEventTypeTemplate()
(endpoing /template/{type}/{mp}
) cannot be used as an input to generate()
(endpoint /{mp}
).
Event templates are in sync with event schemas.
None known.
REMReM-semantics doesn't add the default domain id if not provided by the user.
This improvement has to add the default domainId if its not available
If there is no domainId present in the event, REMReM semantics has to add the default domainId
Even in the case of User is not provided the domainId REMReM-semantics will add the default domainId
None
Need data and Links information in the Event class that can be used to fetch information about the events.
The Paris edition of the Eiffel protocol has been released (see eiffel-community/eiffel#253) and REMReM should be updated to that edition. The CD and ArtP events have been bumped from 3.0.0 to 3.1.0.
The Paris edition includes a few interesting changes that we'd like to be able to use with REMReM.
We have a need to publish artifact events for multi-file artifacts and support for that wasn't introduced until the Paris edition of the protocol.
REMReM clients get access to the latest event versions.
None. The changes in Paris are backwards compatible.
REMReM generate does not accept the link types FAILED_ISSUE, INCONCLUSIVE_ISSUE, or SUCCESSFUL_ISSUE in the EiffelIssueVerifiedEvent.
The validation fails when adding those link types to an EiffelIssueVerifiedEvent, and gives the following error message:
{
"message": "Cannot validate given JSON string",
"cause": "com.ericsson.eiffel.remrem.semantics.validator.EiffelValidationException: FAILED_ISSUE,INCONCLUSIVE_ISSUE,SUCCESSFUL_ISSUE link types are invalid for the event EiffelIssueVerifiedEvent"
}
I expect REMReM to validate according to the protocol defined here: https://github.com/eiffel-community/eiffel/blob/master/eiffel-vocabulary/EiffelIssueVerifiedEvent.md .
The missing link types should be added to the IssueVerified event approved link types.
REMReM validates according to the protocol documentation.
None.
The Event.generateMeta() method should not overwrite meta.id or meta.time if valid values already exist in the meta object passed in.
https://github.com/eiffel-community/eiffel-remrem-semantics/blob/master/src/main/java/com/ericsson/eiffel/semantics/events/Event.java#L41
When generating an Event it is the event emitter may want to specify a specific uuid (e.g. reproducible uuid) to identify the Event. To support this presently, the event emitter needs to call the remrem-generate, parse the response and replace the id in that response. This processing overhead would be unnecessary if the the Event.generateMeta did not overwrite the id passed in.
reproducible uuids can be used to avoid lookups when creating Events with links. For example a ScS could have a uuid that used the VCS commit identifier as a seed. It then becomes a relatively simple task to create an Act event linked to the ScS
Reduction in processing overhead on client
Logically consistent with remrem-generate for other fields Eiffel message
Recently a routing key template was added to Eiffel Sepia, through PR eiffel-community/eiffel-sepia#9. REMReM should adapt to that recommendation. It is almost compatible with the current implementation in REMReM, apart from the event type field, which should contain the complete event type name and not just an abbreviated version of it. Suggestion is to provide a configuration option to REMReM to keep the "legacy" (current) strings in the event type field to be compatible with any current REMReM deployments, but with the intention to be phased out in due time. It's recommended to provide this "legacy" option as a deprecated option to highlight that this option might disappear in the future.
Documentation to update
To be aligned between all Eiffel eco system tools that should share the same routing key template. Eiffel Sepia should be seen as the blueprint for interoperability between tools in the Eiffel eco system.
E.g. a Jenkins event consumer can more easily be configured to listen to the wanted events.
Increased interoperability between all Eiffel event producers and consumers, as they share the same routing key template.
Existing Eiffel message consumers & producers using another routing key scheme needs to adapt to the new routing key scheme. The proposed "legacy" option is added to this suggestion to deal with that.
Running the schema update process with mvn clean install -P process-schemas
on a Unix-like platform results in the following exception:
Caused by: java.lang.IllegalArgumentException: /home/magnusbk/src/eiffel-remrem-semantics/src\main\resources\schemas\input does not exist
at org.apache.commons.io.FileUtils.verifiedListFiles (FileUtils.java:1741)
at org.apache.commons.io.FileUtils.cleanDirectory (FileUtils.java:1716)
at com.ericsson.eiffel.remrem.semantics.schemas.LocalRepo.readSchemas (LocalRepo.java:46)
at com.ericsson.eiffel.remrem.semantics.clone.PrepareLocalEiffelSchemas.main (PrepareLocalEiffelSchemas.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:294)
at java.lang.Thread.run (Thread.java:748)
This is unsurprising given the backslash-separated paths in EiffelConstants.
The schema update process should obviously be possible to run on platforms other than Windows.
I'd like to be able to update the schemas from a Linux host.
Obvious.
None.
MsgServer.generateMsg() blindly assumes that various keys are available in the input JSON object. If one of the required keys is missing a NullPointerException will be thrown. You'll have to inspect the stack trace (if available) and correlate it to the source code to figure out what the problem was. This is true for msgParams, msgParams,meta, and eventParams.
When adding these checks I think it's reasonable to consider which keys should really be required. For example, this is smallest input document that will pass muster:
{
"msgParams": {
"meta": {}
},
"eventParams": {
"data": {}
}
}
Should we really require msgParams or msgParams.meta? The value of requiring a value but accepting an empty object is unclear to me.
Giving callers reasonably detailed feedback when the input data is bad is arguably a good idea, and generateMsg() already does in some cases (a bad msgType parameter) so if nothing else it'd be nice with some consistency. This is particularly true when the bad value isn't the method parameter itself but a value accessed from the parameter; getting an NPE when you pass a null parameter is more acceptable.
I discovered this when I was playing around with REMReM Generate and trying to pass an empty JSON body. This resulted in a 500 error with nothing in the REMReM logs (which is a separate issue; see eiffel-community/eiffel-remrem-generate#140) and I had to hack in extra logging to get the stack trace and look in the source code to figure out what the problem was.
Move the documentation from gh-pages to master branch to enable better readability.
To enable common documentation across eiffel community.
This repository currently has a .travis.yml file that triggers Travis CI builds for e.g. pull requests. On Dec 16, 2021, the Eiffel Technical Committee decided that existing uses of Travis CI should be migrated to GitHub Actions (see minutes).
Nowadays Travis CI isn't as free to use as it used to be. There's a limited number of credits given to each organization, and right now we're fairly close to the limit. In recent years GitHub Actions has been introduced and it should be adequate for most use cases.
Decreased risk of service interruptions if we reach the usage limit (and nobody will have to spend time on requesting increases in the limit).
Probably none, unless your current .travis.yml contains steps that are very difficult to replicate in a GitHub Actions workflow.
Hi!
Have you considered using protobuf to define the protocol? I remember @d-stahl-ericsson mentioning that it was considered during initial implementation but then wasn't chosen due to the reason that I don't remember. @d-stahl-ericsson what was it?
I believe we can gain a lot from using protobuf and generating protocol definitions instead of coding classes manually
Here are few examples
https://github.com/Praqma/tracey-protocol-eiffel/blob/master/src/main/proto/eiffel_event.proto
https://github.com/Praqma/tracey-protocol-eiffel/blob/master/src/main/proto/eiffel_source_change_created_event.proto
Moreover, we will get few problems out of the list - serialization, deserialization, protocol extensions and versioning.
BR, Andrey
The files generated from the schemas have been edited by hand before being committed so regenerating them from the schemas results in a huge diff even if there are no schema changes. Generated files should be committed as-is. There's a related issue with the copyright headers (#133) but let's solve that problem separately and for now and just get the current files to match the generated files, except the copyright header.
Updating the files after a schema change should be a simple task that even could be automated. Hand-patching updates is a complete waste of time. If we want files formatted in a particular way (or whatever was the reason behind the patches) we should fix the code generator or automate the patching.
I tried to update the generated files to the Paris edition of the Eiffel protocol and had to spend considerable time going through the diff and the history of the git to understand why the diff was huge.
Easier to update the generated files when new protocol changes are made.
None.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.