Idea: To distinguish easier between needuml and needarch, needuml shall not be stored inside a need

[PhilipPartsch]

Currently: needuml is been stored inside a need, like needarch. Idea: We provide this only with needarch.

[danwos]

I totally agree and I thought this is already the case. At least it was the goal.

needuml: Pure representation, no way to reuse it somewhere else needarch: Storing and representation, can be reused by needuml and needarch.

[PhilipPartsch]

Todos:

1. exception in needuml if a key is given good place for the exception is in here
2. test that needuml is raising the new defined exception
3. test that needarch still works
4. check in copy function form needuml to need, only needarch are been copied. Implementation of copy from needuml to need
5. Adapt documentation for needuml and needarch

[AlexanderLanin]

We have two keywords for the same functionality which are used in two different places.... it really sounds like there should be only one such keyword! Focus on the end user, not how it's easier internally. For the end user it's one less keyword they need to learn.

[danwos]

I disagree here, as they behave slightly differently and have access to different kind of data. The decision was made because of the user and not based on any technical implementation, as it is hard to explain why the same code behaves differently, has different jinja-functions support, and does not have access to the same data, based on where it was used.

In the past, it was one single function, but users starts to complain about it quite fast. Therefore we decided to split it, so that also the documentation can be done more easily.