One more thing (after SVN refactoring was done) it seems really beneficial to set up at least 2 or 3 separate Jenkins builds. Whether or not one "root POM" even still makes sense, please let's discuss when the time comes, but probably better to use "downstream" jobs like many other Apache projects do. Including log4net: https://builds.apache.org/job/log4net-trunk-build/ so either the vbnet or C# client or both should also be CI capable on a dedicated Jenkins node, just like the one Log4Net uses.
A "Data x.x" build (over time at least a 1.x and 2.x stream should exist) triggers all dependent clients if data they use changed. Clients used by a top level /examples may then be used as their trigger. You also see this with log4net where the library job triggers "examples" and "tests" (in Maven usually one build job) So 1 or more "data" jobs plus a job for each "clients" that can use Jenkins and maybe one for "examples" sounds reasonable. Clients or languages that can't build on Jenkins, see Browsermap or Konstantin's Ruby port on GitHub would just use their CI server like Travis, those that Jenkins nodes on Apache supports should have Jenkins jobs at builds.apache. Let's change the architecture, then I may start a separate thread for this. Werner On Wed, Apr 22, 2015 at 3:46 PM, Werner Keil <[email protected]> wrote: > Ok, that makes it easier. Just recall > https://www.apache.org/foundation/voting.html said > 1) Code Modifications, but if that is not binding to any modification or > "refactoring" like this, then the thread here also showed consensus by all > who said something. > > Whoever does their share, make sure the root POM other than /data which > should not be subject to change here gets updated. If you need help with > the > relationship between devicemap/java/simpleddr and devicemap/java/lib, > just ask for help. > > Otherwise, please move the lib folder under the new clients/w3c-ddr > without adding the module to the POM yet, I can fix the > addjars-maven-plugin. > You will need the same lib folder under classifier_w3c_simple whatever its > name and location would be, if intended to build. The Maven modules are > unrelated as Bertrand stated, so unless there was a /clients/lib or > /clients/shared folder for these things, each module must have its own > self-contained folders for that. The W3C JAR is also rather small so no big > overhead. > > Werner > > On Wed, Apr 22, 2015 at 3:26 PM, Bertrand Delacretaz < > [email protected]> wrote: > >> Hi, >> >> On Wed, Apr 22, 2015 at 3:09 PM, Werner Keil <[email protected]> >> wrote: >> > ...I suppose >> > this being a change to the codebase, a formal vote on the private list >> > should take place for it... >> >> No, we usually vote on the private list only for issues related to >> people, like elections. >> >> In this case, as we seem to have consensus here I don't see a need for a >> vote. >> >> Reza, would you have time to do the svn changes? Otherwise I might be >> able to do that at the end of this week. >> >> -Bertrand >> > >
