You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@plc4x.apache.org by Christofer Dutz <ch...@c-ware.de> on 2019/04/10 18:27:11 UTC

[generation] Progress on the code generation ...

Hi all,

just wanted to keep you all in the loop (I’ll try to use the [generation] as marker for this topic).

I just committed some changes to the “plc4x-maven-plugin”.

And I also noticed I should explain why this module is not integrated into the build.
Maven is quite good at resolving dependencies at runtime and ordering the reactor order accordingly to build what’s needed before it’s needed.
Unfortunately this doesn’t work for plugins. So if we use the “plc4x-maven-plugin” in the rest of the build, building will fail guaranteed and especially during releases get really nasty.
So some time in the future we will have to release this plugin independently from the rest of PLC4X (Hopefully we’ll not have to re-release it too often though).
And being able to release it separately is also the reason why it directly references the Apache parent and not any PLC4X parent.

So now to the plugin … if you want to see a first draft, simply run at least a “mvn package” build inside the “sandbox/plc4x-maven-plugin” directory.
Part of the build is a maven plugin unit test, that executes the build defined in “plc4x-maven-plugin/src/test/projects” in the directory “plc4x-maven-plugin/target/test-projects”.
Please have a look at the later directory to see what it generates in “plc4x-maven-plugin/target/test-projects/GenerateMojoTest_testSomething_simple-embedded-schema/target/generated-sources/plc4x”

Yeah … a lot of directories … but this way you can at least see what I’m up to :)

But still a lot of cleaning up to do … especially the handling of datatypes … currently the xml simpleTypes defined in the schema are used, I have to translate them into language-dependent types …

Chris

Re: [generation] Progress on the code generation ...

Posted by Julian Feinauer <j....@pragmaticminds.de>.
Full ack!

Am 11.04.19, 09:14 schrieb "Christofer Dutz" <ch...@c-ware.de>:

    Yeah I toally agree,
    
    I totally hate this hen-egg type of problem with this special case. 
    But as I chatted with Otto yesterday ... it's in the sandbox/playground for now.
    As soon as it's mature enough to leave the sandbox seems a good time to 
    Do the transfer to another repo ... but for now ... let's keep it simple ;-)
    
    Chris
    
    
    Am 11.04.19, 09:00 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:
    
        Hi Chris,
        
        thanks for sharing, i will definetly have a look : )
        And regarding Ottos point, I agree, that at some point in the future, I would also prefer to have a separate repo, simply to have things simple and well defined without too many tweaks and "Oh, yes, in this case you just have to...".
        This is, from my perspective, against the maven philosophy.
        
        Julian
        
        Am 10.04.19, 20:43 schrieb "Christofer Dutz" <ch...@c-ware.de>:
        
            Yeah ... would be an option, 
            
            but was hesitant to setup a whole separate repo for this one maven module.
            
            But not really got a strong opinion about it ... 
            The "Royals" sort of live with a bunch of deps like that in their repo for years ;-)
            
            Chris
            
            
            
            Am 10.04.19, 20:33 schrieb "Otto Fowler" <ot...@gmail.com>:
            
                Having it separate is the way that Apache Nifi for example does it, down to
                it’s own git repo as well.
                
                
                On April 10, 2019 at 14:27:25, Christofer Dutz (christofer.dutz@c-ware.de)
                wrote:
                
                Hi all,
                
                just wanted to keep you all in the loop (I’ll try to use the [generation]
                as marker for this topic).
                
                I just committed some changes to the “plc4x-maven-plugin”.
                
                And I also noticed I should explain why this module is not integrated into
                the build.
                Maven is quite good at resolving dependencies at runtime and ordering the
                reactor order accordingly to build what’s needed before it’s needed.
                Unfortunately this doesn’t work for plugins. So if we use the
                “plc4x-maven-plugin” in the rest of the build, building will fail
                guaranteed and especially during releases get really nasty.
                So some time in the future we will have to release this plugin
                independently from the rest of PLC4X (Hopefully we’ll not have to
                re-release it too often though).
                And being able to release it separately is also the reason why it directly
                references the Apache parent and not any PLC4X parent.
                
                So now to the plugin … if you want to see a first draft, simply run at
                least a “mvn package” build inside the “sandbox/plc4x-maven-plugin”
                directory.
                Part of the build is a maven plugin unit test, that executes the build
                defined in “plc4x-maven-plugin/src/test/projects” in the directory
                “plc4x-maven-plugin/target/test-projects”.
                Please have a look at the later directory to see what it generates in
                “plc4x-maven-plugin/target/test-projects/GenerateMojoTest_testSomething_simple-embedded-schema/target/generated-sources/plc4x”
                
                
                Yeah … a lot of directories … but this way you can at least see what I’m up
                to :)
                
                But still a lot of cleaning up to do … especially the handling of datatypes
                … currently the xml simpleTypes defined in the schema are used, I have to
                translate them into language-dependent types …
                
                Chris

Re: [generation] Progress on the code generation ...

