Closed mnam closed 9 years ago
Hi,
So, if I understand correctly, what you want is to avoid the method to process objects from the Plugin_Resources, correct ? I tried to reproduce the bug but unfortunately, when using the declarative model traversal, it does not parse/analyse files in the PlugIn_Resources. Can you provide an example to reproduce the bug ?
Oh I meant the opposite. I do want it to process the objects in the Pluin_Resources. Like you tested, it does not. Sorry for the confusion.
Ok, so, I understand why I was not able to at least reproduce it. In fact, we would likely not support the addition/modification of something else than properties in the PlugIn_Resources. We also had some requests last week about that and it seems that it could create some errors. I would also discuss that issue with Peter and see how he feels about it but I think it is worth to use the workaround he proposed to address this concern.
The workaround consist in having a shared project with your components library. Then, each project that is using the components library would reference it so that you can resolve the name, etc ... In addition, the traversal plugin shall parse the elements in that project. I used to work when I tested but you might encounter some error (and in that case, please open a bug).
Does that sound reasonable for you ?
Yeh, if it was not meant to go through the type definitions in the Plugin_Resources, its fine. Normally it just becomes a hassel to tell people to import an extra project for a library which is why I prefer have it in auto generated in the Plugin_Resources.
I don't understand why adding something other the property sets shoud not be supported though.
If a plug-in is built with the requirement of having some component types to exist in the workspace, it is much better to link it through other plug-ins that adds the component types to the Plugin_Resource through plug-in dependencies. Rather than having instructions about another AADL project of library components that users should manually import or I guess this can be autogenerated as well.
Thanks. I'll close this. Just wanted to see if this was intend or was a bug.
Min Young,
I have been chasing another bug. In plugin resources we do have packages in addition to property sets. For example, the Data Model annex contributes data type definitions. I’ll look at the discussion thread and then respond.
Peter
From: mnam [mailto:notifications@github.com] Sent: Wednesday, February 13, 2013 2:41 PM To: osate/osate2-core Subject: Re: [osate2-core] ForAllElement.defaultTraversalAllDeclarativeModels() doesn't give Component types in Plugin_Resource (#180)
Yeh, if it was not meant to go through the type definitions in the Plugin_Resources, its fine. Normally it just becomes a hassel to tell people to import an extra project for a library which is why I prefer have it in auto generated in the Plugin_Resources.
I don't understand why adding something other the property sets shoud not be supported though.
If a plug-in is built with the requirement of having some component types to exist in the workspace, it is much better to link it through other plug-ins that adds the component types to the Plugin_Resource through plug-in dependencies. Rather than having instructions about another AADL project of library components that users should manually import or I guess this can be autogenerated as well.
Thanks. I'll close this. Just wanted to see if this was intend or was a bug.
— Reply to this email directly or view it on GitHubhttps://github.com/osate/osate2-core/issues/180#issuecomment-13513766.
Hi
I wanted to reopen this just as a reminder since from Peter's last comment, we do have data types in the Plugin Resources and probably defaultTraversalAllDeclarativeModels should go through the PluginResources then.
Thanks. Min Young
Min Young,
I will be looking at this in the next few days. Brian Larson also has an issue with it.
Peter
From: mnam [mailto:notifications@github.com] Sent: Thursday, February 21, 2013 7:00 PM To: osate/osate2-core Cc: Peter Feiler Subject: Re: [osate2-core] ForAllElement.defaultTraversalAllDeclarativeModels() doesn't give Component types in Plugin_Resource (#180)
Hi
I wanted to reopen this just as a reminder since from Peter's last comment, we do have data types in the Plugin Resources and probably defaultTraversalAllDeclarativeModels should go through the PluginResources then.
Thanks. Min Young
— Reply to this email directly or view it on GitHubhttps://github.com/osate/osate2-core/issues/180#issuecomment-13920968.
This is pretty old. Do we still need to fix it?
I must have done something about this. Frankly, I don't remember since it has been so long. Let's close this.
Thanks. Min Young
On Wed, Apr 22, 2015 at 9:24 AM, Lutz Wrage notifications@github.com wrote:
This is pretty old. Do we still need to fix it?
— Reply to this email directly or view it on GitHub https://github.com/osate/osate2-core/issues/180#issuecomment-95175840.
Hi all,
Not sure if this was intended or its a bug. The defaultTraversalAllDeclarativeModels does NOT go through any of component types in the Plugin_Resources. The standard of course doesn't have any Classifier types defined in the Plugin_Resources. However, we can add plug-ins to extend it and as a use case, one would add a library of components that a tool supports so that people could extend them. To provide the list of these library components as well as any component type definition, I would use defaultTraversalAllDeclarativeModels but the types are not included.
On the other hand, using the EMFIndexRetrieval approach, I do get ALL type definitions. Any way we could make the defaultTraversalAllDeclarativeModels work for content in the Plugin_Resources or is there any settings I could do?
Thanks. Min Young