Skip to content
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

[WIP] Feature/properties in boundary definitions #113

Open
wants to merge 8 commits into
base: main
Choose a base branch
from

Conversation

v-yussupov
Copy link

Add Property Definitions for Properties in Boundary Defintions

With this feature, Properties in Boundary Defintions, in addition to the original plain XML specification, can be specified using a PropertyDefintions extension element that is defined on the level of ServiceTemplate.

What's added:

  • Properties Definition tab on the level of ServiceTemplate (similar to Node Types, etc)

  • Apart from Winery's KV proeprties, specification of XML elements/types is also possible

  • Properties are instantiated based on the specified Properties Definition

  • If no Properties Definition was specified, properties can be specified as in the original implementation

  • If existing Properties Definition are removed or their type is changed, e.g., from XML element to KV properties, specified properties and property mappings are also removed

  • Changes of KV Properties Definition (adding or removing new kv pairs) is reflected in both, properties and property mappings

  • Property Mappings now have a select element allowing to choose defined KV properties (in case KV properties were used in Properties Definition), otherwise an original input field is kept

  • Ensure that you followed http://eclipse.github.io/winery/dev/ToolChain#github---prepare-pull-request. Especially, we require a single commit

  • Ensure that the commit message is a good commit message

  • Ensure to use auto format in all files

  • Ensure that you appear in NOTICE at Copyright Holders

  • Tests created for changes

  • Documentation updated (if needed)

  • Screenshots added (for UI changes)

@clarity-bot
Copy link

clarity-bot bot commented Aug 3, 2018

I generated a structure-diff below from pulling c2f8beb on OpenTOSCA:feature/issue-199 into e34186c on OpenTOSCA:master.

Structure Diff

Signed-off-by: Vladimir Yussupov <[email protected]>
@@ -154,6 +154,8 @@ protected void setWPDElement(WinerysPropertiesDefinition res) {
}

protected void setWPDNamespace(WinerysPropertiesDefinition res) {
// bo be overridden by subclasses willing to use getWinerysPropertiesDefinition()
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be marked as abstract then, to force said overriding? This class is already abstract so we're not giving up anything for that

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was not sure if all TExtensibleElements actually need WPD support, since initially only TEntityType supported them. This is an attempt to reuse the method in both TEntityTypes and TServiceTemplates without duplicating it and at the same time without putting additional requirements on TExtensibleElements.

@lharzenetter lharzenetter changed the title [WIP] Feature/issue 199 [WIP] Feature/properties in boundary definitions Aug 4, 2018
Copy link
Member

@lharzenetter lharzenetter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On a first sight, it looked good to me. I have some changes though and I will take a deeper look into it next week.
Please also ensure, that Travis completes successfully.

}

protected void setWPDNamespace(WinerysPropertiesDefinition res) {
// bo be overridden by subclasses willing to use getWinerysPropertiesDefinition()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you need to have this "abstract" method. The implementations in both are similar and you could check if the current class is an instance of HasTargetNamespace, and otherwise use a default one

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, that's a good solution if a namespace has to be set in the same way for both TEntityType and TServiceTemplate (currently setWPDNamespace is identical, so I assume there's no need for different implementations)

public class PropertiesResource {

private static final Logger LOGGER = LoggerFactory.getLogger(PropertiesResource.class);

private AbstractComponentInstanceResource res;
private TEntityTemplate template;

public PropertiesResource() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need this?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

now it's not needed, I'll remove it (I first made BoundaryDefinitionsPropertiesResource to be a subclass of PropertiesResource and there I needed a default constructor, however I changed it later)

@@ -119,6 +120,11 @@ public BoundaryDefinitionsResource getBoundaryDefinitionsResource() {
return new BoundaryDefinitionsResource(this, boundaryDefinitions);
}

@Path("propertiesdefinition/")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please no trailing slash

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all other subresources (topologytemplate, plans, ...) in ServiceTemplateResource use trailing slashes, I just kept it consistent with the used convention


return this.http
/*return this.http
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please remove comments

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure!

public class PropertiesResource {

private static final Logger LOGGER = LoggerFactory.getLogger(PropertiesResource.class);

private AbstractComponentInstanceResource res;
private TEntityTemplate template;

public PropertiesResource() {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need this?

@@ -119,6 +120,11 @@ public BoundaryDefinitionsResource getBoundaryDefinitionsResource() {
return new BoundaryDefinitionsResource(this, boundaryDefinitions);
}

@Path("propertiesdefinition/")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No trailing slashes

}
}

protected void setWPDNamespace(WinerysPropertiesDefinition res) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could actually implement it on this level since the methods are identical. To be able to use the getTargetNamespace method, you can check if the current object is an instance of HasTargetNamespace and cast it. Otherwise, you could use a default namespace.

Signed-off-by: Vladimir Yussupov <[email protected]>
@miwurster
Copy link

Hi @v-yussupov, what needs to be done here for the final merge?

@v-yussupov
Copy link
Author

@miwurster actually, I'm not sure if it's still needed. I think initially Lukas planned to have this feature for the paper, but eventually it was not used. @lharzenetter, is it still needed?

@miwurster
Copy link

miwurster commented Feb 14, 2020

@lharzenetter please revise, finalize and merge this PR ... otherwise, close it.

@miwurster miwurster closed this Feb 14, 2020
@miwurster miwurster reopened this Feb 14, 2020
@lharzenetter lharzenetter changed the base branch from master to main December 15, 2021 12:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

5 participants