Hi,
I already anticipated that response : )
And agree that ist bad practice : )
But I agree with your approach.. we first try it in our branch and if ist fine,
we should start the release train and go for it : )
Julian
Am 16.07.19, 10:16 schrieb "Christofer Dutz" :
Hi Julian,
A
Hi Julian,
A big -1 for checking in generated code. We should simply release the build
tools asap. I think it's in good shape and wanted to verify by testing it with
more specs. So I would like you guys to test if the current solution suits your
needs. So how about you trying to create the
Hey,
I'm not saying that I'm about to merge such a change but I think this is a
reasonable think todo.
If we all agree on it I'll file an Issue on jira and try to do it myself the
next weeks.
But good point with docs and examples!
J
Am 16.07.19, 10:11 schrieb "Christofer Dutz" :
I am
I am also in favor for changing it.
I'm however a little unsure about the ads. But as the adsid can be completely
different, pehaps it would be a good idea to do something like: ams://{hostname
or ip} for cases where the ads I'd is created from the ip by adding ".1.1" and
using ams://{hostname
Hi all,
I had a short discussion with Chris and Volker (a new colleague of us)
yesterday which is important for the list, I guess.
First, I learned (sorry that I didn’t notice Chris!) that the generation of
POJOs and serializers / deserializers in Java is totally finished.
So if we agree on
Hey Matthias,
Personally, I feel that it would be better for users to keep fields "domain"
specific.
At least I love that for S7 (and our users too).
Perhaps we can introduce also a general unified language for that but
optionally provide a specific one for each protocol.
What do others think?
Hi Julian,
I think that is a really good question.
For the Connection String I would agree (+1) for your suggestion. But wanted to
ask if there is a notation which is domain specific to a protocol from the
"user" point of view?
Like we have it in the FieldAddresses.
So that we just throw into
