Hi Sönke, found even more interesting stuff ...
https://stackoverflow.com/questions/48751013/jenkins-multibranch-pipeline-only-for-subfolder Seems we can add a new Jenkinsfile in the root that propagates to Jenkinsfiles in the subdirectory, but only for those directory that contains changes. Guess we can omit that. After all I usually added those to other projects in order to welcome total newbees, but in this case I guess most people working on this will not belong to that category. Regarding dependencies ... I guess we can work that out as the problems come in. Right now I would probably solve the extensions jar problem with a multi-module maven build. So I would omit the mvnw stuff, merge the rest and then I'll add a new Jenkinsfile and make sure the infrastructure is up and running again. Chris Am 17.04.19, 20:00 schrieb "Sönke Liebau" <[email protected]>: Thanks Chris! Should I just omit the .mvn and mvnw files completely for now? I think we will probably need to look at Maven structures anyway, I imagine that in the end there will be a few submodules with dependencies amongst themselves, for example building the extensions jar file you mentioned in another thread. Best regards, Sönke On Wed, Apr 17, 2019 at 7:29 PM Christofer Dutz <[email protected]> wrote: > Ok, > > so I had a look at the changes ... > > So I would suggest to move the mvnw and the .mvn back to the root as this > applies to more than just the site build ... but we could even omit it > totally. > Also did I have a look at the Jenkinsfile support in Jenkins ... normally > it wouldn't be found by Jenkins as this is no longer in its default > location. > But the plugin can be configured to look to alternate locations. So we > should be fine if we update that config. > > Would be good however to make sure the site build is only started if > something inside the "site" directory is changed ... will try to find out > how to do that. > > Chris > > Am 17.04.19, 18:36 schrieb "Christofer Dutz" <[email protected]>: > > Please don't merge that as it will break a lot of things. I'm > currently traveling and reviewing on my phone wouldn't be good. > > Chris > > Outlook für Android<https://aka.ms/ghei36> herunterladen > > ________________________________ > From: Sönke Liebau <[email protected]> > Sent: Wednesday, April 17, 2019 4:12:26 PM > To: [email protected] > Subject: Re: Repo structure > > Hi everybody, > > since there were no major objections I've gone ahead and created a pull > request for this. > Only change I made was to rename the "trainings" folder to "sessions" > due > to the discussion around the non-existence of a plural of training. > > Best regards, > Sönke > > On Thu, Apr 11, 2019 at 11:55 AM Sönke Liebau < > [email protected]> > wrote: > > > Hi Frank, > > > > thanks for your mail, overall I totally agree with everything you > said. > > > > Regarding how to organize the content directory, I am unsure about > the > > overall way of doing this. > > I think from what we have already seen we will have very varied > content > > that I'd struggle to sort into lab, slide or any other well defined > > structure. I am personally tending towards ordering this into purely > top > > level directories like "hbase_labs" "hbase_slides" or similar and > then > > taking care of everything else via metadata. > > I think the process of using this will be largely decoupled from the > > actual directory structure anyway, as we'll have metadata and search > > indices for everything, so we might as well keep it simple here.. > > > > Just my two cents :) > > > > On a larger scale, I think if we can agree on the top level > structure to > > start out with and get that committed, then there will probably be > smaller > > groups of people interested in specific directories and can start > > discussions around the structure in there. > > > > Best regards, > > Sönke > > > > > > > > > > > > > > On Thu, Apr 11, 2019 at 11:17 AM Frank Marmann <[email protected]> > wrote: > > > >> Hi, > >> > >> > >> > >> I like the proposed repository structure. I will just write out some > >> thoughts and my understanding to see if it fits your intention. > >> > >> > >> > >> content – below the /content/core/ directory there are specific > subfolders > >> for each topic, which may or may not be related to Apache projects > like > >> HBase, Spark, etc. > >> > >> > >> > >> I am not so sure yet about the language-specific subfolders. We > need to > >> take multiple languages into account, but this applies not only to > content > >> bus also to labs and maybe even to exams. I think this is a > technical > >> decision of how to provide multiple languages. > >> > >> > >> > >> Below the /content/core/<topic>/content/ directory we probably need > the > >> possibility to define training modules for that topic (or call it > building > >> blocks as the term modules might be too overloaded already). For > example: > >> Spark Basics, Spark ML, Spark Streaming, etc. In my option it is a > >> primarily technical decision if these building blocks require > another > >> level > >> of subfolders or if there is one file per building block or > something like > >> that. > >> > >> > >> > >> training – I like the separation of content and the actual > training. But > >> as > >> you already wrote I also see the need to somehow create “releases” > for > >> each > >> of those trainings separately. > >> > >> > >> > >> Looking forward getting this structure up and running! :) > >> > >> > >> > >> Best regards, > >> > >> Frank > >> > >> On Wed, Apr 10, 2019 at 3:49 PM Sönke Liebau > >> <[email protected]> wrote: > >> > >> > Hi everybody, > >> > > >> > I'd like to start a dedicated thread about how to roughly > structure our > >> > repository. > >> > I don't think we need to agree on the final and detailed > structure at > >> this > >> > point in time, but some very high level decisions would be useful > at > >> this > >> > point to enable us to move forward I believe. > >> > > >> > Biggest question is: one repository or multiple? > >> > > >> > My personal opinion is that we can make do with one and it'll be > less > >> > hassle overall. > >> > > >> > Based on that I think we need a few top-level directories: > >> > > >> > content - slide sources > >> > site - source code for the webpage > >> > tools - home to all tooling that we'll potentially develop > >> > trainings - definitions of trainings - these will not contain > actual > >> > content but references to content from the content folder > >> > > >> > None of the names are final or in any way important for me - feel > free > >> to > >> > propose better suitable candidates! > >> > > >> > Lars has created a playground for that in our github account [1] > which > >> we > >> > could use to play around with this a little bit - but I think if > we can > >> at > >> > least agree on the top level structure we might just as well get > that > >> > committed to the Apache repo and then have individual discussions > in the > >> > sub-projects. > >> > > >> > Any thoughts? > >> > > >> > Best regards, > >> > Sönke > >> > > >> > [1] https://github.com/opencore/training-playground > >> > > >> > > > > > > -- > > Sönke Liebau > > Partner > > Tel. +49 179 7940878 > > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany > > > > > -- > Sönke Liebau > Partner > Tel. +49 179 7940878 > OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany > > > -- Sönke Liebau Partner Tel. +49 179 7940878 OpenCore GmbH & Co. KG - Thomas-Mann-Straße 8 - 22880 Wedel - Germany