Posted by Christofer Dutz <ch...@c-ware.de>.
Yeah I toally agree,

I totally hate this hen-egg type of problem with this special case. 
But as I chatted with Otto yesterday ... it's in the sandbox/playground for now.
As soon as it's mature enough to leave the sandbox seems a good time to 
Do the transfer to another repo ... but for now ... let's keep it simple ;-)

Chris


Am 11.04.19, 09:00 schrieb "Julian Feinauer" <j....@pragmaticminds.de>:

    Hi Chris,
    
    thanks for sharing, i will definetly have a look : )
    And regarding Ottos point, I agree, that at some point in the future, I would also prefer to have a separate repo, simply to have things simple and well defined without too many tweaks and "Oh, yes, in this case you just have to...".
    This is, from my perspective, against the maven philosophy.
    
    Julian
    
    Am 10.04.19, 20:43 schrieb "Christofer Dutz" <ch...@c-ware.de>:
    
        Yeah ... would be an option, 
        
        but was hesitant to setup a whole separate repo for this one maven module.
        
        But not really got a strong opinion about it ... 
        The "Royals" sort of live with a bunch of deps like that in their repo for years ;-)
        
        Chris
        
        
        
        Am 10.04.19, 20:33 schrieb "Otto Fowler" <ot...@gmail.com>:
        
            Having it separate is the way that Apache Nifi for example does it, down to
            it’s own git repo as well.
            
            
            On April 10, 2019 at 14:27:25, Christofer Dutz (christofer.dutz@c-ware.de)
            wrote:
            
            Hi all,
            
            just wanted to keep you all in the loop (I’ll try to use the [generation]
            as marker for this topic).
            
            I just committed some changes to the “plc4x-maven-plugin”.
            
            And I also noticed I should explain why this module is not integrated into
            the build.
            Maven is quite good at resolving dependencies at runtime and ordering the
            reactor order accordingly to build what’s needed before it’s needed.
            Unfortunately this doesn’t work for plugins. So if we use the
            “plc4x-maven-plugin” in the rest of the build, building will fail
            guaranteed and especially during releases get really nasty.
            So some time in the future we will have to release this plugin
            independently from the rest of PLC4X (Hopefully we’ll not have to
            re-release it too often though).
            And being able to release it separately is also the reason why it directly
            references the Apache parent and not any PLC4X parent.
            
            So now to the plugin … if you want to see a first draft, simply run at
            least a “mvn package” build inside the “sandbox/plc4x-maven-plugin”
            directory.
            Part of the build is a maven plugin unit test, that executes the build
            defined in “plc4x-maven-plugin/src/test/projects” in the directory
            “plc4x-maven-plugin/target/test-projects”.
            Please have a look at the later directory to see what it generates in
            “plc4x-maven-plugin/target/test-projects/GenerateMojoTest_testSomething_simple-embedded-schema/target/generated-sources/plc4x”
            
            
            Yeah … a lot of directories … but this way you can at least see what I’m up
            to :)
            
            But still a lot of cleaning up to do … especially the handling of datatypes
            … currently the xml simpleTypes defined in the schema are used, I have to
            translate them into language-dependent types …
            
            Chris

Re: [generation] Progress on the code generation ...

Posted by Julian Feinauer <j....@pragmaticminds.de>.
Hi Chris,

thanks for sharing, i will definetly have a look : )
And regarding Ottos point, I agree, that at some point in the future, I would also prefer to have a separate repo, simply to have things simple and well defined without too many tweaks and "Oh, yes, in this case you just have to...".
This is, from my perspective, against the maven philosophy.

Julian

Am 10.04.19, 20:43 schrieb "Christofer Dutz" <ch...@c-ware.de>:

    Yeah ... would be an option, 
    
    but was hesitant to setup a whole separate repo for this one maven module.
    
    But not really got a strong opinion about it ... 
    The "Royals" sort of live with a bunch of deps like that in their repo for years ;-)
    
    Chris
    
    
    
    Am 10.04.19, 20:33 schrieb "Otto Fowler" <ot...@gmail.com>:
    
        Having it separate is the way that Apache Nifi for example does it, down to
        it’s own git repo as well.
        
        
        On April 10, 2019 at 14:27:25, Christofer Dutz (christofer.dutz@c-ware.de)
        wrote:
        
        Hi all,
        
        just wanted to keep you all in the loop (I’ll try to use the [generation]
        as marker for this topic).
        
        I just committed some changes to the “plc4x-maven-plugin”.
        
        And I also noticed I should explain why this module is not integrated into
        the build.
        Maven is quite good at resolving dependencies at runtime and ordering the
        reactor order accordingly to build what’s needed before it’s needed.
        Unfortunately this doesn’t work for plugins. So if we use the
        “plc4x-maven-plugin” in the rest of the build, building will fail
        guaranteed and especially during releases get really nasty.
        So some time in the future we will have to release this plugin
        independently from the rest of PLC4X (Hopefully we’ll not have to
        re-release it too often though).
        And being able to release it separately is also the reason why it directly
        references the Apache parent and not any PLC4X parent.
        
        So now to the plugin … if you want to see a first draft, simply run at
        least a “mvn package” build inside the “sandbox/plc4x-maven-plugin”
        directory.
        Part of the build is a maven plugin unit test, that executes the build
        defined in “plc4x-maven-plugin/src/test/projects” in the directory
        “plc4x-maven-plugin/target/test-projects”.
        Please have a look at the later directory to see what it generates in
        “plc4x-maven-plugin/target/test-projects/GenerateMojoTest_testSomething_simple-embedded-schema/target/generated-sources/plc4x”
        
        
        Yeah … a lot of directories … but this way you can at least see what I’m up
        to :)
        
        But still a lot of cleaning up to do … especially the handling of datatypes
        … currently the xml simpleTypes defined in the schema are used, I have to
        translate them into language-dependent types …
        
        Chris

