plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: Rearrange modules according to their language?
Date Mon, 29 Apr 2019 14:01:15 GMT
Hi all,

I just pushed a feature branch "feature/sorted-examples-integrations" which moves the integration
modules and examples to the language they are based on.
This made it possible to move the java configuration into the "plc4j" module.

Please have a look and comment.


Chris

Am 29.04.19, 10:54 schrieb "Julian Feinauer" <j.feinauer@pragmaticminds.de>:

    Hi Chris,
    
    I agree with you and with the latest work you have done it gets more and more concise,
I guess.
    So lets finish PLC4X-111 and then see where it brings us.
    And perhaps a solution could also be to simply bring the "proxy" thing out of the other
structure as this would keep the build there (because modules are pretty tightly coupled),
perhaps even without submodules for other languages... and only have those on Top Level.
    
    Julian
    
    PS.: It really is an art to write short and concise emails... and it seems like we're
only mediocre talented : /
    
    Am 29.04.19, 10:25 schrieb "Christofer Dutz" <christofer.dutz@c-ware.de>:
    
        Hi Julian,
        
        just saw that I didn't respond to that email ... gotta add my thoughts ;-)
        
        I would totally put all +1s I have (which is 1) into arranging the project by language.
The reason for this is the complexity of the build.
        If we put all Java stuff into plc4j and all C++ stuff into plc4cpp and all python
stuff into plc4py, we can define all the settings in that particular root module and inherit
them to all sub modules. This would prevent Java setting from leaking into c++ modules (Currently
the build seems to be running JavaDoc on C++ code ;-) ) 
        
        While maven would allow separating the directory structure from the pom structure,
however I have used this several times before and it was always a nightmare in the end. 
        
        We're currently not only using Maven ... maven is the coordinator. For the C++ modules
we are using CMake which seems to be doing a great job for building on multiple platforms
and Tool- and IDE-Support. I would try to stick to maven as close as possible though. Keep
in mind, when doing releases we have to do quite a lot of stuff to comply to Apache's rules.
With this "Maven as master build" we get a lot of bases covered: RAT checks, Source distribution
building, signing, staging, ... If we start splitting up into separate builds. We have to
ensure all of these for each build tool and especially we have to learn all of these in order
to be able to maintain things.
        
        Right now regarding the tooling and as I already stated in multiple chats: I would
like to make the build as simple as possible for new people to setup. I have worked in other
Apache projects where it tool multiple attempts and hours of setting up before being able
to start. This is the horror scenario, I would like to avoid. So I thought we should keep
the parts that are very general outside the project, but the parts we need control over the
version inside. So as an example, If we use Thrift for the proxies and the intermediate drivers,
we need to have control over the version of the Thrift compiler used. If we don't we are guaranteed
to get problems when updating to newer Thrift versions and we'll have to deal with those support
complaints that arise from this. Also if in the C++ module, the base framework is Boost, this
also has great impact on the code, having different versions of Boost could also produce hard
to diagnose errors. That's the reason I updated the build to download and build exactly those
versions we are using. So if for example we use a newer version of Thrift, we update a property
in the master pom and run the build and it will build and use exactly that thrift version.
        
        There's nothing that scares new committers more than not being able to checkout and
build the project in reasonable time. That’s why I'm investing so much time in the build,
cause I know this is probably the most crucial part in getting new people on board.
        
        Chris
        
        PS: I really hope we won't continue these mega-email threads ... I really hate when
emails I write and read exceed a screen size ;-)
        
        
        
        
        Am 27.04.19, 19:20 schrieb "Julian Feinauer" <j.feinauer@pragmaticminds.de>:
        
            Hi Chris,
            
            first, thank you for all your work on the build.
            One feat that gets stronger and stronger for me is the complexity of our build,
which I dislike.
            I know that this is a necessity of our current setup but I think we have to do
something about it as the build himself currently has the complexity of a simple driver but
"no" testcoverage and is very hard to debug (and very few are able to maintain or even understand
it, myself included).
            
            So I think we have to think about how we can change this and this is, from my
perspective the most important issue and should drive how we organize our modules.
            
            This includes questions like
            - should we organize by language or by "role" (which is basically your question)
            - should we only use maven as driver for the build or should we decouple all builds
and leave it to Jenkins to execute all of these
            - should we split repos or should we keep one repo as it is currently
            - how do we handle interdependencies between different languages
            - how to we deal with general "tools" in the build pipeline (longer idempotent
build vs complexer individual setup)
            
            I know that some of these suggestions would imply large changes but I think we
should not drive these important decisions.
            
            Julian
            
            Am 27.04.19, 18:43 schrieb "Christofer Dutz" <christofer.dutz@c-ware.de>:
            
                Hi all,
                
                currently we have a structure where Java modules are located in plc4j, c++
modules in plc4cpp and python modules in plc4py … however the integration modules and examples
are at root level.
                
                Even if we don’t yet have any non java integration modules or examples,
we will be getting some in the near future. What is observable, is that Java plugin configuration
is leaking over to the cpp and python modules, which isn’t good.
                
                For the sake of a simpler build and cleaner configuration, I would propose
to create integrations and examples modules inside each of the language directories and to
move the existing modules there.
                
                What do you think?
                
                Chris
                
            
            
        
        
    
    

Mime
View raw message