Hi, yes I like your idea to hide it in the SDK. To ensure that the namespace is unique we would still use the package name?
Philipp > On 9. Apr 2020, at 21:17, Dominik Riemer <[email protected]> wrote: > > Hi, > > I also agree that the current IDs are too long. I think when we decided to > have the full namespace in the pipeline element Id (appId) the idea was to > avoid naming conflicts once other pipeline elements outside of StreamPipes > are used (e.g., company-internal). > > What about simplifying the structure a bit, such as > namespace:pipelineElementId (e.g., org.apache.streampipes:textfilter)? But > then we would have a colon in the directory, which is not much better than a > dot I guess ;-) > But maybe we could hide this from the user by modifying the SDK and split the > id into a namespace and pipeline element Id, e.g.: > ProcessingElementBuilder.create(namespace, id), and then the resource folder > name would only need to adhere to the id instead of the full namespace+id. > > What do you think? > Dominik > > > > On 2020/04/09 18:10:40, Christofer Dutz <[email protected]> wrote: >> I agree ... >> >> And I had issues in the past with these directory names including dots. It's >> sort of impossible to see if this is a set of nested directories or just one >> (or something in between) in most IDEs I'm using. I would really prefer to >> not have "." in directory names. >> >> Chris >> >> >> >> Am 08.04.20, 22:18 schrieb "Philipp Zehnder" <[email protected]>: >> >> Hi all, >> >> while testing the processing elements for the release I realized that it >> is hard to manage the resources for the pipeline elements, because the name >> of the folder is so long. >> Especially when there are many elements within one module it is hard to >> find the one you are looking for. >> >> My suggestion would be to shorten the folder names. Currently we have the >> whole package name to ensure that the processors are unique. >> Maybe when can still use the package name, but start from the Init class >> file. This would improve the readability during development. >> >> What do you think? Are there any reasons why we need the whole package >> name? >> >> Philipp >> >> >> >>