Re: [generation] Progress on the code generation ...

Posted by Christofer Dutz <ch...@c-ware.de>.
Yeah ... would be an option, 

but was hesitant to setup a whole separate repo for this one maven module.

But not really got a strong opinion about it ... 
The "Royals" sort of live with a bunch of deps like that in their repo for years ;-)

Chris



Am 10.04.19, 20:33 schrieb "Otto Fowler" <ot...@gmail.com>:

    Having it separate is the way that Apache Nifi for example does it, down to
    it’s own git repo as well.
    
    
    On April 10, 2019 at 14:27:25, Christofer Dutz (christofer.dutz@c-ware.de)
    wrote:
    
    Hi all,
    
    just wanted to keep you all in the loop (I’ll try to use the [generation]
    as marker for this topic).
    
    I just committed some changes to the “plc4x-maven-plugin”.
    
    And I also noticed I should explain why this module is not integrated into
    the build.
    Maven is quite good at resolving dependencies at runtime and ordering the
    reactor order accordingly to build what’s needed before it’s needed.
    Unfortunately this doesn’t work for plugins. So if we use the
    “plc4x-maven-plugin” in the rest of the build, building will fail
    guaranteed and especially during releases get really nasty.
    So some time in the future we will have to release this plugin
    independently from the rest of PLC4X (Hopefully we’ll not have to
    re-release it too often though).
    And being able to release it separately is also the reason why it directly
    references the Apache parent and not any PLC4X parent.
    
    So now to the plugin … if you want to see a first draft, simply run at
    least a “mvn package” build inside the “sandbox/plc4x-maven-plugin”
    directory.
    Part of the build is a maven plugin unit test, that executes the build
    defined in “plc4x-maven-plugin/src/test/projects” in the directory
    “plc4x-maven-plugin/target/test-projects”.
    Please have a look at the later directory to see what it generates in
    “plc4x-maven-plugin/target/test-projects/GenerateMojoTest_testSomething_simple-embedded-schema/target/generated-sources/plc4x”
    
    
    Yeah … a lot of directories … but this way you can at least see what I’m up
    to :)
    
    But still a lot of cleaning up to do … especially the handling of datatypes
    … currently the xml simpleTypes defined in the schema are used, I have to
    translate them into language-dependent types …
    
    Chris

Re: [generation] Progress on the code generation ...

Posted by Otto Fowler <ot...@gmail.com>.
Having it separate is the way that Apache Nifi for example does it, down to
it’s own git repo as well.


On April 10, 2019 at 14:27:25, Christofer Dutz (christofer.dutz@c-ware.de)
wrote:

Hi all,

just wanted to keep you all in the loop (I’ll try to use the [generation]
as marker for this topic).

I just committed some changes to the “plc4x-maven-plugin”.

And I also noticed I should explain why this module is not integrated into
the build.
Maven is quite good at resolving dependencies at runtime and ordering the
reactor order accordingly to build what’s needed before it’s needed.
Unfortunately this doesn’t work for plugins. So if we use the
“plc4x-maven-plugin” in the rest of the build, building will fail
guaranteed and especially during releases get really nasty.
So some time in the future we will have to release this plugin
independently from the rest of PLC4X (Hopefully we’ll not have to
re-release it too often though).
And being able to release it separately is also the reason why it directly
references the Apache parent and not any PLC4X parent.

So now to the plugin … if you want to see a first draft, simply run at
least a “mvn package” build inside the “sandbox/plc4x-maven-plugin”
directory.
Part of the build is a maven plugin unit test, that executes the build
defined in “plc4x-maven-plugin/src/test/projects” in the directory
“plc4x-maven-plugin/target/test-projects”.
Please have a look at the later directory to see what it generates in
“plc4x-maven-plugin/target/test-projects/GenerateMojoTest_testSomething_simple-embedded-schema/target/generated-sources/plc4x”


Yeah … a lot of directories … but this way you can at least see what I’m up
to :)

But still a lot of cleaning up to do … especially the handling of datatypes
… currently the xml simpleTypes defined in the schema are used, I have to
translate them into language-dependent types …

Chris