We will definitely be using the scm locations from the POM, combined with some dark magics on resolving where the project is located (think maven-plugins with multiple projects sharing the same root). Mark has tried explaining this algorithm on irc several times, but my eyes go watery every time. This time I suppose I'll have to find out ;=)
The problem I see with supporting multiple different SCMs is that at some point their model breaks down, and at some point quite fundamentally. Let me get into a very subtle detail: When you have multiple top-level project sharing "plexus-utils" and you run a command like "mvn git-snapshot plexus-utils" (inside surefire) I think what really needs to be done is "git checkout -tb surefire-snapshot origin/master"; in other words we create a branch that represents the changes done in context of surefire. When you run the corresponding "mvn git-snapshot plexus-utils" inside the "maven-jar-plugin", you probably create a branch for the changes in context of jar-plugin. If you do that, you can basically be in a position to ALWAYS be able to switch contexts (I can resume working on my jar-plugin changes while being in mid-progress on the surefire changes). You can just auto-commit and change branch The clue here is that this is the "plexus-utils" clone will have one branch tracking head for each top-level project, as well as the master branch from asf. Now this is the stuff git is built for; I can pick changes between the branches like cherries from an autumn tree. The only way I can map this onto subversion involves making a number of distinct checkouts of the same project (tags, trunk and feature branches); I think this is a receipe for disaster. So while I should be able to check out svn projects, I'm afraid the feature set of the plugin I want to make is not very adaptable/valuable in svn. We *will* of course use maven-scm; and I'm sure the smart people here will come up with some models that allow this plugin to be useful for svn too ;) I'm sure we'd work well with hg. Since no code has been written yet, we're free to call it what we want ;) I added a section on GITHUB support to the end of the wiki page Kristian 2012/9/13 Olivier Lamy <[email protected]>: > Hi, > This idea looks nice :-). > I imagine you will retrieve scm locations of dependencies from their poms. > In such case dependencies can be a mix of scm (git, svn, hg etc..) > So I would prefer we try to do something more generic to provide such > features for all scms we support with maven scm (hey we have a very > generic scm api :-) ). > Maybe it's the case and just the plugin name confuse me :-). > > 2012/9/13 Kristian Rosenvold <[email protected]>: >> I have just added wiki document to discuss the design of a totally new >> plugin I have dubbed the "git-workspace-plugin". >> >> The idea is to change the way we work with layered multi-module >> projects in git that will make it a whole lot easier for anyone >> wishing to make a change to do so. >> >> The page is at >> https://cwiki.apache.org/confluence/display/MAVEN/git-workspace-plugin >> and I would really appreciate any kind of feedback on this. >> >> Feel free to edit the page, I will also keep it up to date ;) >> >> Kristian >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Olivier Lamy > Talend: http://coders.talend.com > http://twitter.com/olamy | http://linkedin.com/in/olamy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
