any git expert available to tell us if submodules are what we're looking for? And will permit something like svn trunks [1], ie use each submodule to commit independantly, while having easy full code clone or pull.
IIUC, we'll have to learn new git commands, since it's not as transparent as svn externals and to have plugins/ and shared/ directories, are we able to have a submodule name with a /, or will we need to create plugins.git and shared.git containing submodules for each component, then reference these repos from the global git repo listing sub modules? once again, a personal git repo on github having submodules to existing maven got repos could make a good PoC: I'm working on m-pdf-p currently, so maybe someone can beat me at it... Regards, Hervé [1] http://svn.apache.org/viewvc/maven/trunks/ Le dimanche 8 octobre 2017, 13:09:58 CEST Tibor Digana a écrit : > Now I have found out that GitHub has submodules. This does not introduce an > intermediate path in URL but it would introduce a kind of groupper repo > folder. For instance maven-clean-plugin would be submodule inside repo > maven-plugins. > References: > https://stackoverflow.com/questions/35043733/how-do-i-create-nested-reposito > ries-in-github > > Example from stackoveflow: > https://github.com/laristra/cinch-nested-example/ > See the definition of submodules > https://github.com/laristra/cinch-nested-example/blob/master/.gitmodules > which results in repos: > https://github.com/laristra/cinch-example/ > https://github.com/laristra/cinch > > I think GitHub does not provide us with better solutions. > > On Sun, Oct 8, 2017 at 12:49 PM, Hervé BOUTEMY <herve.bout...@free.fr> > > wrote: > > I fear this is not an option today, but ideally, that would be a perfectly > > visible grouping > > > > we need to find another way of grouping, for people who do care about > > Maven > > general structure: people who just work on an artifact just don't care > > and they don't care that git repos are flat even at Apache level: Apache > > level > > just enforce grouping via repo name prefix > > http://git.apache.org/ > > > > currently, I hope that our "full Maven source code clone" implementation > > would > > make the Maven code structure grouping visible > > if we implement it as a shell script, that's only a few mkdirs: but I'm > > not > > convinced by shell script implementation, since cloning is one command, > > but we > > need also to be able to fetch and pull > > > > Regards, > > > > Hervé > > > > Le dimanche 8 octobre 2017, 12:21:54 CEST Tibor Digana a écrit : > > > 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 > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
