The Builder does not build Lists

[gataka]

Hi Team

Can you extend your builders to instantiate Lists.
Example: If you call
environmentBuilder = new DefaultAssetAdministrationShellEnvironment.Builder().submodels(new DefaultSubmodel());

You will receive a null pointer, because the underlying list is null. To get it work you have to call it so:
environmentBuilder = new DefaultAssetAdministrationShellEnvironment.Builder() .submodels(new ArrayList<>()) .submodels(new DefaultSubmodel());

This is not a good behaviour of the builder.

The builder would make more sense when it creates such lists on calling new DefaultAssetAdministrationShellEnvironment.Builder().submodels(new DefaultSubmodel()); with a code statement like this

if (getBuildingInstance().getSubmodels() == null)
{
getBuildingInstance().setSubmodels(new ArrayList<>());
}
....

Thank you
Br.

[mjacoby]

Actually, the example you posted works as intended and does not throw any exception, tested with
DefaultAssetAdministrationShellEnvironment aas = new DefaultAssetAdministrationShellEnvironment.Builder().submodels(new DefaultSubmodel()).build();

This implicit agreement in this library is that all collection-like properties of a class are always initialized as an empty collection, see for example here.

Therefore, I do not see any problem here. Did you maybe use a custom implementation of the AssetAdministrationShellEnvironment interface and unknowingly broke this (not explicitely written) agreement? If not, can you provide a code snippet to reproduce the problem?

[gataka]

Hi,
Sorry, I have got it now. Thanks for answering.

Currently I am trying to build the Nameplate with litte java code. It is really hard to build up the whole meta model. Do you think it is possible at one day, that the builders e.g. for SubmodelElements like Property have more intelligence? E.g. That I just have to insert some parameters (like IRDI, Value etc.) and the builder will make the whole work to create the meta model ? Currently I have to create up to 2 "Sub" builders only to set the semanticId. So I am a lacy programmer and I am currently creating methods which will help me to reduce work. How hard is it to contribute this to that repo? I have heard from an IDTA actor that the models will be generated in the future. So will it make sense to contribute it to this repo?

If this comes it would really help to use the java-model.

Br.

[mjacoby]

I'm not sure what exactly you are asking for with the request that builders e.g. for SubmodelElements like Property have more intelligence.
Are you maybe talking about creating instances of a specific SubmodelTemplate? Or are you thinking that some definitions should be fetched remotely by just providing a URL? Besides that I'm having trouble to imagine any other way how to make creation of a model easier.
Maybe it would help if your describe or post some of that code that you are writing to simplify creation.

Contribution to this repository is possible, however there are two major issues

1. This repository will no longer be maintained in the future as the project has moved to Eclipse https://github.com/eclipse-digitaltwin/aas4j
2. The models are already auto-generated in this repository so we will obviously not accept pull requests changing that code but you can always make proposals how to improve the generated code or make a PR on the code generator itself (https://github.com/eclipse-digitaltwin/aas4j-model-generator)

[gataka]

Hi.
Oh I will look to https://github.com/eclipse-digitaltwin/aas4j. Please write it somewhere in the readme's of the admin-shell-io-projects.

I mean some functions like this:

public class ReferenceBuilder extends DefaultReference.Builder {

  public static ReferenceBuilder getBuilder() {
    return new ReferenceBuilder();
  }

  public DefaultReference buildSemanticId(final KeyType semanticKeyIdType,
      final KeyElements semanticKeyType, final String semanticIdValue) {
    return getSelf().key(new DefaultKey.Builder().idType(
        semanticKeyIdType).type(semanticKeyType).value(semanticIdValue).build()).build();
  }


  public Reference buildSubmodel(final Submodel submodel) {

    return getSelf().key(new DefaultKey.Builder().idType(
            KeyType.IRI).type(KeyElements.SUBMODEL).value(submodel.getIdentification().getIdentifier())
        .build()).build();
  }
  public Reference buildAsset(final Asset asset) {

    return getSelf().key(new DefaultKey.Builder().idType(
            KeyType.IRI).type(KeyElements.ASSET).value(asset.getIdentification().getIdentifier())
        .build()).build();
  }
}

Or when I am adding a Submodel to the AdminShellEnv it will automatic connected to an AdminShell.

Br.

[mjacoby]

Also I totally agree that such functionality is quite helpful, I don't think it is feasible to have them as part of the builder classes as this code cannot be auto-generated without additional information beyond the official meta-data model.

From my perspective, the way to go is to provide such utility functions e.g. converting Submodel to Reference separate from the model which still allows pretty easy usage like shown in this pseudo-code

Submodel submodel = ..;
new DefaultAssetAdministrationShell.Builder()
   .submodel(ReferenceHelper.asReference(submodel))
   .build();

A small set of basic such utility functions can be found in the java-serializer project in AasUtils.java. However, this is limited to what was needed to implement serialization.

You can find additional utility functions in the context of one of the projects that already use the java-model and java-serializer projects here (disclaimer: I'm one of the developers)

Coming back on your initial request to add such functionality in the builder classes, I will bring this up in the aas4j proect meeting once we finished migration and are open for new features. If we find a way to auto-generate something like this I might support this feature but I guess we'll have to keep working with utility functions.

[sebbader]

Closing the ticket as the initial problem has been solved, and future steps towards the suggested functions will be handled in a follow-up ticket in the eclipse repository.