We need to decide how to arrange Maven across one or more GIT repositories.

Options:

  • One Big Repo.
  • One Repo per current SVN TTB (e.g., all plugins together)
  • Many, Many Repos.

On the one hand, Mark S points out that it's desirable to be able to quickly make a tree with a bunch of our various svn TTBs in it. On the other hand, it seems to me (perhaps incorrectly), that any two things in the same git repo sort of need to share a branch strategy, since a GIT branch cuts across the entire repo.

Anyhow, this page is mostly a placeholder to allow others to chime in.

  • No labels

5 Comments

  1. Mark Struberg

    I'm really strictly -1 for giving each core plugin it's own GIT repo. I've seen a few projects who did this and they all ended up almost non-maintainable, with half of the repos dead and just confusing people. This happens all the time you retire some parts or rename them.

    But I just asked myself what we would loose if we export e.g. all the plugins project as 1 GIT repo?

    Ok, if you release a plugin then you will end up with a tag over the whole plugins repo. But who cares? If you maintain an old version then you probably only care about the folder of this very plugin. And you don't care whether the other folders in the repo contain some other stuff or not (and which version).

    Same for branches. You actually don't care if a branch also affects other plugins as long as you do not touch them.

    1. Kristian Rosenvold

      I think we can really choose to do all the plugins as one repo without really hurting ourselves (the way you describe, Mark); it's a decent option and it certainly doesnt have any significant downsides. Migrating every single svn repo as-is is perfectly ok.

      My personal preference would be 1 plugin 1 repo, as I can easily see how we can create cool tooling and make it work and handle it well (but that's probably me being lazy; I'mn sure N plugins 1 repo will do just fine (wink). But I'm open to good arguments as to why this can/will be a problem, preferably on a very practical level. (I don't really think our failing to document stuff properly is sufficient...)

      I think we should support the following use cases well:

      A) I want to fix a single problem/issue and when I'm done with that
      I'm going to submit a patch and get on with my life.
      B) I'm hooked. I fix things in a limited subset of the code base all
      the time. So I need to keep it recent, fresh and patched.
      C) I'm all over the place. I do global updates to dependencies and
      reformat code like there's no tomorrow.

      I really think it's only the "C" use case that needs special considerations if we decide to do 1 plugin 1 repo ?

      In any circumstances we need to stop using relative references to outside poms, like we do in the root pom of maven-plugins. I assume this means we need to start publishing this parent to central along with the maven poms?

      As for the general mayhem caused by renaming stuff, I think we as a project are mature enough to not care too much, it's much more of a problem for fresh young projects with significant itches for renaming ?

      1. Stephen Connolly

        I wonder if there is a case for grouping some of the core plugins and releasing them en-mass any time one changes.

        It might promote more frequent releases of some plugins...

        Group 1 - Core lifecycle

        • maven-clean-plugin/
        • maven-compiler-plugin/
        • maven-deploy-plugin/
        • maven-help-plugin/
        • maven-install-plugin/
        • maven-gpg-plugin/
        • maven-resources-plugin/
        • maven-source-plugin/
        • maven-toolchains-plugin/

        Group 2 - Site related

        • maven-changelog-plugin/
        • maven-changes-plugin/
        • maven-checkstyle-plugin/
        • maven-doap-plugin/
        • maven-docck-plugin/
        • maven-javadoc-plugin/
        • maven-linkcheck-plugin/
        • maven-pdf-plugin/
        • maven-pmd-plugin/
        • maven-project-info-reports-plugin/
        • maven-scm-publish-plugin/
        • maven-site-plugin/

        Group 3 - Packaging

        • maven-acr-plugin/
        • maven-assembly-plugin/
        • maven-ear-plugin/
        • maven-ejb-plugin/
        • maven-jar-plugin/
        • maven-jarsigner-plugin/
        • maven-rar-plugin/
        • maven-war-plugin/

        Group 4 - Utility

        • maven-ant-plugin/
        • maven-antrun-plugin/
        • maven-dependency-plugin/
        • maven-invoker-plugin/
        • maven-patch-plugin/
        • maven-plugins/
        • maven-reactor-plugin/
        • maven-remote-resources-plugin/
        • maven-repository-plugin/
        • maven-shade-plugin/
        • maven-stage-plugin/
        • maven-verifier-plugin/

        Group 5 - Integration Plugins

        • maven-eclipse-plugin/
        • maven-idea-plugin/
        • maven-one-plugin/

        Though it does mean that if we need to "reclassify" a plugin we loose history (sad)

      2. Jesse Glick

        Any dir where you can run release:prepare, such as a typical plugin, should be its own repository. (For what it’s worth the Jenkins project does it this way and the resulting repositories are certainly not “dead”.)

        1. Stanislav Ochotnicky

          I would second this approach from my POV. Each artifact with its own lifecycle should be in separate repository. It will have separate branches/tags etc. I find it much worse to have dead code being in the same repository as actively developed code. I

          However if you decide to go the way of one big repository, I'd like to see separate source tarball releases for each plugin for example. Getting source tarballs from SVN is not ideal, but it's still easier than handling one huge git repository.