Would we need to have the URLs like these? github/apache/***/repo https://github.com/apache/*maven-plugins*/maven-clean-plugin/ https://github.com/apache/*maven-shared*/maven-shared-utils/
On Sun, Oct 8, 2017 at 4:55 AM, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > 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: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
