subject:"Migration of remaining plugins to Git"

Re: Migration of remaining plugins to Git

2017-06-28 Thread Paul Hammant

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

2017-06-27 Thread Paul Hammant

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

2017-06-24 Thread Arnaud Héritier

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=
> > > > > > incubator-predictionio
> > > > > > or https://gitbox.apache.org/repos/asf?a=project_list=
> > > > > > 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.
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> ^

Re: Migration of remaining plugins to Git

2017-06-24 Thread Hervé BOUTEMY

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=
> > > > > incubator-predictionio
> > > > > or https://gitbox.apache.org/repos/asf?a=project_list=
> > > > > 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.

Re: Migration of remaining plugins to Git

2017-06-20 Thread Arnaud Héritier

+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=
> > > > > incubator-predictionio
> > > > > or https://gitbox.apache.org/repos/asf?a=project_list=
> > > > > 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
> > > >

Re: Migration of remaining plugins to Git

2017-06-20 Thread Stephen Connolly

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=
> > > > incubator-predictionio
> > > > or https://gitbox.apache.org/repos/asf?a=project_list=
> > > > 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,

Re: Migration of remaining plugins to Git

2017-06-20 Thread Arnaud Héritier

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=
> > > incubator-predictionio
> > > or https://gitbox.apache.org/repos/asf?a=project_list=
> > > 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.

Re: Migration of remaining plugins to Git

2017-06-20 Thread Hervé BOUTEMY

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=
> > incubator-predictionio
> > or https://gitbox.apache.org/repos/asf?a=project_list=
> > 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
> >

Re: Migration of remaining plugins to Git

2017-06-19 Thread Paul Hammant

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=
> incubator-predictionio
> or https://gitbox.apache.org/repos/asf?a=project_list=
> 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
> >>>

Re: Migration of remaining plugins to Git

2017-06-19 Thread Bindul Bhowmik

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=incubator-predictionio
or https://gitbox.apache.org/repos/asf?a=project_list=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

Re: Migration of remaining plugins to Git

2017-06-19 Thread Paul Hammant

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,
>> > > > > > >
>>

Re: Migration of remaining plugins to Git

2017-06-18 Thread Paul Hammant

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

Re: Migration of remaining plugins to Git

2017-06-18 Thread Stephen Connolly

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

2017-06-18 Thread Paul Hammant

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

Re: Migration of remaining plugins to Git

2017-06-18 Thread Stephen Connolly

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

2017-06-18 Thread Paul Hammant

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

2017-06-18 Thread Stephen Connolly

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

2017-06-18 Thread Enrico Olivelli

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

2017-06-18 Thread Hervé BOUTEMY

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

2017-06-18 Thread Paul Hammant

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

2017-06-18 Thread Hervé BOUTEMY

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

2017-06-18 Thread Michael Osipov


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

2017-06-18 Thread 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.

Thoughts?

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Re: Migration of remaining plugins to Git

Migration of remaining plugins to Git

23 matches

Site Navigation

Mail list logo

Footer information