from a pure syntax perspective, now I see the proposal from an implementation point of view, I don't want to be pessimistic, but this would require a dependency from Maven core to maven-scm and a complexity during reactor pom parsing.
and if in theory this could solve the initial clone question, this would not provide pull/fetch IMHO, better to have a basic shell script completely independant of Maven Regards, Hervé Le lundi 9 octobre 2017, 20:49:14 CEST Robert Scholte a écrit : > An example: > > <project> > <modules> > <module>sub1</module> <!-- directory --> > <module>sub2/custom-pom.xml</module> <!-- folder --> > > <!-- proposal --> > > <module>scm:git:https://git-wip-us.apache.org/repos/asf/maven-clean-plugin. > git</module> <!-- scm based --> > <modules> > </project> > > > On Mon, 09 Oct 2017 00:01:29 +0200, Hervé BOUTEMY <[email protected]> > > wrote: > > I don't really understand these answers: a demo, please > > > > Regards, > > > > Hervé > > > > Le dimanche 8 octobre 2017, 20:32:29 CEST Robert Scholte a écrit : > >> On Sun, 08 Oct 2017 20:27:17 +0200, Stephen Connolly > >> > >> <[email protected]> wrote: > >> > On Sun 8 Oct 2017 at 18:28, Hervé BOUTEMY <[email protected]> > >> > >> wrote: > >> >> I don't get the technical details > >> >> but IIUC, you're able to do a PoC with our available git > >> > >> repositories of > >> > >> >> Jenkins job maintenance (easy job creation + easy Jenkinsfile > >> >> maintenance), > >> > > >> > Job created automatically once there is a git repo with a branch > >> > >> with a > >> > >> > Jenkinsfile . No human interaction required after `echo > >> > “mavenProjectStdBuild();” > Jenkinsfile && git add Jenkinsfile && git > >> > commit “add Jenkinsfile” && git push` > >> > > >> > Jenkinsfile being just one line `mavenProjectStdBuild` or something > >> > >> like > >> > >> > that. > >> > > >> > Is that easy enough? > >> > >> IIRC there is this proposal to let pom modules support directories, pom > >> locations (these are already supported) and SCM references. Might be > >> interesting for an aggregator pom. > >> > >> Robert > >> > >> > and > >> > > >> >> you're confident that it can scale to the size we're expecting when > >> >> we're > >> >> splitting the current aggregator svn to many small git repos > >> >> > >> >> that's it? > >> >> > >> >> Regards, > >> >> > >> >> Hervé > >> >> > >> >> Le dimanche 8 octobre 2017, 16:21:10 CEST Stephen Connolly a écrit : > >> >> > On Sun 8 Oct 2017 at 03:55, Hervé BOUTEMY <[email protected]> > >> >> > >> >> 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 > >> >> > > >> >> > so we create a shared Groovy library like the Jenkins project does > >> > >> and > >> > >> >> the > >> >> > >> >> > Jenkinsfile becomes `buildPlugin` for all except core > >> >> > > >> >> > > - we need easy 80 jobs creation (no, I won't manually create 80 > >> > >> jobs > >> > >> >> > > personally) > >> >> > > >> >> > So I will add SCMNavigator functionality to the ASF git-Jenkins > >> > >> plugin > >> > >> >> and > >> >> > >> >> > we just define an org-folder for Maven and all git repos with a > >> >> > >> >> Jenkinsfile > >> >> > >> >> > will be auto-maintained. > >> >> > > >> >> > > 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 we use an org folder integrated with GitPubSub I do not think > >> > >> they > >> > >> >> will > >> >> > >> >> > be overly concerned > >> >> > > >> >> > > 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. > >> >> > > >> >> > I think one repo per release root is the way to go. > >> >> > > >> >> > We should start by drawing up a list and amalgamation where > >> >> > >> >> appropriate: > >> >> > Eg > >> >> > > >> >> > * does it make sense to release maven-deploy-plugin and > >> >> > maven-install-plugin independently? Seems we most often make > >> > >> mirroring > >> > >> >> > changes to both, and perhaps it would be better if we forced that > >> >> > >> >> model? > >> >> > >> >> > (Don’t answer in this thread, just pointing out an example) > >> >> > >> >> --------------------------------------------------------------------- > >> >> > >> >> > > To unsubscribe, e-mail: [email protected] > >> >> > > For additional commands, e-mail: [email protected] > >> >> > > > >> >> > > -- > >> >> > > >> >> > Sent from my phone > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> -- > >> > > >> > Sent from my phone > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
