TLDR; = Perhaps we can start with 2 proofs of concept: 1. full git clone + Jenkins jobs for the 7 existing git repos (with 6 additional ones in 2 days) 2. git split of one of the aggregator svn trunk: skins or doxia-tools can be easy choices since they are light, where plugins or shared are perhaps too heavy. The one working on this PoC will make his choice
then more detailed answer inline that lead to this PoCs proposal Regards, Hervé Le dimanche 8 octobre 2017, 00:02:10 CEST Tibor Digana a écrit : > I don't think the devs would work on all artifacts(projects) a time. sure, I think I'm one of the few people working on near everything (with rare exceptions like Surefire, as you noticed :) ) but for usual contributor, there is no issue I'm not a git expert, then I don't know if easy "full Maven clone" is better done with a shell script or some git modules > If the naming convention of repo for a plugin would be artifactId, like > /maven-clean-plugin, then even easy to figure out which one to clone. > The most likely the dev would just clone one repo she/he is interested in > at the moment, i.e. repository /maven-clean-plugin, let's say. > It's good to avoid any shared files across them, even I don't think devs > share some in svn today. The release process would be quite usual, i.e. one > repo = one project, and new devs already have these experiences which will > be simple for them to adapt faster. +1 the only drawback I see currently is that there is no natural grouping, then we have a flat lit of near 100 git repos without the current structure (plugins, shared components, skins, ...): I think components structure is useful for maintenability but not really a complete showstopper and perhaps the "Maven full clone" tooling can re-create some grouping to keep visible structure Now, someone has to know how to create per-component git repo with tags (either by reworking exiting git mirrors, either by restarting from svn), and that's not me :) given the volume (adding 70 git repos for Maven), we'll have to tell infra about it. Then there is the Jenkins jobs configuration: - we need easy Jenkinsfile in each repo - we need easy 80 jobs creation (no, I won't manually create 80 jobs personally) And once again, infra will have to be in the loop (at Jenkins side this time), since I fear the load on Jenkins master node won't be light: perhaps that's where Jenkins folders will be useful, but I'm not a Jenkins expert either. If everything seems feasible to split our svn code into 1 git repo per- component, which will bring us to "full Maven code" being near 100 repos, I'm ok with it. We'll need the help of misc experts on Jenkins and git to prepare things at this scale. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
