Migration of remaining plugins to Git

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Migration of remaining plugins to Git

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?
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

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 <[hidden email]> 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/<repo-name> which is what you'd actually want), we
> could do github.com/apache-maven/<repo-name>.
>
> 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 <[hidden email]>
> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
--


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

stephenconnolly
In reply to this post by Paul Hammant
They are now adding user grouping... I wonder how long before repo grouping
too

On Sun 18 Jun 2017 at 17:12, Paul Hammant <[hidden email]> 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/<repo-name> which is what you'd actually want), we
> could do github.com/apache-maven/<repo-name>.
>
> 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 <[hidden email]>
> 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: [hidden email]
> > > For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

stephenconnolly
Polite, yes, just non commital ;-)

On Sun 18 Jun 2017 at 23:10, Paul Hammant <[hidden email]> 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 <
> [hidden email]> 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 <[hidden email]> wrote:
> >
> > > Good thought. We could ask about a timeline.
> > >
> > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > > [hidden email]> 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 <[hidden email]> 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/<repo-name> which is what you'd actually
> > > want),
> > > > we
> > > > > could do github.com/apache-maven/<repo-name>.
> > > > >
> > > > > 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 <
> > [hidden email]
> > > >
> > > > > 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: [hidden email]
> > > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > > > > >
> > > > > > ------------------------------------------------------------
> > > ---------
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > > > >
> > > > > >
> > > > >
> > > > --
> > > > Sent from my phone
> > > >
> > >
> >
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

stephenconnolly
In reply to this post by Paul Hammant
On Tue 20 Jun 2017 at 20:29, Arnaud Héritier <[hidden email]> 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 <[hidden email]> 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/<module-name> ?
> > >
> > > 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 <
> [hidden email]
> > >
> > >
> > > wrote:
> > > > Paul,
> > > >
> > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant <[hidden email]>
> > 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-<plugin_name>
> > > >
> > > > 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 <[hidden email]>
> > 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
> > > > >>
> > > > >> <[hidden email]> wrote:
> > > > >>> Polite, yes, just non commital ;-)
> > > > >>>
> > > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant <[hidden email]>
> > 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 <
> > > > >>> >
> > > > >>> > [hidden email]> 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 <[hidden email]>
> > wrote:
> > > > >>> > > > Good thought. We could ask about a timeline.
> > > > >>> > > >
> > > > >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > > > >>> > > >
> > > > >>> > > > [hidden email]> 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 <
> > [hidden email]>
> > > > >>> > > > >
> > > > >>> > > > > 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/<repo-name> which is what
> you'd
> > > > >>> > > > > > actually
> > > > >>> > > >
> > > > >>> > > > want),
> > > > >>> > > >
> > > > >>> > > > > we
> > > > >>> > > > >
> > > > >>> > > > > > could do github.com/apache-maven/<repo-name>.
> > > > >>> > > > > >
> > > > >>> > > > > > 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 <
> > > > >>> > >
> > > > >>> > > [hidden email]
> > > > >>> > >
> > > > >>> > > > > > 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:
> > [hidden email]
> > > >
> > > > >>> > > > > > > > For additional commands, e-mail:
> > > > [hidden email]
> > > >
> > > > >>> > > > > > > ------------------------------
> > > >
> > > > ------------------------------
> > > >
> > > > >>> > > > ---------
> > > > >>> > > >
> > > > >>> > > > > > > To unsubscribe, e-mail:
> > [hidden email]
> > > > >>> > > > > > > For additional commands, e-mail:
> > [hidden email]
> > > > >>> > > > >
> > > > >>> > > > > --
> > > > >>> > > > > Sent from my phone
> > > > >>>
> > > > >>> --
> > > > >>> Sent from my phone
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > --
> -----
> Arnaud Héritier
> http://aheritier.net
> Mail/GTalk: aheritier AT gmail DOT com
> Twitter/Skype : aheritier
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]> 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/<module-name> ?
> > > > >
> > > > > 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 <
> > >
> > > [hidden email]
> > >
> > > > > wrote:
> > > > > > Paul,
> > > > > >
> > > > > > On Mon, Jun 19, 2017 at 12:42 PM, Paul Hammant <[hidden email]
> >
> > > >
> > > > 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-<plugin_name>
> > > > > >
> > > > > > 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 <
> [hidden email]>
> > > >
> > > > 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
> > > > > > >>
> > > > > > >> <[hidden email]> wrote:
> > > > > > >>> Polite, yes, just non commital ;-)
> > > > > > >>>
> > > > > > >>> On Sun 18 Jun 2017 at 23:10, Paul Hammant <[hidden email]>
> > > >
> > > > 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 <
> > > > > > >>> >
> > > > > > >>> > [hidden email]> 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 <[hidden email]
> >
> > > >
> > > > wrote:
> > > > > > >>> > > > Good thought. We could ask about a timeline.
> > > > > > >>> > > >
> > > > > > >>> > > > On Sun, Jun 18, 2017 at 1:00 PM, Stephen Connolly <
> > > > > > >>> > > >
> > > > > > >>> > > > [hidden email]> 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 <
> > > >
> > > > [hidden email]>
> > > >
> > > > > > >>> > > > > 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/<repo-name> which is what
> > >
> > > you'd
> > >
> > > > > > >>> > > > > > actually
> > > > > > >>> > > >
> > > > > > >>> > > > want),
> > > > > > >>> > > >
> > > > > > >>> > > > > we
> > > > > > >>> > > > >
> > > > > > >>> > > > > > could do github.com/apache-maven/<repo-name>.
> > > > > > >>> > > > > >
> > > > > > >>> > > > > > 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 <
> > > > > > >>> > >
> > > > > > >>> > > [hidden email]
> > > > > > >>> > >
> > > > > > >>> > > > > > 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:
> > > > [hidden email]
> > > >
> > > > > > >>> > > > > > > > For additional commands, e-mail:
> > > > > > [hidden email]
> > > > > >
> > > > > > >>> > > > > > > ------------------------------
> > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > > >>> > > > ---------
> > > > > > >>> > > >
> > > > > > >>> > > > > > > To unsubscribe, e-mail:
> > > > [hidden email]
> > > >
> > > > > > >>> > > > > > > For additional commands, e-mail:
> > > > [hidden email]
> > > >
> > > > > > >>> > > > > --
> > > > > > >>> > > > > Sent from my phone
> > > > > > >>>
> > > > > > >>> --
> > > > > > >>> Sent from my phone
> > > > > >
> > > > > > ------------------------------------------------------------
> --------
> > > > > > -
> > > > > > To unsubscribe, e-mail: [hidden email]
> > > > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > ------------------------------------------------------------
> ---------
> > > > To unsubscribe, e-mail: [hidden email]
> > > > For additional commands, e-mail: [hidden email]
> > > >
> > > > --
> > >
> > > -----
> > > Arnaud Héritier
> > > http://aheritier.net
> > > Mail/GTalk: aheritier AT gmail DOT com
> > > Twitter/Skype : aheritier
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
-----
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Migration of remaining plugins to Git

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 <root of plugins multi-module checkout/clone>
   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 <[hidden email]> 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 <scm> 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
>
>
>
>
>
Loading...