-
Notifications
You must be signed in to change notification settings - Fork 27
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update the Model and Serialisers to 3.0.rc02 #3
Update the Model and Serialisers to 3.0.rc02 #3
Conversation
…ed on MAVEN CENTRAL).
* AASX * JSON * AML * XML
Version 1.3.RC02-SNAPSHOT for the model adjusting the packages to org.eclipse.aas4j and correcting imports and other renaming due to RD02 Adjusting the JSON Serialiser to the new "modelType" pattern and the DataTypeDefXsd notation
@twebermartins and @mjacoby, as discussed today this is the current state of work in direction of 3.0.RC02. |
Merge so that we have the RC02. We know that there are some errors due to missing builds for datafile formats (AML, AASX, XML ..). Issues will be generated to address these errors and will be addressed ASAP. |
* Update test JSON documents to v3.0.RC02
"description": [ | ||
"description": | ||
{ | ||
"langStrings": [ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems not to be standard-compliant (see table 6, page 96 AAS Part 1 v3.0RC02). Description in JSON should be array and not object with additional property "langStrings"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Valid point. I have raised an issue at aas-core-works/aas-core-meta#128 as this is the source of the JSON schema that I have imported.
package io.adminshell.aas.v3.dataformat.aasx; | ||
package org.eclipse.aas4j.v3.rc02.dataformat.aasx; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to go for a package name only containing the target version (v3) and not also including the current working version (in this case rc02)? I don't see a benefit having the sub-package.
Only the additional effort on the consumer side - when fetching a new version - to update all imports. Also when we come to v3 final, the rc-package will be removed and the build within consumer projects will fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would expect that minor versions will never contain "breaking" changes.
If this is the case I fully agree with @Smudo99 and would recommend to only have a major version in names.
I am merging this PR into a working branch based on the discussion of the committers meeting from today. |
This PR contains a lot of changes introduced by:
Please also note that this is not a final state for 3.0.RC02. Many tests are failing, and I have focused on the JSON part a lot. The other modules compile, but that's it, nothing more.