Re: Migration of remaining plugins to Git
So the alternate strategy (to what I tested 11 hrs ago) would be to change the release plugin so that it can do its work on a sub-directory safely. cd cd maven-changes-plugin mvn release:prepare mvn release:perform We note after the event that the release was* tagged in SCM with something strong like 'maven-changes-plugin-3.0.0'*. We also silently lament that Git doesn't have branch mappings like Perforce. Indeed, just one small aspect of branch mapping - the ability to remove sections of the tree in the branch and* maintain that divergence going forwards*. Of course tags are not branches, but you know what I mean. In Git given it's content based storage, there's no storage downsides from a branch/tag for 'maven-changes-plugin-3.0.0' also containing all other plugins. Well no storage downsides ignoring working copy (the checkout). - Paul On Tue, Jun 27, 2017 at 8:14 PM, Paul Hammant wrote: > OK, I tried something new. > > *Goal*: all the plugins in one Git repo (less CI jobs to set up - just > one recursive multi-module maven build). > *Constraint*: Plugins must be independently releasable. > > *Test:* Take two modules from the Svn repo and check them in to master > (the rest were deleted - test needs two and a parent pom in master). > > *Repository*: https://github.com/paul-hammant/ph_testplugins > > Of the two modules checked in, maven-changes-plugin is the one I attempted > to release to my com/paulhammant/ group on 'Central. The workflow for the > release of that single module is here https://github.com/paul- > hammant/ph_testplugins/blob/master/CHANGES_PLUGIN_RELEASE_WORKFLOW.md > > *Result of Test:* failed, but in a surprising way and at a very late stage > > During the release:perform stage the maven tried to push to > https://oss.sonatype.org/content/repositories/snapshots > /com/paulhammant/testplugins-ph-chgs-pi/3.0.0-SNAPSHOT/ > testplugins-ph-chgs-pi-3.0.0-20170627.234743-1.jar which is nuts because > I'm not trying to push to a SNAPSHOT, I'm trying to do a proper release of > 3.0.0 (of my renamed to an obscure name plugin). > > The documentation for the part of the pom says that it honors the > name of the local branch for the sequence of commits that the release > plugin does. Which is exactly what you'd want. I've already tested it a > dozen times and it does the right thing by way of tags too. It's only that > SNAPSHOT weirdness during the upload that ends the experiment, and that's a > fairly late stage piece. My plan was to go onto oss.sonatype.org and > delete it from staging so it would ultimately go nowhere. > > Barring that bug, this would work for all of the Maven plugins in a single > repo, meaning a lot less permutations for CI, albeit with a longer build > per commit. I don't think that last is a big issue for this proposed > repository. > > Any of you could clone the repo I have made, and do the same steps as > CHANGES_PLUGIN_RELEASE_WORKFLOW.md document to get to the same place I > got to (a 401 error from Sonatype's DAV infra). And one of you could tell > me what I did wrong with the setup to encounter that snapshot issue :) > > - Paul > > > > >
Re: Migration of remaining plugins to Git
OK, I tried something new. *Goal*: all the plugins in one Git repo (less CI jobs to set up - just one recursive multi-module maven build). *Constraint*: Plugins must be independently releasable. *Test:* Take two modules from the Svn repo and check them in to master (the rest were deleted - test needs two and a parent pom in master). *Repository*: https://github.com/paul-hammant/ph_testplugins Of the two modules checked in, maven-changes-plugin is the one I attempted to release to my com/paulhammant/ group on 'Central. The workflow for the release of that single module is here https://github.com/paul-hammant/ph_testplugins/blob/master/CHANGES_PLUGIN_RELEASE_WORKFLOW.md *Result of Test:* failed, but in a surprising way and at a very late stage During the release:perform stage the maven tried to push to https://oss.sonatype.org/content/repositories/snapshots /com/paulhammant/testplugins-ph-chgs-pi/3.0.0-SNAPSHOT/testplugins-ph-chgs-pi-3.0.0-20170627.234743-1.jar which is nuts because I'm not trying to push to a SNAPSHOT, I'm trying to do a proper release of 3.0.0 (of my renamed to an obscure name plugin). The documentation for the part of the pom says that it honors the name of the local branch for the sequence of commits that the release plugin does. Which is exactly what you'd want. I've already tested it a dozen times and it does the right thing by way of tags too. It's only that SNAPSHOT weirdness during the upload that ends the experiment, and that's a fairly late stage piece. My plan was to go onto oss.sonatype.org and delete it from staging so it would ultimately go nowhere. Barring that bug, this would work for all of the Maven plugins in a single repo, meaning a lot less permutations for CI, albeit with a longer build per commit. I don't think that last is a big issue for this proposed repository. Any of you could clone the repo I have made, and do the same steps as CHANGES_PLUGIN_RELEASE_WORKFLOW.md document to get to the same place I got to (a 401 error from Sonatype's DAV infra). And one of you could tell me what I did wrong with the setup to encounter that snapshot issue :) - Paul
Re: Migration of remaining plugins to Git
Using JobDSL is effectively another approach It's main avantage is to easily keep the control at Jenkins Admin level of what is done instead of delegating it to projects developers On Sat, Jun 24, 2017 at 8:44 AM, Hervé BOUTEMY wrote: > I was thinking at something like the Maven Jenkins Seeding experiment [1] > that > was done, with its DSL code [2] > > IIUC, this new Jenkins feature could provide a more generic seeding? > Looks promising. > > Whether we go with first or second option will be a matter of ETA and > people > wanting to work on it: I'm supportive of both approaches :) > > Regards, > > Hervé > > [1] https://builds.apache.org/view/M-R/view/Maven/job/maven- > jenkins-seeding/ > > [2] http://svn.apache.org/viewvc/maven/jenkins-seeding/ > > Le mardi 20 juin 2017, 22:02:14 CEST Stephen Connolly a écrit : > > On Tue 20 Jun 2017 at 20:29, Arnaud Héritier > wrote: > > > Stephen knows more the ASF infra than me to tell if it is possible but > in > > > Jenkins we have the notion of organization folder for GitHub which > allow > > > to > > > automatically browse an org in GitHub and create/update/delete > > > multibranches jobs for each repo. If we can also create shared > libraries > > > in > > > Jenkins our JenkinsFile could just be a line: buildPlugin() like we do > in > > > jenkins project. > > > > Now that I have landed JENKINS-43507 it should be relatively easy for me > to > > write a SCMNavigator for the ASF hosted repositories. > > > > That would give us a folder where all jobs for plugins etc would be > > auto-created based on the presence of a Jenkinsfile. > > > > With a shared library we can then give them all a standard build with a > > nice simple Jenkinsfile that is just one line. > > > > If people are interested I can prototype the SCMNavigator > > > > > Le mar. 20 juin 2017 à 21:14, Hervé BOUTEMY a > > > > > > écrit : > > > > as explained in the git migration status [1], the biggest issue with > > > > plugins 1 > > > > svn repo to 41 git repo migration is the maintenance of Jenkins job > > > > > > files, > > > > > > > with > > > > their java + maven version matrix. > > > > With Jenkinsfile as worked out in Mavne core, same type of > configuration > > > > could > > > > help us to change our 10 aggregate Jenkins jobs to 41 individual jobs > > > > > > > > Would it be possible to create an aggregator Jenkins job that would > > > > > > create > > > > > > > the > > > > 41 plugins jobs? > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa > collectionofgitrepos > > > > > > > Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit : > > > > > I think the plugins are descoped for a while. > > > > > > > > > > How about https://github.com/apache-maven/ ? > > > > > > > > > > Luckily GitHub does 302s just find if things get renamed or moved > > > > > > between > > > > > > > > orgs. > > > > > > > > > > - Paul > > > > > > > > > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik < > > > > > > bindulbhow...@gmail.com > > > > > > > > wrote: > > > > > > Paul, > > > > > > > > > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant > > > > > > > > > wrote: > > > > > > > Back from Github's suggestions team: "Currently, we don't have > the > > > > > > > > > > > > ability > > > > > > > > > > > > > to group repos beyond the organization level, but I'll > definitely > > > > > > > > > > > > consider > > > > > > > > > > > > > this a feature request." > > > > > > > > > > > > Until such time, how about grouping the repositories by name, > like > > > > > > https://github.com/apache/maven-plugin- > > > > > > > > > > > > A number of other projects in Apache have done this, for example > > > > > > https://git-wip-us.apache.org/repos/asf?a=project_list&s= > > > > > > incubator-predictionio > > > > > > or https://gitbox.apache.org/repos/asf?a=project_list&s= > > > > > > incubator-openwhisk > > > > > > > > > > > > - Bindul > > > > > > > > > > > > > - Paul > > > > > > > > > > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant < > p...@hammant.org> > > > > > > > > wrote: > > > > > > >> I met Chris Wanstrath at a meetup in Cincinatti about four > years > > > > > > > > ago, > > > > > > > > > > and > > > > > > > > > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll) > was as > > > > > > a > > > > > > > > > CMS. I > > > > > > > > > > > > >> suggested that if they could add themes for "high school", > > > > > > > > "community > > > > > > > > > > >> group", etc they could pull in another category of user of the > > > > > > > > > > > > platform, and > > > > > > > > > > > > >> that the themes that are available for gh-pages are not that > > > > > > useful > > > > > > > as > > > > > > > > > > they > > > > > > > > > > > > >> are. > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> ^ screencap from today: unchanged :( > > > > > > >> > > > > > > >> On Sun, Jun 18, 2017 at
Re: Migration of remaining plugins to Git
I was thinking at something like the Maven Jenkins Seeding experiment [1] that was done, with its DSL code [2] IIUC, this new Jenkins feature could provide a more generic seeding? Looks promising. Whether we go with first or second option will be a matter of ETA and people wanting to work on it: I'm supportive of both approaches :) Regards, Hervé [1] https://builds.apache.org/view/M-R/view/Maven/job/maven-jenkins-seeding/ [2] http://svn.apache.org/viewvc/maven/jenkins-seeding/ Le mardi 20 juin 2017, 22:02:14 CEST Stephen Connolly a écrit : > On Tue 20 Jun 2017 at 20:29, Arnaud Héritier wrote: > > Stephen knows more the ASF infra than me to tell if it is possible but in > > Jenkins we have the notion of organization folder for GitHub which allow > > to > > automatically browse an org in GitHub and create/update/delete > > multibranches jobs for each repo. If we can also create shared libraries > > in > > Jenkins our JenkinsFile could just be a line: buildPlugin() like we do in > > jenkins project. > > Now that I have landed JENKINS-43507 it should be relatively easy for me to > write a SCMNavigator for the ASF hosted repositories. > > That would give us a folder where all jobs for plugins etc would be > auto-created based on the presence of a Jenkinsfile. > > With a shared library we can then give them all a standard build with a > nice simple Jenkinsfile that is just one line. > > If people are interested I can prototype the SCMNavigator > > > Le mar. 20 juin 2017 à 21:14, Hervé BOUTEMY a > > > > écrit : > > > as explained in the git migration status [1], the biggest issue with > > > plugins 1 > > > svn repo to 41 git repo migration is the maintenance of Jenkins job > > > > files, > > > > > with > > > their java + maven version matrix. > > > With Jenkinsfile as worked out in Mavne core, same type of configuration > > > could > > > help us to change our 10 aggregate Jenkins jobs to 41 individual jobs > > > > > > Would it be possible to create an aggregator Jenkins job that would > > > > create > > > > > the > > > 41 plugins jobs? > > > > > > Regards, > > > > > > Hervé > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > > > > Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit : > > > > I think the plugins are descoped for a while. > > > > > > > > How about https://github.com/apache-maven/ ? > > > > > > > > Luckily GitHub does 302s just find if things get renamed or moved > > > > between > > > > > > orgs. > > > > > > > > - Paul > > > > > > > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik < > > > > bindulbhow...@gmail.com > > > > > > wrote: > > > > > Paul, > > > > > > > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant > > > > > > wrote: > > > > > > Back from Github's suggestions team: "Currently, we don't have the > > > > > > > > > > ability > > > > > > > > > > > to group repos beyond the organization level, but I'll definitely > > > > > > > > > > consider > > > > > > > > > > > this a feature request." > > > > > > > > > > Until such time, how about grouping the repositories by name, like > > > > > https://github.com/apache/maven-plugin- > > > > > > > > > > A number of other projects in Apache have done this, for example > > > > > https://git-wip-us.apache.org/repos/asf?a=project_list&s= > > > > > incubator-predictionio > > > > > or https://gitbox.apache.org/repos/asf?a=project_list&s= > > > > > incubator-openwhisk > > > > > > > > > > - Bindul > > > > > > > > > > > - Paul > > > > > > > > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant > > > > > > wrote: > > > > > >> I met Chris Wanstrath at a meetup in Cincinatti about four years > > > > > > ago, > > > > > > > > and > > > > > > > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll) was as > > > > a > > > > > > > CMS. I > > > > > > > > > > >> suggested that if they could add themes for "high school", > > > > > > "community > > > > > > > > >> group", etc they could pull in another category of user of the > > > > > > > > > > platform, and > > > > > > > > > > >> that the themes that are available for gh-pages are not that > > > > useful > > > > > as > > > > > > > > they > > > > > > > > > > >> are. > > > > > >> > > > > > >> > > > > > >> > > > > > >> ^ screencap from today: unchanged :( > > > > > >> > > > > > >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly > > > > > >> > > > > > >> wrote: > > > > > >>> Polite, yes, just non commital ;-) > > > > > >>> > > > > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant > > > > > > wrote: > > > > > >>> > They're always very polite for things that I ask for, but I > > > > can't > > > > > > > claim > > > > > > > > > > >>> > to > > > > > >>> > have suggested anything that got implemented. I've a better > > > > > > hit-rate > > > > > > > > >>> > with > > > > > >>> > JetBrains and their IDEs. > > > > > >>> > > > > >
Re: Migration of remaining plugins to Git
+1 for me On Wed, Jun 21, 2017 at 12:02 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > On Tue 20 Jun 2017 at 20:29, Arnaud Héritier wrote: > > > Stephen knows more the ASF infra than me to tell if it is possible but in > > Jenkins we have the notion of organization folder for GitHub which allow > to > > automatically browse an org in GitHub and create/update/delete > > multibranches jobs for each repo. If we can also create shared libraries > in > > Jenkins our JenkinsFile could just be a line: buildPlugin() like we do in > > jenkins project. > > > > Now that I have landed JENKINS-43507 it should be relatively easy for me to > write a SCMNavigator for the ASF hosted repositories. > > That would give us a folder where all jobs for plugins etc would be > auto-created based on the presence of a Jenkinsfile. > > With a shared library we can then give them all a standard build with a > nice simple Jenkinsfile that is just one line. > > If people are interested I can prototype the SCMNavigator > > > > Le mar. 20 juin 2017 à 21:14, Hervé BOUTEMY a > > écrit : > > > > > as explained in the git migration status [1], the biggest issue with > > > plugins 1 > > > svn repo to 41 git repo migration is the maintenance of Jenkins job > > files, > > > with > > > their java + maven version matrix. > > > With Jenkinsfile as worked out in Mavne core, same type of > configuration > > > could > > > help us to change our 10 aggregate Jenkins jobs to 41 individual jobs > > > > > > Would it be possible to create an aggregator Jenkins job that would > > create > > > the > > > 41 plugins jobs? > > > > > > Regards, > > > > > > Hervé > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa > collectionofgitrepos > > > > > > Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit : > > > > I think the plugins are descoped for a while. > > > > > > > > How about https://github.com/apache-maven/ ? > > > > > > > > Luckily GitHub does 302s just find if things get renamed or moved > > between > > > > orgs. > > > > > > > > - Paul > > > > > > > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik < > > bindulbhow...@gmail.com > > > > > > > > > > > > wrote: > > > > > Paul, > > > > > > > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant > > > wrote: > > > > > > Back from Github's suggestions team: "Currently, we don't have > the > > > > > > > > > > ability > > > > > > > > > > > to group repos beyond the organization level, but I'll definitely > > > > > > > > > > consider > > > > > > > > > > > this a feature request." > > > > > > > > > > Until such time, how about grouping the repositories by name, like > > > > > https://github.com/apache/maven-plugin- > > > > > > > > > > A number of other projects in Apache have done this, for example > > > > > https://git-wip-us.apache.org/repos/asf?a=project_list&s= > > > > > incubator-predictionio > > > > > or https://gitbox.apache.org/repos/asf?a=project_list&s= > > > > > incubator-openwhisk > > > > > > > > > > - Bindul > > > > > > > > > > > - Paul > > > > > > > > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant > > > wrote: > > > > > >> I met Chris Wanstrath at a meetup in Cincinatti about four years > > > ago, > > > > > > > > > > and > > > > > > > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll) was > as > > a > > > > > > > > > > CMS. I > > > > > > > > > > >> suggested that if they could add themes for "high school", > > > "community > > > > > >> group", etc they could pull in another category of user of the > > > > > > > > > > platform, and > > > > > > > > > > >> that the themes that are available for gh-pages are not that > > useful > > > as > > > > > > > > > > they > > > > > > > > > > >> are. > > > > > >> > > > > > >> > > > > > >> > > > > > >> ^ screencap from today: unchanged :( > > > > > >> > > > > > >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly > > > > > >> > > > > > >> wrote: > > > > > >>> Polite, yes, just non commital ;-) > > > > > >>> > > > > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant > > > wrote: > > > > > >>> > They're always very polite for things that I ask for, but I > > can't > > > > > > > > > > claim > > > > > > > > > > >>> > to > > > > > >>> > have suggested anything that got implemented. I've a better > > > hit-rate > > > > > >>> > with > > > > > >>> > JetBrains and their IDEs. > > > > > >>> > > > > > > >>> > - Paul > > > > > >>> > > > > > > >>> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < > > > > > >>> > > > > > > >>> > stephen.alan.conno...@gmail.com> wrote: > > > > > >>> > > Liable to get an answer like: > > > > > >>> > > > We don't comment our roadmap publicly I'm afraid > > > > > >>> > > > > > > > >>> > > (I've gotten that a couple of times for different things... > > > you'd > > > > > >>> > > think > > > > > >>> > > given that I'm the maintainer of the GitHub Branch Source > > > plugin > > > > > > > > > > for > > > > > > > > > > >>>
Re: Migration of remaining plugins to Git
On Tue 20 Jun 2017 at 20:29, Arnaud Héritier wrote: > Stephen knows more the ASF infra than me to tell if it is possible but in > Jenkins we have the notion of organization folder for GitHub which allow to > automatically browse an org in GitHub and create/update/delete > multibranches jobs for each repo. If we can also create shared libraries in > Jenkins our JenkinsFile could just be a line: buildPlugin() like we do in > jenkins project. > Now that I have landed JENKINS-43507 it should be relatively easy for me to write a SCMNavigator for the ASF hosted repositories. That would give us a folder where all jobs for plugins etc would be auto-created based on the presence of a Jenkinsfile. With a shared library we can then give them all a standard build with a nice simple Jenkinsfile that is just one line. If people are interested I can prototype the SCMNavigator > Le mar. 20 juin 2017 à 21:14, Hervé BOUTEMY a > écrit : > > > as explained in the git migration status [1], the biggest issue with > > plugins 1 > > svn repo to 41 git repo migration is the maintenance of Jenkins job > files, > > with > > their java + maven version matrix. > > With Jenkinsfile as worked out in Mavne core, same type of configuration > > could > > help us to change our 10 aggregate Jenkins jobs to 41 individual jobs > > > > Would it be possible to create an aggregator Jenkins job that would > create > > the > > 41 plugins jobs? > > > > Regards, > > > > Hervé > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > > > Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit : > > > I think the plugins are descoped for a while. > > > > > > How about https://github.com/apache-maven/ ? > > > > > > Luckily GitHub does 302s just find if things get renamed or moved > between > > > orgs. > > > > > > - Paul > > > > > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik < > bindulbhow...@gmail.com > > > > > > > > > wrote: > > > > Paul, > > > > > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant > > wrote: > > > > > Back from Github's suggestions team: "Currently, we don't have the > > > > > > > > ability > > > > > > > > > to group repos beyond the organization level, but I'll definitely > > > > > > > > consider > > > > > > > > > this a feature request." > > > > > > > > Until such time, how about grouping the repositories by name, like > > > > https://github.com/apache/maven-plugin- > > > > > > > > A number of other projects in Apache have done this, for example > > > > https://git-wip-us.apache.org/repos/asf?a=project_list&s= > > > > incubator-predictionio > > > > or https://gitbox.apache.org/repos/asf?a=project_list&s= > > > > incubator-openwhisk > > > > > > > > - Bindul > > > > > > > > > - Paul > > > > > > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant > > wrote: > > > > >> I met Chris Wanstrath at a meetup in Cincinatti about four years > > ago, > > > > > > > > and > > > > > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll) was as > a > > > > > > > > CMS. I > > > > > > > > >> suggested that if they could add themes for "high school", > > "community > > > > >> group", etc they could pull in another category of user of the > > > > > > > > platform, and > > > > > > > > >> that the themes that are available for gh-pages are not that > useful > > as > > > > > > > > they > > > > > > > > >> are. > > > > >> > > > > >> > > > > >> > > > > >> ^ screencap from today: unchanged :( > > > > >> > > > > >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly > > > > >> > > > > >> wrote: > > > > >>> Polite, yes, just non commital ;-) > > > > >>> > > > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant > > wrote: > > > > >>> > They're always very polite for things that I ask for, but I > can't > > > > > > > > claim > > > > > > > > >>> > to > > > > >>> > have suggested anything that got implemented. I've a better > > hit-rate > > > > >>> > with > > > > >>> > JetBrains and their IDEs. > > > > >>> > > > > > >>> > - Paul > > > > >>> > > > > > >>> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < > > > > >>> > > > > > >>> > stephen.alan.conno...@gmail.com> wrote: > > > > >>> > > Liable to get an answer like: > > > > >>> > > > We don't comment our roadmap publicly I'm afraid > > > > >>> > > > > > > >>> > > (I've gotten that a couple of times for different things... > > you'd > > > > >>> > > think > > > > >>> > > given that I'm the maintainer of the GitHub Branch Source > > plugin > > > > > > > > for > > > > > > > > >>> > > Jenkins they might - you know - want to help... but alas) > > > > >>> > > > > > > >>> > > On 18 June 2017 at 10:12, Paul Hammant > > wrote: > > > > >>> > > > Good thought. We could ask about a timeline. > > > > >>> > > > > > > > >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > > > > >>> > > > > > > > >>> > > > stephen.alan.conno...@gmail.com> wrote: > > > > >>> > > > > They are now adding user group
Re: Migration of remaining plugins to Git
Stephen knows more the ASF infra than me to tell if it is possible but in Jenkins we have the notion of organization folder for GitHub which allow to automatically browse an org in GitHub and create/update/delete multibranches jobs for each repo. If we can also create shared libraries in Jenkins our JenkinsFile could just be a line: buildPlugin() like we do in jenkins project. Le mar. 20 juin 2017 à 21:14, Hervé BOUTEMY a écrit : > as explained in the git migration status [1], the biggest issue with > plugins 1 > svn repo to 41 git repo migration is the maintenance of Jenkins job files, > with > their java + maven version matrix. > With Jenkinsfile as worked out in Mavne core, same type of configuration > could > help us to change our 10 aggregate Jenkins jobs to 41 individual jobs > > Would it be possible to create an aggregator Jenkins job that would create > the > 41 plugins jobs? > > Regards, > > Hervé > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit : > > I think the plugins are descoped for a while. > > > > How about https://github.com/apache-maven/ ? > > > > Luckily GitHub does 302s just find if things get renamed or moved between > > orgs. > > > > - Paul > > > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik > > > > > wrote: > > > Paul, > > > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant > wrote: > > > > Back from Github's suggestions team: "Currently, we don't have the > > > > > > ability > > > > > > > to group repos beyond the organization level, but I'll definitely > > > > > > consider > > > > > > > this a feature request." > > > > > > Until such time, how about grouping the repositories by name, like > > > https://github.com/apache/maven-plugin- > > > > > > A number of other projects in Apache have done this, for example > > > https://git-wip-us.apache.org/repos/asf?a=project_list&s= > > > incubator-predictionio > > > or https://gitbox.apache.org/repos/asf?a=project_list&s= > > > incubator-openwhisk > > > > > > - Bindul > > > > > > > - Paul > > > > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant > wrote: > > > >> I met Chris Wanstrath at a meetup in Cincinatti about four years > ago, > > > > > > and > > > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll) was as a > > > > > > CMS. I > > > > > > >> suggested that if they could add themes for "high school", > "community > > > >> group", etc they could pull in another category of user of the > > > > > > platform, and > > > > > > >> that the themes that are available for gh-pages are not that useful > as > > > > > > they > > > > > > >> are. > > > >> > > > >> > > > >> > > > >> ^ screencap from today: unchanged :( > > > >> > > > >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly > > > >> > > > >> wrote: > > > >>> Polite, yes, just non commital ;-) > > > >>> > > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant > wrote: > > > >>> > They're always very polite for things that I ask for, but I can't > > > > > > claim > > > > > > >>> > to > > > >>> > have suggested anything that got implemented. I've a better > hit-rate > > > >>> > with > > > >>> > JetBrains and their IDEs. > > > >>> > > > > >>> > - Paul > > > >>> > > > > >>> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < > > > >>> > > > > >>> > stephen.alan.conno...@gmail.com> wrote: > > > >>> > > Liable to get an answer like: > > > >>> > > > We don't comment our roadmap publicly I'm afraid > > > >>> > > > > > >>> > > (I've gotten that a couple of times for different things... > you'd > > > >>> > > think > > > >>> > > given that I'm the maintainer of the GitHub Branch Source > plugin > > > > > > for > > > > > > >>> > > Jenkins they might - you know - want to help... but alas) > > > >>> > > > > > >>> > > On 18 June 2017 at 10:12, Paul Hammant > wrote: > > > >>> > > > Good thought. We could ask about a timeline. > > > >>> > > > > > > >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > > > >>> > > > > > > >>> > > > stephen.alan.conno...@gmail.com> wrote: > > > >>> > > > > They are now adding user grouping... I wonder how long > before > > > >>> > > > > repo > > > >>> > > > > > > >>> > > > grouping > > > >>> > > > > > > >>> > > > > too > > > >>> > > > > > > > >>> > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant < > p...@hammant.org> > > > >>> > > > > > > > >>> > > > > wrote: > > > >>> > > > > > Choose one to start with, is what I would do. > > > >>> > > > > > > > > >>> > > > > > git svn clone of a trunk only, then make that master. > > > >>> > > > > > branch/tag > > > >>> > > > > > > >>> > > > history > > > >>> > > > > > > >>> > > > > > can be retained in Subversion but also up on > MavenCentral as > > > >>> > > > > > foo-x.y-sources.jar files. Unless you optimize that > > > >>> > > > > > git-svn-clone > > > >>> > > > > > operation by specifying the first Svn commit for the > module > > > > > > in
Re: Migration of remaining plugins to Git
as explained in the git migration status [1], the biggest issue with plugins 1 svn repo to 41 git repo migration is the maintenance of Jenkins job files, with their java + maven version matrix. With Jenkinsfile as worked out in Mavne core, same type of configuration could help us to change our 10 aggregate Jenkins jobs to 41 individual jobs Would it be possible to create an aggregator Jenkins job that would create the 41 plugins jobs? Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Git +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos Le lundi 19 juin 2017, 16:10:39 CEST Paul Hammant a écrit : > I think the plugins are descoped for a while. > > How about https://github.com/apache-maven/ ? > > Luckily GitHub does 302s just find if things get renamed or moved between > orgs. > > - Paul > > On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik > > wrote: > > Paul, > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant wrote: > > > Back from Github's suggestions team: "Currently, we don't have the > > > > ability > > > > > to group repos beyond the organization level, but I'll definitely > > > > consider > > > > > this a feature request." > > > > Until such time, how about grouping the repositories by name, like > > https://github.com/apache/maven-plugin- > > > > A number of other projects in Apache have done this, for example > > https://git-wip-us.apache.org/repos/asf?a=project_list&s= > > incubator-predictionio > > or https://gitbox.apache.org/repos/asf?a=project_list&s= > > incubator-openwhisk > > > > - Bindul > > > > > - Paul > > > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant wrote: > > >> I met Chris Wanstrath at a meetup in Cincinatti about four years ago, > > > > and > > > > >> bent his ear about how fantastic Github-Pages (and Jekyll) was as a > > > > CMS. I > > > > >> suggested that if they could add themes for "high school", "community > > >> group", etc they could pull in another category of user of the > > > > platform, and > > > > >> that the themes that are available for gh-pages are not that useful as > > > > they > > > > >> are. > > >> > > >> > > >> > > >> ^ screencap from today: unchanged :( > > >> > > >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly > > >> > > >> wrote: > > >>> Polite, yes, just non commital ;-) > > >>> > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant wrote: > > >>> > They're always very polite for things that I ask for, but I can't > > > > claim > > > > >>> > to > > >>> > have suggested anything that got implemented. I've a better hit-rate > > >>> > with > > >>> > JetBrains and their IDEs. > > >>> > > > >>> > - Paul > > >>> > > > >>> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < > > >>> > > > >>> > stephen.alan.conno...@gmail.com> wrote: > > >>> > > Liable to get an answer like: > > >>> > > > We don't comment our roadmap publicly I'm afraid > > >>> > > > > >>> > > (I've gotten that a couple of times for different things... you'd > > >>> > > think > > >>> > > given that I'm the maintainer of the GitHub Branch Source plugin > > > > for > > > > >>> > > Jenkins they might - you know - want to help... but alas) > > >>> > > > > >>> > > On 18 June 2017 at 10:12, Paul Hammant wrote: > > >>> > > > Good thought. We could ask about a timeline. > > >>> > > > > > >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > > >>> > > > > > >>> > > > stephen.alan.conno...@gmail.com> wrote: > > >>> > > > > They are now adding user grouping... I wonder how long before > > >>> > > > > repo > > >>> > > > > > >>> > > > grouping > > >>> > > > > > >>> > > > > too > > >>> > > > > > > >>> > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant > > >>> > > > > > > >>> > > > > wrote: > > >>> > > > > > Choose one to start with, is what I would do. > > >>> > > > > > > > >>> > > > > > git svn clone of a trunk only, then make that master. > > >>> > > > > > branch/tag > > >>> > > > > > >>> > > > history > > >>> > > > > > >>> > > > > > can be retained in Subversion but also up on MavenCentral as > > >>> > > > > > foo-x.y-sources.jar files. Unless you optimize that > > >>> > > > > > git-svn-clone > > >>> > > > > > operation by specifying the first Svn commit for the module > > > > in > > > > >>> > > > question, > > >>> > > > > > >>> > > > > > it'll need many hours to iterate over all commits to pluck > > > > out > > > > >>> > > > > > the > > >>> > > > > >>> > > ones > > >>> > > > > >>> > > > > > pertinent to the trunk of that module. > > >>> > > > > > > > >>> > > > > > GitHub only allows a single effective 'parent directory' for > > >>> > > > > > repos, > > >>> > > > > >>> > > so > > >>> > > > > >>> > > > > > instead of the general github.com/apache org (and in lieu of > > >>> > > > > > github.com/apache/maven/ which is what you'd > > >>> > > > > > actually > > >>> > > > > > >>> > > > want), > > >>> > > > > > >>> > > > > we > > >>> > > > > > > >>> > > > > > could do github.
Re: Migration of remaining plugins to Git
I think the plugins are descoped for a while. How about https://github.com/apache-maven/ ? Luckily GitHub does 302s just find if things get renamed or moved between orgs. - Paul On Mon, Jun 19, 2017 at 3:34 PM, Bindul Bhowmik wrote: > Paul, > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant wrote: > > Back from Github's suggestions team: "Currently, we don't have the > ability > > to group repos beyond the organization level, but I'll definitely > consider > > this a feature request." > > Until such time, how about grouping the repositories by name, like > https://github.com/apache/maven-plugin- > > A number of other projects in Apache have done this, for example > https://git-wip-us.apache.org/repos/asf?a=project_list&s= > incubator-predictionio > or https://gitbox.apache.org/repos/asf?a=project_list&s= > incubator-openwhisk > > - Bindul > > > > > - Paul > > > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant wrote: > >> > >> I met Chris Wanstrath at a meetup in Cincinatti about four years ago, > and > >> bent his ear about how fantastic Github-Pages (and Jekyll) was as a > CMS. I > >> suggested that if they could add themes for "high school", "community > >> group", etc they could pull in another category of user of the > platform, and > >> that the themes that are available for gh-pages are not that useful as > they > >> are. > >> > >> > >> > >> ^ screencap from today: unchanged :( > >> > >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly > >> wrote: > >>> > >>> Polite, yes, just non commital ;-) > >>> > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant wrote: > >>> > >>> > They're always very polite for things that I ask for, but I can't > claim > >>> > to > >>> > have suggested anything that got implemented. I've a better hit-rate > >>> > with > >>> > JetBrains and their IDEs. > >>> > > >>> > - Paul > >>> > > >>> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < > >>> > stephen.alan.conno...@gmail.com> wrote: > >>> > > >>> > > Liable to get an answer like: > >>> > > > >>> > > > We don't comment our roadmap publicly I'm afraid > >>> > > > >>> > > (I've gotten that a couple of times for different things... you'd > >>> > > think > >>> > > given that I'm the maintainer of the GitHub Branch Source plugin > for > >>> > > Jenkins they might - you know - want to help... but alas) > >>> > > > >>> > > On 18 June 2017 at 10:12, Paul Hammant wrote: > >>> > > > >>> > > > Good thought. We could ask about a timeline. > >>> > > > > >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > >>> > > > stephen.alan.conno...@gmail.com> wrote: > >>> > > > > >>> > > > > They are now adding user grouping... I wonder how long before > >>> > > > > repo > >>> > > > grouping > >>> > > > > too > >>> > > > > > >>> > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant > >>> > > > > wrote: > >>> > > > > > >>> > > > > > Choose one to start with, is what I would do. > >>> > > > > > > >>> > > > > > git svn clone of a trunk only, then make that master. > >>> > > > > > branch/tag > >>> > > > history > >>> > > > > > can be retained in Subversion but also up on MavenCentral as > >>> > > > > > foo-x.y-sources.jar files. Unless you optimize that > >>> > > > > > git-svn-clone > >>> > > > > > operation by specifying the first Svn commit for the module > in > >>> > > > question, > >>> > > > > > it'll need many hours to iterate over all commits to pluck > out > >>> > > > > > the > >>> > > ones > >>> > > > > > pertinent to the trunk of that module. > >>> > > > > > > >>> > > > > > GitHub only allows a single effective 'parent directory' for > >>> > > > > > repos, > >>> > > so > >>> > > > > > instead of the general github.com/apache org (and in lieu of > >>> > > > > > github.com/apache/maven/ which is what you'd > >>> > > > > > actually > >>> > > > want), > >>> > > > > we > >>> > > > > > could do github.com/apache-maven/. > >>> > > > > > > >>> > > > > > I volunteer for some of the work. Err, maybe I should read > >>> > > > > > those > >>> > > > > > confluence pages. > >>> > > > > > > >>> > > > > > - Paul > >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY < > >>> > > herve.bout...@free.fr > >>> > > > > > >>> > > > > > wrote: > >>> > > > > > > >>> > > > > > > yes, git is really ubiquitous now and nowadays could > perhaps > >>> > > > > > > help > >>> > > > some > >>> > > > > > > contributions > >>> > > > > > > here is our tracking of git migration [1] > >>> > > > > > > > >>> > > > > > > there are a few entries that we could move if someone takes > >>> > > > > > > the > >>> > > job: > >>> > > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, > >>> > Release > >>> > > > > > > > >>> > > > > > > there are issues to fix when migrating 1 svn repo > >>> > > (trunk/tags/branch) > >>> > > > > to > >>> > > > > > > many > >>> > > > > > > git repos that are documented but not solved yet > >>> > > > > > > Plugins and shared components are the 2 big repos, with > >>> > >
Re: Migration of remaining plugins to Git
Paul, On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant wrote: > Back from Github's suggestions team: "Currently, we don't have the ability > to group repos beyond the organization level, but I'll definitely consider > this a feature request." Until such time, how about grouping the repositories by name, like https://github.com/apache/maven-plugin- A number of other projects in Apache have done this, for example https://git-wip-us.apache.org/repos/asf?a=project_list&s=incubator-predictionio or https://gitbox.apache.org/repos/asf?a=project_list&s=incubator-openwhisk - Bindul > > - Paul > > On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant wrote: >> >> I met Chris Wanstrath at a meetup in Cincinatti about four years ago, and >> bent his ear about how fantastic Github-Pages (and Jekyll) was as a CMS. I >> suggested that if they could add themes for "high school", "community >> group", etc they could pull in another category of user of the platform, and >> that the themes that are available for gh-pages are not that useful as they >> are. >> >> >> >> ^ screencap from today: unchanged :( >> >> On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly >> wrote: >>> >>> Polite, yes, just non commital ;-) >>> >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant wrote: >>> >>> > They're always very polite for things that I ask for, but I can't claim >>> > to >>> > have suggested anything that got implemented. I've a better hit-rate >>> > with >>> > JetBrains and their IDEs. >>> > >>> > - Paul >>> > >>> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < >>> > stephen.alan.conno...@gmail.com> wrote: >>> > >>> > > Liable to get an answer like: >>> > > >>> > > > We don't comment our roadmap publicly I'm afraid >>> > > >>> > > (I've gotten that a couple of times for different things... you'd >>> > > think >>> > > given that I'm the maintainer of the GitHub Branch Source plugin for >>> > > Jenkins they might - you know - want to help... but alas) >>> > > >>> > > On 18 June 2017 at 10:12, Paul Hammant wrote: >>> > > >>> > > > Good thought. We could ask about a timeline. >>> > > > >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < >>> > > > stephen.alan.conno...@gmail.com> wrote: >>> > > > >>> > > > > They are now adding user grouping... I wonder how long before >>> > > > > repo >>> > > > grouping >>> > > > > too >>> > > > > >>> > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant >>> > > > > wrote: >>> > > > > >>> > > > > > Choose one to start with, is what I would do. >>> > > > > > >>> > > > > > git svn clone of a trunk only, then make that master. >>> > > > > > branch/tag >>> > > > history >>> > > > > > can be retained in Subversion but also up on MavenCentral as >>> > > > > > foo-x.y-sources.jar files. Unless you optimize that >>> > > > > > git-svn-clone >>> > > > > > operation by specifying the first Svn commit for the module in >>> > > > question, >>> > > > > > it'll need many hours to iterate over all commits to pluck out >>> > > > > > the >>> > > ones >>> > > > > > pertinent to the trunk of that module. >>> > > > > > >>> > > > > > GitHub only allows a single effective 'parent directory' for >>> > > > > > repos, >>> > > so >>> > > > > > instead of the general github.com/apache org (and in lieu of >>> > > > > > github.com/apache/maven/ which is what you'd >>> > > > > > actually >>> > > > want), >>> > > > > we >>> > > > > > could do github.com/apache-maven/. >>> > > > > > >>> > > > > > I volunteer for some of the work. Err, maybe I should read >>> > > > > > those >>> > > > > > confluence pages. >>> > > > > > >>> > > > > > - Paul >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY < >>> > > herve.bout...@free.fr >>> > > > > >>> > > > > > wrote: >>> > > > > > >>> > > > > > > yes, git is really ubiquitous now and nowadays could perhaps >>> > > > > > > help >>> > > > some >>> > > > > > > contributions >>> > > > > > > here is our tracking of git migration [1] >>> > > > > > > >>> > > > > > > there are a few entries that we could move if someone takes >>> > > > > > > the >>> > > job: >>> > > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, >>> > Release >>> > > > > > > >>> > > > > > > there are issues to fix when migrating 1 svn repo >>> > > (trunk/tags/branch) >>> > > > > to >>> > > > > > > many >>> > > > > > > git repos that are documented but not solved yet >>> > > > > > > Plugins and shared components are the 2 big repos, with >>> > > respectively >>> > > > 41 >>> > > > > > > and 26 >>> > > > > > > parts if we switch to git that look hard to manage if we >>> > > > > > > don't >>> > > have a >>> > > > > > plan. >>> > > > > > > Perphaps Jenkins pipelines could provide some solutions on >>> > > > > > > the >>> > > > Jenkins >>> > > > > > > side. >>> > > > > > > >>> > > > > > > Skins is perhaps not an issue any more now that we deprecated >>> > > > > > > 3 >>> > old >>> > > > > > skins, >>> > > > > > > then only 2 skins remain. Pom would be feasible now
Re: Migration of remaining plugins to Git
Back from Github's suggestions team: "Currently, we don't have the ability to group repos beyond the organization level, but I'll definitely consider this a feature request." - Paul On Sun, Jun 18, 2017 at 7:04 PM, Paul Hammant wrote: > I met Chris Wanstrath at a meetup in Cincinatti about four years ago, and > bent his ear about how fantastic Github-Pages (and Jekyll) was as a CMS. I > suggested that if they could add themes for "high school", "community > group", etc they could pull in another category of user of the platform, > and that the themes that are available for gh-pages are not that useful as > they are. > > [image: Inline image 1] > > ^ screencap from today: unchanged :( > > On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > >> Polite, yes, just non commital ;-) >> >> On Sun 18 Jun 2017 at 23:10, Paul Hammant wrote: >> >> > They're always very polite for things that I ask for, but I can't claim >> to >> > have suggested anything that got implemented. I've a better hit-rate >> with >> > JetBrains and their IDEs. >> > >> > - Paul >> > >> > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < >> > stephen.alan.conno...@gmail.com> wrote: >> > >> > > Liable to get an answer like: >> > > >> > > > We don't comment our roadmap publicly I'm afraid >> > > >> > > (I've gotten that a couple of times for different things... you'd >> think >> > > given that I'm the maintainer of the GitHub Branch Source plugin for >> > > Jenkins they might - you know - want to help... but alas) >> > > >> > > On 18 June 2017 at 10:12, Paul Hammant wrote: >> > > >> > > > Good thought. We could ask about a timeline. >> > > > >> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < >> > > > stephen.alan.conno...@gmail.com> wrote: >> > > > >> > > > > They are now adding user grouping... I wonder how long before repo >> > > > grouping >> > > > > too >> > > > > >> > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant >> wrote: >> > > > > >> > > > > > Choose one to start with, is what I would do. >> > > > > > >> > > > > > git svn clone of a trunk only, then make that master. branch/tag >> > > > history >> > > > > > can be retained in Subversion but also up on MavenCentral as >> > > > > > foo-x.y-sources.jar files. Unless you optimize that >> git-svn-clone >> > > > > > operation by specifying the first Svn commit for the module in >> > > > question, >> > > > > > it'll need many hours to iterate over all commits to pluck out >> the >> > > ones >> > > > > > pertinent to the trunk of that module. >> > > > > > >> > > > > > GitHub only allows a single effective 'parent directory' for >> repos, >> > > so >> > > > > > instead of the general github.com/apache org (and in lieu of >> > > > > > github.com/apache/maven/ which is what you'd >> actually >> > > > want), >> > > > > we >> > > > > > could do github.com/apache-maven/. >> > > > > > >> > > > > > I volunteer for some of the work. Err, maybe I should read >> those >> > > > > > confluence pages. >> > > > > > >> > > > > > - Paul >> > > > > > >> > > > > > >> > > > > > >> > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY < >> > > herve.bout...@free.fr >> > > > > >> > > > > > wrote: >> > > > > > >> > > > > > > yes, git is really ubiquitous now and nowadays could perhaps >> help >> > > > some >> > > > > > > contributions >> > > > > > > here is our tracking of git migration [1] >> > > > > > > >> > > > > > > there are a few entries that we could move if someone takes >> the >> > > job: >> > > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, >> > Release >> > > > > > > >> > > > > > > there are issues to fix when migrating 1 svn repo >> > > (trunk/tags/branch) >> > > > > to >> > > > > > > many >> > > > > > > git repos that are documented but not solved yet >> > > > > > > Plugins and shared components are the 2 big repos, with >> > > respectively >> > > > 41 >> > > > > > > and 26 >> > > > > > > parts if we switch to git that look hard to manage if we don't >> > > have a >> > > > > > plan. >> > > > > > > Perphaps Jenkins pipelines could provide some solutions on the >> > > > Jenkins >> > > > > > > side. >> > > > > > > >> > > > > > > Skins is perhaps not an issue any more now that we deprecated >> 3 >> > old >> > > > > > skins, >> > > > > > > then only 2 skins remain. Pom would be feasible now that I >> > reworked >> > > > > Maven >> > > > > > > parent poms to be only in one global release: just the history >> > > > > migration >> > > > > > > could >> > > > > > > be tricky given this exact rework :) >> > > > > > > >> > > > > > > >> > > > > > > Then we can move forward: >> > > > > > > - just do it for some svn repos >> > > > > > > - a plan, particularly on Jenkins side, has to be found for >> > plugins >> > > > and >> > > > > > > shared >> > > > > > > >> > > > > > > any taker for some of the work? >> > > > > > > >> > > > > > > Regards, >> > > > > > > >> > > > > > > Hervé >> > > > > > > >> > > > > > > >> > > > > > > [1] https
Re: Migration of remaining plugins to Git
I met Chris Wanstrath at a meetup in Cincinatti about four years ago, and bent his ear about how fantastic Github-Pages (and Jekyll) was as a CMS. I suggested that if they could add themes for "high school", "community group", etc they could pull in another category of user of the platform, and that the themes that are available for gh-pages are not that useful as they are. [image: Inline image 1] ^ screencap from today: unchanged :( On Sun, Jun 18, 2017 at 6:46 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Polite, yes, just non commital ;-) > > On Sun 18 Jun 2017 at 23:10, Paul Hammant wrote: > > > They're always very polite for things that I ask for, but I can't claim > to > > have suggested anything that got implemented. I've a better hit-rate with > > JetBrains and their IDEs. > > > > - Paul > > > > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > Liable to get an answer like: > > > > > > > We don't comment our roadmap publicly I'm afraid > > > > > > (I've gotten that a couple of times for different things... you'd think > > > given that I'm the maintainer of the GitHub Branch Source plugin for > > > Jenkins they might - you know - want to help... but alas) > > > > > > On 18 June 2017 at 10:12, Paul Hammant wrote: > > > > > > > Good thought. We could ask about a timeline. > > > > > > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > > > They are now adding user grouping... I wonder how long before repo > > > > grouping > > > > > too > > > > > > > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant > wrote: > > > > > > > > > > > Choose one to start with, is what I would do. > > > > > > > > > > > > git svn clone of a trunk only, then make that master. branch/tag > > > > history > > > > > > can be retained in Subversion but also up on MavenCentral as > > > > > > foo-x.y-sources.jar files. Unless you optimize that > git-svn-clone > > > > > > operation by specifying the first Svn commit for the module in > > > > question, > > > > > > it'll need many hours to iterate over all commits to pluck out > the > > > ones > > > > > > pertinent to the trunk of that module. > > > > > > > > > > > > GitHub only allows a single effective 'parent directory' for > repos, > > > so > > > > > > instead of the general github.com/apache org (and in lieu of > > > > > > github.com/apache/maven/ which is what you'd actually > > > > want), > > > > > we > > > > > > could do github.com/apache-maven/. > > > > > > > > > > > > I volunteer for some of the work. Err, maybe I should read those > > > > > > confluence pages. > > > > > > > > > > > > - Paul > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY < > > > herve.bout...@free.fr > > > > > > > > > > > wrote: > > > > > > > > > > > > > yes, git is really ubiquitous now and nowadays could perhaps > help > > > > some > > > > > > > contributions > > > > > > > here is our tracking of git migration [1] > > > > > > > > > > > > > > there are a few entries that we could move if someone takes the > > > job: > > > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, > > Release > > > > > > > > > > > > > > there are issues to fix when migrating 1 svn repo > > > (trunk/tags/branch) > > > > > to > > > > > > > many > > > > > > > git repos that are documented but not solved yet > > > > > > > Plugins and shared components are the 2 big repos, with > > > respectively > > > > 41 > > > > > > > and 26 > > > > > > > parts if we switch to git that look hard to manage if we don't > > > have a > > > > > > plan. > > > > > > > Perphaps Jenkins pipelines could provide some solutions on the > > > > Jenkins > > > > > > > side. > > > > > > > > > > > > > > Skins is perhaps not an issue any more now that we deprecated 3 > > old > > > > > > skins, > > > > > > > then only 2 skins remain. Pom would be feasible now that I > > reworked > > > > > Maven > > > > > > > parent poms to be only in one global release: just the history > > > > > migration > > > > > > > could > > > > > > > be tricky given this exact rework :) > > > > > > > > > > > > > > > > > > > > > Then we can move forward: > > > > > > > - just do it for some svn repos > > > > > > > - a plan, particularly on Jenkins side, has to be found for > > plugins > > > > and > > > > > > > shared > > > > > > > > > > > > > > any taker for some of the work? > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > > > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+ > > > Migration > > > > > > > > > > > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > > > > > > > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa > > > > > collectionofgitrepos > > > > > > > > > > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit > : > > > > > > > > Am 2017-06-18 um 15:45 schrieb
Re: Migration of remaining plugins to Git
Polite, yes, just non commital ;-) On Sun 18 Jun 2017 at 23:10, Paul Hammant wrote: > They're always very polite for things that I ask for, but I can't claim to > have suggested anything that got implemented. I've a better hit-rate with > JetBrains and their IDEs. > > - Paul > > On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > Liable to get an answer like: > > > > > We don't comment our roadmap publicly I'm afraid > > > > (I've gotten that a couple of times for different things... you'd think > > given that I'm the maintainer of the GitHub Branch Source plugin for > > Jenkins they might - you know - want to help... but alas) > > > > On 18 June 2017 at 10:12, Paul Hammant wrote: > > > > > Good thought. We could ask about a timeline. > > > > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > > > stephen.alan.conno...@gmail.com> wrote: > > > > > > > They are now adding user grouping... I wonder how long before repo > > > grouping > > > > too > > > > > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant wrote: > > > > > > > > > Choose one to start with, is what I would do. > > > > > > > > > > git svn clone of a trunk only, then make that master. branch/tag > > > history > > > > > can be retained in Subversion but also up on MavenCentral as > > > > > foo-x.y-sources.jar files. Unless you optimize that git-svn-clone > > > > > operation by specifying the first Svn commit for the module in > > > question, > > > > > it'll need many hours to iterate over all commits to pluck out the > > ones > > > > > pertinent to the trunk of that module. > > > > > > > > > > GitHub only allows a single effective 'parent directory' for repos, > > so > > > > > instead of the general github.com/apache org (and in lieu of > > > > > github.com/apache/maven/ which is what you'd actually > > > want), > > > > we > > > > > could do github.com/apache-maven/. > > > > > > > > > > I volunteer for some of the work. Err, maybe I should read those > > > > > confluence pages. > > > > > > > > > > - Paul > > > > > > > > > > > > > > > > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY < > > herve.bout...@free.fr > > > > > > > > > wrote: > > > > > > > > > > > yes, git is really ubiquitous now and nowadays could perhaps help > > > some > > > > > > contributions > > > > > > here is our tracking of git migration [1] > > > > > > > > > > > > there are a few entries that we could move if someone takes the > > job: > > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, > Release > > > > > > > > > > > > there are issues to fix when migrating 1 svn repo > > (trunk/tags/branch) > > > > to > > > > > > many > > > > > > git repos that are documented but not solved yet > > > > > > Plugins and shared components are the 2 big repos, with > > respectively > > > 41 > > > > > > and 26 > > > > > > parts if we switch to git that look hard to manage if we don't > > have a > > > > > plan. > > > > > > Perphaps Jenkins pipelines could provide some solutions on the > > > Jenkins > > > > > > side. > > > > > > > > > > > > Skins is perhaps not an issue any more now that we deprecated 3 > old > > > > > skins, > > > > > > then only 2 skins remain. Pom would be feasible now that I > reworked > > > > Maven > > > > > > parent poms to be only in one global release: just the history > > > > migration > > > > > > could > > > > > > be tricky given this exact rework :) > > > > > > > > > > > > > > > > > > Then we can move forward: > > > > > > - just do it for some svn repos > > > > > > - a plan, particularly on Jenkins side, has to be found for > plugins > > > and > > > > > > shared > > > > > > > > > > > > any taker for some of the work? > > > > > > > > > > > > Regards, > > > > > > > > > > > > Hervé > > > > > > > > > > > > > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+ > > Migration > > > > > > > > > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > > > > > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa > > > > collectionofgitrepos > > > > > > > > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > > > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > > > > > > In order to be able to build a composite 'trunk' for all > > > components > > > > > of > > > > > > > > maven (that are org.apache.*) can we move the remaining > things > > > left > > > > > in > > > > > > > > Subversion to Git, and mirror them to Github? > > > > > > > > > > > > > > > > `git submodule` (etc) would be how we'd recreate a developer > > > > > experience > > > > > > > > that felt like a single trunk that would be cloneable in a > > single > > > > > > command. > > > > > > > > > > > > > > This have been discussed, afaik, for the plugins already. That > > > would > > > > > > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > > > > > > > > > > > > > > > > > > > > ---
Re: Migration of remaining plugins to Git
They're always very polite for things that I ask for, but I can't claim to have suggested anything that got implemented. I've a better hit-rate with JetBrains and their IDEs. - Paul On Sun, Jun 18, 2017 at 4:39 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Liable to get an answer like: > > > We don't comment our roadmap publicly I'm afraid > > (I've gotten that a couple of times for different things... you'd think > given that I'm the maintainer of the GitHub Branch Source plugin for > Jenkins they might - you know - want to help... but alas) > > On 18 June 2017 at 10:12, Paul Hammant wrote: > > > Good thought. We could ask about a timeline. > > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > > stephen.alan.conno...@gmail.com> wrote: > > > > > They are now adding user grouping... I wonder how long before repo > > grouping > > > too > > > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant wrote: > > > > > > > Choose one to start with, is what I would do. > > > > > > > > git svn clone of a trunk only, then make that master. branch/tag > > history > > > > can be retained in Subversion but also up on MavenCentral as > > > > foo-x.y-sources.jar files. Unless you optimize that git-svn-clone > > > > operation by specifying the first Svn commit for the module in > > question, > > > > it'll need many hours to iterate over all commits to pluck out the > ones > > > > pertinent to the trunk of that module. > > > > > > > > GitHub only allows a single effective 'parent directory' for repos, > so > > > > instead of the general github.com/apache org (and in lieu of > > > > github.com/apache/maven/ which is what you'd actually > > want), > > > we > > > > could do github.com/apache-maven/. > > > > > > > > I volunteer for some of the work. Err, maybe I should read those > > > > confluence pages. > > > > > > > > - Paul > > > > > > > > > > > > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY < > herve.bout...@free.fr > > > > > > > wrote: > > > > > > > > > yes, git is really ubiquitous now and nowadays could perhaps help > > some > > > > > contributions > > > > > here is our tracking of git migration [1] > > > > > > > > > > there are a few entries that we could move if someone takes the > job: > > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release > > > > > > > > > > there are issues to fix when migrating 1 svn repo > (trunk/tags/branch) > > > to > > > > > many > > > > > git repos that are documented but not solved yet > > > > > Plugins and shared components are the 2 big repos, with > respectively > > 41 > > > > > and 26 > > > > > parts if we switch to git that look hard to manage if we don't > have a > > > > plan. > > > > > Perphaps Jenkins pipelines could provide some solutions on the > > Jenkins > > > > > side. > > > > > > > > > > Skins is perhaps not an issue any more now that we deprecated 3 old > > > > skins, > > > > > then only 2 skins remain. Pom would be feasible now that I reworked > > > Maven > > > > > parent poms to be only in one global release: just the history > > > migration > > > > > could > > > > > be tricky given this exact rework :) > > > > > > > > > > > > > > > Then we can move forward: > > > > > - just do it for some svn repos > > > > > - a plan, particularly on Jenkins side, has to be found for plugins > > and > > > > > shared > > > > > > > > > > any taker for some of the work? > > > > > > > > > > Regards, > > > > > > > > > > Hervé > > > > > > > > > > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+ > Migration > > > > > > > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > > > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa > > > collectionofgitrepos > > > > > > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > > > > > In order to be able to build a composite 'trunk' for all > > components > > > > of > > > > > > > maven (that are org.apache.*) can we move the remaining things > > left > > > > in > > > > > > > Subversion to Git, and mirror them to Github? > > > > > > > > > > > > > > `git submodule` (etc) would be how we'd recreate a developer > > > > experience > > > > > > > that felt like a single trunk that would be cloneable in a > single > > > > > command. > > > > > > > > > > > > This have been discussed, afaik, for the plugins already. That > > would > > > > > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > > > > > > > > > > > > > > > > - > > > > > > 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...
Re: Migration of remaining plugins to Git
Liable to get an answer like: > We don't comment our roadmap publicly I'm afraid (I've gotten that a couple of times for different things... you'd think given that I'm the maintainer of the GitHub Branch Source plugin for Jenkins they might - you know - want to help... but alas) On 18 June 2017 at 10:12, Paul Hammant wrote: > Good thought. We could ask about a timeline. > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > They are now adding user grouping... I wonder how long before repo > grouping > > too > > > > On Sun 18 Jun 2017 at 17:12, Paul Hammant wrote: > > > > > Choose one to start with, is what I would do. > > > > > > git svn clone of a trunk only, then make that master. branch/tag > history > > > can be retained in Subversion but also up on MavenCentral as > > > foo-x.y-sources.jar files. Unless you optimize that git-svn-clone > > > operation by specifying the first Svn commit for the module in > question, > > > it'll need many hours to iterate over all commits to pluck out the ones > > > pertinent to the trunk of that module. > > > > > > GitHub only allows a single effective 'parent directory' for repos, so > > > instead of the general github.com/apache org (and in lieu of > > > github.com/apache/maven/ which is what you'd actually > want), > > we > > > could do github.com/apache-maven/. > > > > > > I volunteer for some of the work. Err, maybe I should read those > > > confluence pages. > > > > > > - Paul > > > > > > > > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY > > > > wrote: > > > > > > > yes, git is really ubiquitous now and nowadays could perhaps help > some > > > > contributions > > > > here is our tracking of git migration [1] > > > > > > > > there are a few entries that we could move if someone takes the job: > > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release > > > > > > > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) > > to > > > > many > > > > git repos that are documented but not solved yet > > > > Plugins and shared components are the 2 big repos, with respectively > 41 > > > > and 26 > > > > parts if we switch to git that look hard to manage if we don't have a > > > plan. > > > > Perphaps Jenkins pipelines could provide some solutions on the > Jenkins > > > > side. > > > > > > > > Skins is perhaps not an issue any more now that we deprecated 3 old > > > skins, > > > > then only 2 skins remain. Pom would be feasible now that I reworked > > Maven > > > > parent poms to be only in one global release: just the history > > migration > > > > could > > > > be tricky given this exact rework :) > > > > > > > > > > > > Then we can move forward: > > > > - just do it for some svn repos > > > > - a plan, particularly on Jenkins side, has to be found for plugins > and > > > > shared > > > > > > > > any taker for some of the work? > > > > > > > > Regards, > > > > > > > > Hervé > > > > > > > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration > > > > > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa > > collectionofgitrepos > > > > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > > > > In order to be able to build a composite 'trunk' for all > components > > > of > > > > > > maven (that are org.apache.*) can we move the remaining things > left > > > in > > > > > > Subversion to Git, and mirror them to Github? > > > > > > > > > > > > `git submodule` (etc) would be how we'd recreate a developer > > > experience > > > > > > that felt like a single trunk that would be cloneable in a single > > > > command. > > > > > > > > > > This have been discussed, afaik, for the plugins already. That > would > > > > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > > > > > > > > > > > > - > > > > > 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 > > > > > > > > > > > > > -- > > Sent from my phone > > >
Re: Migration of remaining plugins to Git
Good thought. We could ask about a timeline. On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > They are now adding user grouping... I wonder how long before repo grouping > too > > On Sun 18 Jun 2017 at 17:12, Paul Hammant wrote: > > > Choose one to start with, is what I would do. > > > > git svn clone of a trunk only, then make that master. branch/tag history > > can be retained in Subversion but also up on MavenCentral as > > foo-x.y-sources.jar files. Unless you optimize that git-svn-clone > > operation by specifying the first Svn commit for the module in question, > > it'll need many hours to iterate over all commits to pluck out the ones > > pertinent to the trunk of that module. > > > > GitHub only allows a single effective 'parent directory' for repos, so > > instead of the general github.com/apache org (and in lieu of > > github.com/apache/maven/ which is what you'd actually want), > we > > could do github.com/apache-maven/. > > > > I volunteer for some of the work. Err, maybe I should read those > > confluence pages. > > > > - Paul > > > > > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY > > wrote: > > > > > yes, git is really ubiquitous now and nowadays could perhaps help some > > > contributions > > > here is our tracking of git migration [1] > > > > > > there are a few entries that we could move if someone takes the job: > > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release > > > > > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) > to > > > many > > > git repos that are documented but not solved yet > > > Plugins and shared components are the 2 big repos, with respectively 41 > > > and 26 > > > parts if we switch to git that look hard to manage if we don't have a > > plan. > > > Perphaps Jenkins pipelines could provide some solutions on the Jenkins > > > side. > > > > > > Skins is perhaps not an issue any more now that we deprecated 3 old > > skins, > > > then only 2 skins remain. Pom would be feasible now that I reworked > Maven > > > parent poms to be only in one global release: just the history > migration > > > could > > > be tricky given this exact rework :) > > > > > > > > > Then we can move forward: > > > - just do it for some svn repos > > > - a plan, particularly on Jenkins side, has to be found for plugins and > > > shared > > > > > > any taker for some of the work? > > > > > > Regards, > > > > > > Hervé > > > > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration > > > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > > > +Migration#GitMigration-Migratinganaggregatortreeintoa > collectionofgitrepos > > > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > > > In order to be able to build a composite 'trunk' for all components > > of > > > > > maven (that are org.apache.*) can we move the remaining things left > > in > > > > > Subversion to Git, and mirror them to Github? > > > > > > > > > > `git submodule` (etc) would be how we'd recreate a developer > > experience > > > > > that felt like a single trunk that would be cloneable in a single > > > command. > > > > > > > > This have been discussed, afaik, for the plugins already. That would > > > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > > > > > > > > - > > > > 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 > > > > > > > > > -- > Sent from my phone >
Re: Migration of remaining plugins to Git
They are now adding user grouping... I wonder how long before repo grouping too On Sun 18 Jun 2017 at 17:12, Paul Hammant wrote: > Choose one to start with, is what I would do. > > git svn clone of a trunk only, then make that master. branch/tag history > can be retained in Subversion but also up on MavenCentral as > foo-x.y-sources.jar files. Unless you optimize that git-svn-clone > operation by specifying the first Svn commit for the module in question, > it'll need many hours to iterate over all commits to pluck out the ones > pertinent to the trunk of that module. > > GitHub only allows a single effective 'parent directory' for repos, so > instead of the general github.com/apache org (and in lieu of > github.com/apache/maven/ which is what you'd actually want), we > could do github.com/apache-maven/. > > I volunteer for some of the work. Err, maybe I should read those > confluence pages. > > - Paul > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY > wrote: > > > yes, git is really ubiquitous now and nowadays could perhaps help some > > contributions > > here is our tracking of git migration [1] > > > > there are a few entries that we could move if someone takes the job: > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release > > > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to > > many > > git repos that are documented but not solved yet > > Plugins and shared components are the 2 big repos, with respectively 41 > > and 26 > > parts if we switch to git that look hard to manage if we don't have a > plan. > > Perphaps Jenkins pipelines could provide some solutions on the Jenkins > > side. > > > > Skins is perhaps not an issue any more now that we deprecated 3 old > skins, > > then only 2 skins remain. Pom would be feasible now that I reworked Maven > > parent poms to be only in one global release: just the history migration > > could > > be tricky given this exact rework :) > > > > > > Then we can move forward: > > - just do it for some svn repos > > - a plan, particularly on Jenkins side, has to be found for plugins and > > shared > > > > any taker for some of the work? > > > > Regards, > > > > Hervé > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > > In order to be able to build a composite 'trunk' for all components > of > > > > maven (that are org.apache.*) can we move the remaining things left > in > > > > Subversion to Git, and mirror them to Github? > > > > > > > > `git submodule` (etc) would be how we'd recreate a developer > experience > > > > that felt like a single trunk that would be cloneable in a single > > command. > > > > > > This have been discussed, afaik, for the plugins already. That would > > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > > > > - > > > 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 > > > > > -- Sent from my phone
Re: Migration of remaining plugins to Git
Hi, I am currently migrating many projects from sv to git, all of them are on the same svn repo. I am using tools like svn2git https://github.com/nirvdrum/svn2git These tools retain the full history, authors, branches and tags. I can give more info if needed Hope that helps Enrico Il dom 18 giu 2017, 18:12 Paul Hammant ha scritto: > Choose one to start with, is what I would do. > > git svn clone of a trunk only, then make that master. branch/tag history > can be retained in Subversion but also up on MavenCentral as > foo-x.y-sources.jar files. Unless you optimize that git-svn-clone > operation by specifying the first Svn commit for the module in question, > it'll need many hours to iterate over all commits to pluck out the ones > pertinent to the trunk of that module. > > GitHub only allows a single effective 'parent directory' for repos, so > instead of the general github.com/apache org (and in lieu of > github.com/apache/maven/ which is what you'd actually want), we > could do github.com/apache-maven/. > > I volunteer for some of the work. Err, maybe I should read those > confluence pages. > > - Paul > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY > wrote: > > > yes, git is really ubiquitous now and nowadays could perhaps help some > > contributions > > here is our tracking of git migration [1] > > > > there are a few entries that we could move if someone takes the job: > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release > > > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to > > many > > git repos that are documented but not solved yet > > Plugins and shared components are the 2 big repos, with respectively 41 > > and 26 > > parts if we switch to git that look hard to manage if we don't have a > plan. > > Perphaps Jenkins pipelines could provide some solutions on the Jenkins > > side. > > > > Skins is perhaps not an issue any more now that we deprecated 3 old > skins, > > then only 2 skins remain. Pom would be feasible now that I reworked Maven > > parent poms to be only in one global release: just the history migration > > could > > be tricky given this exact rework :) > > > > > > Then we can move forward: > > - just do it for some svn repos > > - a plan, particularly on Jenkins side, has to be found for plugins and > > shared > > > > any taker for some of the work? > > > > Regards, > > > > Hervé > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > > In order to be able to build a composite 'trunk' for all components > of > > > > maven (that are org.apache.*) can we move the remaining things left > in > > > > Subversion to Git, and mirror them to Github? > > > > > > > > `git submodule` (etc) would be how we'd recreate a developer > experience > > > > that felt like a single trunk that would be cloneable in a single > > command. > > > > > > This have been discussed, afaik, for the plugins already. That would > > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > > > > - > > > 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 > > > > > -- -- Enrico Olivelli
Re: Migration of remaining plugins to Git
I updated the page to mark in green the repos that are ready to migrate: just need the job to be done (with the help of infra, I suppose) with immediate one to one migration We can in parallel work on organizing more complex 1 to many migration plan Thank you for your help on this tedious work that exhausted previous volunteers... Regards, Hervé Le dimanche 18 juin 2017, 12:12:54 CEST Paul Hammant a écrit : > Choose one to start with, is what I would do. > > git svn clone of a trunk only, then make that master. branch/tag history > can be retained in Subversion but also up on MavenCentral as > foo-x.y-sources.jar files. Unless you optimize that git-svn-clone > operation by specifying the first Svn commit for the module in question, > it'll need many hours to iterate over all commits to pluck out the ones > pertinent to the trunk of that module. > > GitHub only allows a single effective 'parent directory' for repos, so > instead of the general github.com/apache org (and in lieu of > github.com/apache/maven/ which is what you'd actually want), we > could do github.com/apache-maven/. > > I volunteer for some of the work. Err, maybe I should read those > confluence pages. > > - Paul > > > > On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY > > wrote: > > yes, git is really ubiquitous now and nowadays could perhaps help some > > contributions > > here is our tracking of git migration [1] > > > > there are a few entries that we could move if someone takes the job: > > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release > > > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to > > many > > git repos that are documented but not solved yet > > Plugins and shared components are the 2 big repos, with respectively 41 > > and 26 > > parts if we switch to git that look hard to manage if we don't have a > > plan. > > Perphaps Jenkins pipelines could provide some solutions on the Jenkins > > side. > > > > Skins is perhaps not an issue any more now that we deprecated 3 old skins, > > then only 2 skins remain. Pom would be feasible now that I reworked Maven > > parent poms to be only in one global release: just the history migration > > could > > be tricky given this exact rework :) > > > > > > Then we can move forward: > > - just do it for some svn repos > > - a plan, particularly on Jenkins side, has to be found for plugins and > > shared > > > > any taker for some of the work? > > > > Regards, > > > > Hervé > > > > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration > > > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > > In order to be able to build a composite 'trunk' for all components of > > > > maven (that are org.apache.*) can we move the remaining things left in > > > > Subversion to Git, and mirror them to Github? > > > > > > > > `git submodule` (etc) would be how we'd recreate a developer > > > > experience > > > > that felt like a single trunk that would be cloneable in a single > > > > command. > > > > > This have been discussed, afaik, for the plugins already. That would > > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > > > > - > > > 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
Re: Migration of remaining plugins to Git
Choose one to start with, is what I would do. git svn clone of a trunk only, then make that master. branch/tag history can be retained in Subversion but also up on MavenCentral as foo-x.y-sources.jar files. Unless you optimize that git-svn-clone operation by specifying the first Svn commit for the module in question, it'll need many hours to iterate over all commits to pluck out the ones pertinent to the trunk of that module. GitHub only allows a single effective 'parent directory' for repos, so instead of the general github.com/apache org (and in lieu of github.com/apache/maven/ which is what you'd actually want), we could do github.com/apache-maven/. I volunteer for some of the work. Err, maybe I should read those confluence pages. - Paul On Sun, Jun 18, 2017 at 11:51 AM, Hervé BOUTEMY wrote: > yes, git is really ubiquitous now and nowadays could perhaps help some > contributions > here is our tracking of git migration [1] > > there are a few entries that we could move if someone takes the job: > Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release > > there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to > many > git repos that are documented but not solved yet > Plugins and shared components are the 2 big repos, with respectively 41 > and 26 > parts if we switch to git that look hard to manage if we don't have a plan. > Perphaps Jenkins pipelines could provide some solutions on the Jenkins > side. > > Skins is perhaps not an issue any more now that we deprecated 3 old skins, > then only 2 skins remain. Pom would be feasible now that I reworked Maven > parent poms to be only in one global release: just the history migration > could > be tricky given this exact rework :) > > > Then we can move forward: > - just do it for some svn repos > - a plan, particularly on Jenkins side, has to be found for plugins and > shared > > any taker for some of the work? > > Regards, > > Hervé > > > [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration > > [2] https://cwiki.apache.org/confluence/display/MAVEN/Git > +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos > > Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > > In order to be able to build a composite 'trunk' for all components of > > > maven (that are org.apache.*) can we move the remaining things left in > > > Subversion to Git, and mirror them to Github? > > > > > > `git submodule` (etc) would be how we'd recreate a developer experience > > > that felt like a single trunk that would be cloneable in a single > command. > > > > This have been discussed, afaik, for the plugins already. That would > > result in an explosion of repositories. It wasn't worthwhile. > > > > > > - > > 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 > >
Re: Migration of remaining plugins to Git
yes, git is really ubiquitous now and nowadays could perhaps help some contributions here is our tracking of git migration [1] there are a few entries that we could move if someone takes the job: Doxia core, Doxia Site Tools, Enforcer, Jxr, Plugin Tools, Release there are issues to fix when migrating 1 svn repo (trunk/tags/branch) to many git repos that are documented but not solved yet Plugins and shared components are the 2 big repos, with respectively 41 and 26 parts if we switch to git that look hard to manage if we don't have a plan. Perphaps Jenkins pipelines could provide some solutions on the Jenkins side. Skins is perhaps not an issue any more now that we deprecated 3 old skins, then only 2 skins remain. Pom would be feasible now that I reworked Maven parent poms to be only in one global release: just the history migration could be tricky given this exact rework :) Then we can move forward: - just do it for some svn repos - a plan, particularly on Jenkins side, has to be found for plugins and shared any taker for some of the work? Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Git+Migration [2] https://cwiki.apache.org/confluence/display/MAVEN/Git +Migration#GitMigration-Migratinganaggregatortreeintoacollectionofgitrepos Le dimanche 18 juin 2017, 15:54:16 CEST Michael Osipov a écrit : > Am 2017-06-18 um 15:45 schrieb Paul Hammant: > > In order to be able to build a composite 'trunk' for all components of > > maven (that are org.apache.*) can we move the remaining things left in > > Subversion to Git, and mirror them to Github? > > > > `git submodule` (etc) would be how we'd recreate a developer experience > > that felt like a single trunk that would be cloneable in a single command. > > This have been discussed, afaik, for the plugins already. That would > result in an explosion of repositories. It wasn't worthwhile. > > > - > 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
Re: Migration of remaining plugins to Git
Am 2017-06-18 um 15:45 schrieb Paul Hammant: In order to be able to build a composite 'trunk' for all components of maven (that are org.apache.*) can we move the remaining things left in Subversion to Git, and mirror them to Github? `git submodule` (etc) would be how we'd recreate a developer experience that felt like a single trunk that would be cloneable in a single command. This have been discussed, afaik, for the plugins already. That would result in an explosion of repositories. It wasn't worthwhile. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Migration of remaining plugins to Git
In order to be able to build a composite 'trunk' for all components of maven (that are org.apache.*) can we move the remaining things left in Subversion to Git, and mirror them to Github? `git submodule` (etc) would be how we'd recreate a developer experience that felt like a single trunk that would be cloneable in a single command. Thoughts?