AW: Simpifying the profiles?

2019-10-16 Thread Strljic, Matthias Milan
GERMANY Tel: +49 711 685-84530 Fax: +49 711 685-74530 E-Mail: matthias.strl...@isw.uni-stuttgart.de Web: http://www.isw.uni-stuttgart.de -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Wednesday, October 16, 2019 10:34 AM An: dev@plc4x.apache.org Betreff: Re: Simpifying

Re: Simpifying the profiles?

2019-10-16 Thread Christofer Dutz
+1 to that :-) Am 16.10.19, 13:41 schrieb "Julian Feinauer" : Sorry, some appendum. I +1 Chris proposal but I see that in a (hopefully not too far) future communities gather for separate languages they should ofc choose the build tool of their choice (use make and deal with it...

Re: Simpifying the profiles?

2019-10-16 Thread Julian Feinauer
Sorry, some appendum. I +1 Chris proposal but I see that in a (hopefully not too far) future communities gather for separate languages they should ofc choose the build tool of their choice (use make and deal with it... __). But I agree with Chris that as long as the "core" or "java" team manages

Re: Simpifying the profiles?

2019-10-16 Thread Julian Feinauer
Clear +1 from my side for this approach. Am 16.10.19, 10:41 schrieb "Christofer Dutz" : Hi Julian, I suggest not to have a "with-java" profile anymore and no "with-sandbox". Java will probably always be the leading language (at least for the near future). Perhaps it would

Re: Simpifying the profiles?

2019-10-16 Thread Christofer Dutz
Hi Julian, I suggest not to have a "with-java" profile anymore and no "with-sandbox". Java will probably always be the leading language (at least for the near future). Perhaps it would really be better to split out the other languages as soon as they are ready to leave the sandbox, but to stick

Re: Simpifying the profiles?

2019-10-16 Thread Julian Feinauer
Hi Chris, I agree with you and perhaps another way to gain traction is to "finish" java "kind of" and then move together to another language. And regarding the suggestion, why not. So you suggest to jave "with-java" as the default and the others as "add on" profiles, right? Julian Am

Re: Simpifying the profiles?

2019-10-16 Thread Christofer Dutz
Hi Julian, it sadens me to admit that, but I guess your assessment is absolutely correct. I remember having this strange gutt feeling with having plc4py, plc4cpp and plc4net first class citisens as they aren't usable. Then I was hoping the drive in the community would make this happen soon.

Re: Simpifying the profiles?

2019-10-15 Thread Julian Feinauer
Hi Chris, thanks for picking up this discussion and for the three suggestions. My initial approach would be rather similar to your suggestion 3 BUT with a crucial addition. My observation and belief is, that we currently focus nearly 100% on java (I know that you work on codegen for the other

Re: Simpifying the profiles?

2019-10-15 Thread Christofer Dutz
Replying to both posts in one email ... @Niclas: Yes we had thought of that ... as far as I remember it, it was considered an option as the project grows. If we split it up now, this would result in 6 repos (build-tools, protocols, java, c++, c# and python) ... this would result in every

Re: Simpifying the profiles?

2019-10-15 Thread Tim Mitsch
Hey everybody, First of all it's a very good idea to simply the profile-stuff. My thoughts to that are that we maybe could add a little shell-script (Mac/Linux), bat-file (Windows) that guides the user ("Do you want to build Java-sources? [Yes/No]) and states if all requirements for build of

Re: Simpifying the profiles?

2019-10-15 Thread Niclas Hedhman
Has multiple repositories been considered? A project may request as many as they want/need... On Tue, Oct 15, 2019 at 4:07 PM Christofer Dutz wrote: > Hi all, > > as I have heard complaints that the current way we handle profiles is too > complicated, I would like to discuss alternatives with

Simpifying the profiles?

2019-10-15 Thread Christofer Dutz
Hi all, as I have heard complaints that the current way we handle profiles is too complicated, I would like to discuss alternatives with you all. Currently if you just run “./mvnw install” it will only build the protocols. This is probably not what the user wants. Right now we didn’t want to