Re: [DriverGen] Major refactoring and great improvements
I have implemented far too many protocols over the years, in Java, and I
typically end up with;
Link Layer = serial port, IP, TCP, UDP...
Framing / Packet Layer = everything common no matter what payload is.
Typicall involves start/stop markers, escaping/replacement, checksums,
Operations Layer = Different payloads depending on the "function",
"operation", "data type", "event type",... being exchanged.
And to that, I would attach "Utilities" which deals with data type
conversions to/from Java types, bit manipulation, text handling,... and
zero, one or more "Subsystems" for advanced topics specific to the protocol
needed to bridge to "my platform", such as remote alarm management, device
level data recordings, programming, heart beat handling, ++
My 2 devalued cents...
Niclas
On Thu, May 30, 2019 at 6:06 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:
> Hey Chris,
>
> this is one oft he problems I also stumbled across when reasoning and
> which I consider 'hard'.
> One way to make it way cleaner would be to switch to a layered
> architecture.
> If we generally distinguish between Transport Layers and Communication
> Layer (better anmes are welcome) we can introduce a general format of these
> transport layers which is
>
> [Type
> [Some Type of header Stuff]
> [byte[] payload]
> [Some Type of fooder Stuff]
> ]
>
> This would also enforce reusability.
>
> Or am I getting things wrong?
>
> Am 29.05.19, 23:55 schrieb "Christofer Dutz" :
>
> Hi all,
>
> so today I somewhat finished the POJO generation for Java and am
> currently implementing the IO classes to parse the POJOs (Second step will
> be serializing)
>
> Now I stumbled into following problem (One example from the S7
> protocol):
>
> [discriminatedType 'S7Message' ['payloadLength']
> [const uint 8 'protocolId' '0x32']
> [discriminator uint 8 'messageType']
> [reserved uint 16 '0x']
> [field uint 16 'tpduReference']
> [implicit uint 16 'parameterLength' 'parameters.size']
> [implicit uint 16 'payloadLength' 'payloads.size']
> [typeSwitch 'messageType'
> ['0x01' Request
> [context string 'messageType' 'request']
> ]
> ['0x03' Response
> [context string 'messageType' 'response']
> [field uint 8 'errorClass']
> [field uint 8 'errorCode']
> ]
> ['0x07' UserData
> [context string 'messageType' 'userData']
> ]
> ]
> [field S7Parameter 'parameter' {messageType: 'messageType'}]
> [field S7Payload 'payload' {messageType: 'messageType', parameter:
> 'parameter'}]
> ]
>
> As you can see there's properties that belong to the base type and
> parts that belong to Request, Response and UserData ... however this
> information is sort of in-between the header and the footer.
>
> Enforcing the switch to be the last and pulling the parameter and
> payload into the cases, sounds like an ugly restriction.
>
> So I thought that I might generate some parser classes for the
> sub-types, that contain the sub-type properties only and a factory method
> ... to in this case the Response factory pojo class which would sort of
> look like this:
>
> public class ResponseDelayedBuilder implements DelayedBuilder {
> private final short errorClass;
> private final short errorCode;
>
> public ResponseParserModel(short errorClass, short
> errorCode) {
> this.errorClass = errorClass;
> this.errorCode = errorCode;
> }
>
> @override
> public Response build(int tpduReference, S7Parameter parameter,
> S7Payload payload) {
> return new Response(tpduReference, parameter, payload,
> errorClass, errorCode);
> }
> }
>
> Is there a cleaner way of doing something like this?
>
> Chris
>
>
>
> Am 29.05.19, 09:34 schrieb "Christofer Dutz" <
> christofer.d...@c-ware.de>:
>
> Hi all,
>
> I just wanted to give you all an update on how we are progressing
> on the driver generation front.
>
> I just pushed some major refactorings which transition the POC
> more in the direction of something usable.
> Here the most important changes:
>
> * There are Protocol-modules which are discovered similar to
> how we discover drivers in the classpath
> * There are now Language-(output)-modules which also are
> discovered similar to how we discover drivers in the classpath
> * The input modules generally provide only the spec
> * The output modules contain everything needed to produce
> output for a given language
> * In order to allow experimentation of the output variants the
> output modules contain everything needed to generate the output
>
Re: [BUILDS] What build system to use?
Hi, just a rather general comment from myself. As one of the guys that started several discussions about the build and its complexity I really really like the way it currently is going. And I really appreciate that everybody is integrating himself in the discussion, especially Markus with the C++ module. This way feels right to me and I'm really looking forward to the next iteration of our build! Julian Am 29.05.19, 14:14 schrieb "Markus Sommer" : I'have push to Branch feature/s7-cpp Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 12:34 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi Markus, that would be great :-) Chris Am 28.05.19, 11:37 schrieb "Markus Sommer" : Hello Chris, in Case of the CMake files I already did some things here. I would push the CMake files to compile the scources on the branch, so you only have to bind the Pom.xml. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 10:22 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi all, I'll try to summarize responses to all ( So in general you are quite happy as it currently is, however the C++ module could use simplification. I would suggest that I get rid of the individual pom.xml files and all the packaging and unpacking and change the CMake files to use relative paths in the project structure? In general you are ok with using maven to trigger a native build tool (cmake, python setup.py or dotnet) and to have this build the entire language part of that particular module. I could make the maven plugin work in a way that it can generate code for multiple specs into different directories (think it already allows this anyway) and to run this at the language-root. So a build for any language would be: 1. Generate the code using the plc4x-maven-plugin 2. Execute the native build Beyond that we would need: - Clean by providing extra rules to the maven-clean-plugin to clean up the language dependent directories and resources. - If we want to ship artifacts ... find a way to do so in the package, deploy and install phases (For now this is mostly disabled anyway ... but we should come up with something) Things that are important here is a way to provide the version from maven to the native build tool as otherwise we would have problems releasing. I think I have implemented this at least for dotnet and python ... have to double-check with CMake. I am not focused on
Re: [BUILDS] What build system to use?
Haha, you took that from my proposal! :D Am 29.05.19, 15:02 schrieb "Christofer Dutz" : Hi Markus, as I'm currently zoned into parser code generation ... I'll look into this as soon as I come out of the rabbit hole I fell into, where I'm currently chasing a fluffy white bunny with a big fat clock ;-) Thanks, Chris Am 29.05.19, 14:14 schrieb "Markus Sommer" : I'have push to Branch feature/s7-cpp Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 12:34 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi Markus, that would be great :-) Chris Am 28.05.19, 11:37 schrieb "Markus Sommer" : Hello Chris, in Case of the CMake files I already did some things here. I would push the CMake files to compile the scources on the branch, so you only have to bind the Pom.xml. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 10:22 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi all, I'll try to summarize responses to all ( So in general you are quite happy as it currently is, however the C++ module could use simplification. I would suggest that I get rid of the individual pom.xml files and all the packaging and unpacking and change the CMake files to use relative paths in the project structure? In general you are ok with using maven to trigger a native build tool (cmake, python setup.py or dotnet) and to have this build the entire language part of that particular module. I could make the maven plugin work in a way that it can generate code for multiple specs into different directories (think it already allows this anyway) and to run this at the language-root. So a build for any language would be: 1. Generate the code using the plc4x-maven-plugin 2. Execute the native build Beyond that we would need: - Clean by providing extra rules to the maven-clean-plugin to clean up the language dependent directories and resources. - If we want to ship artifacts ... find a way to do so in the package, deploy and install phases (For now this is mostly disabled anyway ... but we should
Re: [DriverGen] Major refactoring and great improvements
Hey Chris,
this is one oft he problems I also stumbled across when reasoning and which I
consider 'hard'.
One way to make it way cleaner would be to switch to a layered architecture.
If we generally distinguish between Transport Layers and Communication Layer
(better anmes are welcome) we can introduce a general format of these transport
layers which is
[Type
[Some Type of header Stuff]
[byte[] payload]
[Some Type of fooder Stuff]
]
This would also enforce reusability.
Or am I getting things wrong?
Am 29.05.19, 23:55 schrieb "Christofer Dutz" :
Hi all,
so today I somewhat finished the POJO generation for Java and am currently
implementing the IO classes to parse the POJOs (Second step will be serializing)
Now I stumbled into following problem (One example from the S7 protocol):
[discriminatedType 'S7Message' ['payloadLength']
[const uint 8 'protocolId' '0x32']
[discriminator uint 8 'messageType']
[reserved uint 16 '0x']
[field uint 16 'tpduReference']
[implicit uint 16 'parameterLength' 'parameters.size']
[implicit uint 16 'payloadLength' 'payloads.size']
[typeSwitch 'messageType'
['0x01' Request
[context string 'messageType' 'request']
]
['0x03' Response
[context string 'messageType' 'response']
[field uint 8 'errorClass']
[field uint 8 'errorCode']
]
['0x07' UserData
[context string 'messageType' 'userData']
]
]
[field S7Parameter 'parameter' {messageType: 'messageType'}]
[field S7Payload 'payload' {messageType: 'messageType', parameter:
'parameter'}]
]
As you can see there's properties that belong to the base type and parts
that belong to Request, Response and UserData ... however this information is
sort of in-between the header and the footer.
Enforcing the switch to be the last and pulling the parameter and payload
into the cases, sounds like an ugly restriction.
So I thought that I might generate some parser classes for the sub-types,
that contain the sub-type properties only and a factory method ... to in this
case the Response factory pojo class which would sort of look like this:
public class ResponseDelayedBuilder implements DelayedBuilder {
private final short errorClass;
private final short errorCode;
public ResponseParserModel(short errorClass, short errorCode)
{
this.errorClass = errorClass;
this.errorCode = errorCode;
}
@override
public Response build(int tpduReference, S7Parameter parameter,
S7Payload payload) {
return new Response(tpduReference, parameter, payload,
errorClass, errorCode);
}
}
Is there a cleaner way of doing something like this?
Chris
Am 29.05.19, 09:34 schrieb "Christofer Dutz" :
Hi all,
I just wanted to give you all an update on how we are progressing on
the driver generation front.
I just pushed some major refactorings which transition the POC more in
the direction of something usable.
Here the most important changes:
* There are Protocol-modules which are discovered similar to how we
discover drivers in the classpath
* There are now Language-(output)-modules which also are discovered
similar to how we discover drivers in the classpath
* The input modules generally provide only the spec
* The output modules contain everything needed to produce output
for a given language
* In order to allow experimentation of the output variants the
output modules contain everything needed to generate the output
* My implementation of a language-template-java uses freemarker to
generate output, but others could simply use other techniques
So far I have a pojo template that will generate the POJO classes for
the types in the spec.
Right now I’m working on the little tool that will tell the output
which Java type it should use for which spec type …
but as soon as that’s done I’m looking forward to implementing the IO
components.
All of this is happening in the “feature/code-gen” branch … and all my
code-generation related code is in sandbox/code-generation
So far the update …
Chris
Re: [DriverGen] Major refactoring and great improvements
Hi all,
so today I somewhat finished the POJO generation for Java and am currently
implementing the IO classes to parse the POJOs (Second step will be serializing)
Now I stumbled into following problem (One example from the S7 protocol):
[discriminatedType 'S7Message' ['payloadLength']
[const uint 8 'protocolId' '0x32']
[discriminator uint 8 'messageType']
[reserved uint 16 '0x']
[field uint 16 'tpduReference']
[implicit uint 16 'parameterLength' 'parameters.size']
[implicit uint 16 'payloadLength' 'payloads.size']
[typeSwitch 'messageType'
['0x01' Request
[context string 'messageType' 'request']
]
['0x03' Response
[context string 'messageType' 'response']
[field uint 8 'errorClass']
[field uint 8 'errorCode']
]
['0x07' UserData
[context string 'messageType' 'userData']
]
]
[field S7Parameter 'parameter' {messageType: 'messageType'}]
[field S7Payload 'payload' {messageType: 'messageType', parameter:
'parameter'}]
]
As you can see there's properties that belong to the base type and parts that
belong to Request, Response and UserData ... however this information is sort
of in-between the header and the footer.
Enforcing the switch to be the last and pulling the parameter and payload into
the cases, sounds like an ugly restriction.
So I thought that I might generate some parser classes for the sub-types, that
contain the sub-type properties only and a factory method ... to in this case
the Response factory pojo class which would sort of look like this:
public class ResponseDelayedBuilder implements DelayedBuilder {
private final short errorClass;
private final short errorCode;
public ResponseParserModel(short errorClass, short errorCode) {
this.errorClass = errorClass;
this.errorCode = errorCode;
}
@override
public Response build(int tpduReference, S7Parameter parameter,
S7Payload payload) {
return new Response(tpduReference, parameter, payload,
errorClass, errorCode);
}
}
Is there a cleaner way of doing something like this?
Chris
Am 29.05.19, 09:34 schrieb "Christofer Dutz" :
Hi all,
I just wanted to give you all an update on how we are progressing on the
driver generation front.
I just pushed some major refactorings which transition the POC more in the
direction of something usable.
Here the most important changes:
* There are Protocol-modules which are discovered similar to how we
discover drivers in the classpath
* There are now Language-(output)-modules which also are discovered
similar to how we discover drivers in the classpath
* The input modules generally provide only the spec
* The output modules contain everything needed to produce output for a
given language
* In order to allow experimentation of the output variants the output
modules contain everything needed to generate the output
* My implementation of a language-template-java uses freemarker to
generate output, but others could simply use other techniques
So far I have a pojo template that will generate the POJO classes for the
types in the spec.
Right now I’m working on the little tool that will tell the output which
Java type it should use for which spec type …
but as soon as that’s done I’m looking forward to implementing the IO
components.
All of this is happening in the “feature/code-gen” branch … and all my
code-generation related code is in sandbox/code-generation
So far the update …
Chris
Re: [BUILDS] What build system to use?
Hi Markus, as I'm currently zoned into parser code generation ... I'll look into this as soon as I come out of the rabbit hole I fell into, where I'm currently chasing a fluffy white bunny with a big fat clock ;-) Thanks, Chris Am 29.05.19, 14:14 schrieb "Markus Sommer" : I'have push to Branch feature/s7-cpp Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 12:34 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi Markus, that would be great :-) Chris Am 28.05.19, 11:37 schrieb "Markus Sommer" : Hello Chris, in Case of the CMake files I already did some things here. I would push the CMake files to compile the scources on the branch, so you only have to bind the Pom.xml. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 10:22 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi all, I'll try to summarize responses to all ( So in general you are quite happy as it currently is, however the C++ module could use simplification. I would suggest that I get rid of the individual pom.xml files and all the packaging and unpacking and change the CMake files to use relative paths in the project structure? In general you are ok with using maven to trigger a native build tool (cmake, python setup.py or dotnet) and to have this build the entire language part of that particular module. I could make the maven plugin work in a way that it can generate code for multiple specs into different directories (think it already allows this anyway) and to run this at the language-root. So a build for any language would be: 1. Generate the code using the plc4x-maven-plugin 2. Execute the native build Beyond that we would need: - Clean by providing extra rules to the maven-clean-plugin to clean up the language dependent directories and resources. - If we want to ship artifacts ... find a way to do so in the package, deploy and install phases (For now this is mostly disabled anyway ... but we should come up with something) Things that are important here is a way to provide the version from maven to the native build tool as otherwise we would have problems releasing. I think I have implemented this at least for dotnet and python ... have to double-check with CMake. I am not focused on using Thrift at all ... it was something you folks came up with and I simply made it work reliably in our build. I do agree that I would prefer not having to build the thrift
AW: [BUILDS] What build system to use?
I'have push to Branch feature/s7-cpp Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.: +49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 12:34 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi Markus, that would be great :-) Chris Am 28.05.19, 11:37 schrieb "Markus Sommer" : Hello Chris, in Case of the CMake files I already did some things here. I would push the CMake files to compile the scources on the branch, so you only have to bind the Pom.xml. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 10:22 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi all, I'll try to summarize responses to all ( So in general you are quite happy as it currently is, however the C++ module could use simplification. I would suggest that I get rid of the individual pom.xml files and all the packaging and unpacking and change the CMake files to use relative paths in the project structure? In general you are ok with using maven to trigger a native build tool (cmake, python setup.py or dotnet) and to have this build the entire language part of that particular module. I could make the maven plugin work in a way that it can generate code for multiple specs into different directories (think it already allows this anyway) and to run this at the language-root. So a build for any language would be: 1. Generate the code using the plc4x-maven-plugin 2. Execute the native build Beyond that we would need: - Clean by providing extra rules to the maven-clean-plugin to clean up the language dependent directories and resources. - If we want to ship artifacts ... find a way to do so in the package, deploy and install phases (For now this is mostly disabled anyway ... but we should come up with something) Things that are important here is a way to provide the version from maven to the native build tool as otherwise we would have problems releasing. I think I have implemented this at least for dotnet and python ... have to double-check with CMake. I am not focused on using Thrift at all ... it was something you folks came up with and I simply made it work reliably in our build. I do agree that I would prefer not having to build the thrift binary in advance. If you come up with an alternative, I'm happy to replace this. The reason for us building it, was that the Thrift project is not distributing thrift compiler binaries for anything except windows. I could contact them and donate our thrift config to the project and hope they start also distributing other binaries, but for now there was just no way to tun the thrift compiler without manually pre-installing it on every system. We could remove that thrift compilation and extend the pre-flight-check and README documentation with instructions on how to install thrift, but then again the list of things to install is continuously
AW: [BUILDS] What build system to use?
Hello, Chris, I pushed my changes to CMakeLists. Now we have to clarify the following points, where we generate the Boost-Libariers. I'd like to see if I can also map the topic in CMake. If not, we would have to go over maven. If the user creates the boost libraries without support, there may be problems with including and linking again. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.: +49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 12:34 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi Markus, that would be great :-) Chris Am 28.05.19, 11:37 schrieb "Markus Sommer" : Hello Chris, in Case of the CMake files I already did some things here. I would push the CMake files to compile the scources on the branch, so you only have to bind the Pom.xml. Best regards Markus Freundliche Grüße Markus Sommer Geschäftsführer isb innovative software businesses GmbH Otto-Lilienthal-Strasse 2 D - 88046 Friedrichshafen Tel.:+49 (0) 7541 3834-14 Mob: +49 (0) 171 537 8437 Fax: +49 (0) 7541 3834-20 E-Mail: som...@isb-fn.de Web: www.isb-fn.de Geschäftsführer: Markus Sommer, Thomas Zeler Sitz: Friedrichshafen Registergericht: Amtsgericht Ulm HRB-Nr. 631624 Important Note: This e-mail and any attachments are confidential, may contain trade secrets and may well also be legally privileged or otherwise protected from disclosure. If you have received it in error, you are on notice of its status. Please notify us immediately by reply e-mail and then delete his e-mail and any attachment from your system. If you are not the intended recipient please understand that you must not copy this e-mail or any attachments or disclose the contents to any other person. Thank you. -Ursprüngliche Nachricht- Von: Christofer Dutz Gesendet: Dienstag, 28. Mai 2019 10:22 An: dev@plc4x.apache.org Betreff: Re: [BUILDS] What build system to use? Hi all, I'll try to summarize responses to all ( So in general you are quite happy as it currently is, however the C++ module could use simplification. I would suggest that I get rid of the individual pom.xml files and all the packaging and unpacking and change the CMake files to use relative paths in the project structure? In general you are ok with using maven to trigger a native build tool (cmake, python setup.py or dotnet) and to have this build the entire language part of that particular module. I could make the maven plugin work in a way that it can generate code for multiple specs into different directories (think it already allows this anyway) and to run this at the language-root. So a build for any language would be: 1. Generate the code using the plc4x-maven-plugin 2. Execute the native build Beyond that we would need: - Clean by providing extra rules to the maven-clean-plugin to clean up the language dependent directories and resources. - If we want to ship artifacts ... find a way to do so in the package, deploy and install phases (For now this is mostly disabled anyway ... but we should come up with something) Things that are important here is a way to provide the version from maven to the native build tool as otherwise we would have problems releasing. I think I have implemented this at least for dotnet and python ... have to double-check with CMake. I am not focused on using Thrift at all ... it was something you folks came up with and I simply made it work reliably in our build. I do agree that I would prefer not having to build the thrift binary in advance. If you come up with an alternative, I'm happy to replace this. The reason for us building it, was that the Thrift project is not distributing thrift compiler binaries for anything except windows. I could contact them and donate our thrift config to the project and hope they start also distributing other
[DriverGen] Major refactoring and great improvements
Hi all, I just wanted to give you all an update on how we are progressing on the driver generation front. I just pushed some major refactorings which transition the POC more in the direction of something usable. Here the most important changes: * There are Protocol-modules which are discovered similar to how we discover drivers in the classpath * There are now Language-(output)-modules which also are discovered similar to how we discover drivers in the classpath * The input modules generally provide only the spec * The output modules contain everything needed to produce output for a given language * In order to allow experimentation of the output variants the output modules contain everything needed to generate the output * My implementation of a language-template-java uses freemarker to generate output, but others could simply use other techniques So far I have a pojo template that will generate the POJO classes for the types in the spec. Right now I’m working on the little tool that will tell the output which Java type it should use for which spec type … but as soon as that’s done I’m looking forward to implementing the IO components. All of this is happening in the “feature/code-gen” branch … and all my code-generation related code is in sandbox/code-generation So far the update … Chris
