Sources Git migration ETA
This page will contains various Apache Maven svn and their ETA of Git Scm migration: Waiting for volunteer, Work in progress, done, to be discussed, do NOT do aggregator strategy to define
Project | ETA | Details/comment | Volunteer for migration | Infra Jira | ||
---|---|---|---|---|---|---|
/ant-tasks |
| deprecated |
|
| ||
app-engine | /app-engine |
| never released... |
|
| |
/archetype |
| |||||
/archetypes | Hervé Boutemy historically, all archetypes were released in 1 release, but since a few years, every archetype is released independantly require a svn2git mirror first: | |||||
components | /components |
|
|
|
| |
/core-integration-testing |
| |||||
/doxia/doxia | ||||||
/doxia/doxia-ide |
| really alive? let's start with a svn2git mirror: INFRA-15739 |
|
| ||
/doxia/doxia-sitetools | ||||||
/doxia/doxia-tools | Hervé Boutemy remains 2 modules for Doxia Book |
|
| |||
/doxia/site |
| same as Maven site: Hervé Boutemy AFAIK, infra only supports svn for CMS require a svn2git mirror first: and Jenkins credentials to publish to svnpubsub: | ||||
/enforcer | ||||||
/indexer |
| |||||
/jxr | ||||||
Maven 1 | /maven-1 |
|
|
|
| |
Maven 2 | /maven-2 |
| Olivier Lamy migrate this really ? |
|
| |
Maven 3 | /maven-3 |
| ||||
/plugin-testing | current git@asf repo is ok | |||||
/plugin-tools | ||||||
/plugins |
| |||||
/pom | see migrate-pom.sh |
| ||||
Project | /project |
| Olivier Lamy no migration |
|
| |
/release | ||||||
repository-tools | /repository-tools |
|
|
|
| |
/resources |
| Olivier Lamy: need to be discussed more |
|
| ||
retired | /retired |
| Olivier Lamy: no migration |
|
| |
Sandbox | /sandbox |
| Olivier Lamy: migrate this really ? Hervé Boutemy created maven-studies.git to have an equivalent on Git |
|
| |
scm | /scm |
| ||||
/shared |
| Kristian Rosenvold: thinks this repo should be split into separate projects |
| |||
/site |
| Hervé Boutemy AFAIK, infra only supports svn for CMS => will disable CMS require Jenkins credentials to publish to svnpubsub: | ||||
/skins | see migrate-skins.sh |
| ||||
/surefire |
| |||||
/wagon |
|
Migrating an aggregator tree into a collection of git repos
We have a few agregator trees that have to be split in a collection of git repos.
For each aggregator, there are currently a few Jenkins jobs (corresponding to misc Maven or JDK versions) that will require to be split too. Sonar configuration will require rework too.
And general question: how to clone/update such a collection of git repos (to avoid working on each repo individually)?
No strategy currently found on these 3 topics. Apache Sling seems to have the same work in progress (10/2017): see SLING-3987 and corresponding Wiki page for planning (equivalent to this one for Maven).
Update 11/2017: strategies found for every issue (ignoring Sonar for now):
- git repos split scripts created (inspired from Sling),
- Google repo manifest created in https://github.com/hboutemy/maven-aggregator (inspired from Sling),
- Jenkins "ASF Organization" plugin WIP: see sconnolly videos that lead to maven-box and maven-wip Jenkins jobs
aggregator | content | Jenkins | Sonar |
---|---|---|---|
plugins | 41 plugins | 10 aggregator jobs: maven-plugin maven-plugins-ITs-m2 maven-plugins-ITs-m2-with-maven-plugin maven-plugins-ITs-m3 maven-plugins-ITs-m3-windows maven-plugins-ITs-m3.0.4 maven-plugins-ITs-m3.0.5-with-maven-plugin maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8 maven-plugins-ITs-m3.1.x-with-maven-plugin-jdk-1.8_windows maven-plugins-windows | Apache Maven Plugins Aggregator |
pom | 2 parent poms: ASF and maven | 2 jobs: maven-parent ASF Parent Pom | N/A |
resources | 6 resources | 1 aggregator job: maven-project-resources | N/A |
shared | 26 shared components | 2 aggregator jobs: maven-shared maven-shared-windows | Maven Shared Components Aggregator |
skins | 2 skins (3 obsolete) | 1 aggregator job: maven-skins | N/A |
doxia-tools | 2 modules (2 tools migrated) | 1 aggregator job: doxia-tools | Doxia Aggregator |
archetypes |
TODO: delete svn2git mirrors once split: maven-pom.git, maven-skins.git
Keeping track of authoritative SCM for each plugin
As a project is migrated, the last commit in svn for that project should typically change the scm url (or invalidate it).
Update the Source Repository page (see also Doxia Source Repository).
For projects providing a plugin, we also keep track of which SCM by modifying the Available Plugins overview page, much like we do for the release process (the pages where we update the version numbers of the latest release also contain SCM url, update this and republish site when a project is migrated)
Things to discuss with INFRA
Could we have some kind of top-level git url for Maven alone ? (At least at the logical level; git://git.maven.apache.org or similar ?)
Who coordinates updates of the github mirrors ?
How do we migrate an individual project.
Migration process description
If there is an existing read-only git mirror (see http://git.apache.org/), and it is appropriate quality (check especially behaviour on checking out tag)
1. Have infra make the existing read-only mirror the official master (see INFRA-5266 for example).
2. Change scm url in pom
3. Add .gitattributes to configure line endings
4. Update github mirroring url (file issue with github) (Hervé Boutemy probably now done by infra on step 1)
5. Celebrate
Else:
Decide on scope of repository. Make git repository. Infra might help; they're a PITA to run from git-svn remote.
Have community review of repository.
Then as above
Could we have some kind of top-level git url for maven alone ? (At least at the logical level; git://git.maven.apache.org or similar ?)
Who coordinates updates of the github mirrors ?
How do we migrate an individual project.
Project's SCM info report
When a project has multiple modules, interpolated SCM info in sub-modules is wrong, and info report displays the wrong info: for example http://maven.apache.org/ref/3.1.0/maven-artifact/source-repository.html
Some tweaks in parent pom can be done to improve things: http://maven.apache.org/ref/3.1.1/maven-artifact/source-repository.html
There are improvements to MPIR 2.8 to simplify things (MPIR-290). and to improve explanations for release tag (MPIR-291).
With actual Git Webview configuration at Apache, the only way to have web view is to link to GitHub: need to be improved
Setup review board
use Apache review board ? https://reviews.apache.org ?