Let me suggest a generalization of Hervé's thought process. I submit that there are four issues here we might be trying to address. (1) users want to put an scm spec in an aggregating project and not have to repeat it (with slight mods) in all the modules. (2) users want to be able to toss a set of aggregation-unrelated projects into a single git repo, or some other SCM where there is a very sharp distinction between the coordinates of the repo and the coordinates of something in the repo (unlike svn), and (3), SCMs like P4 (with the problem of managing views) where there are complex aspects of the situation that don't fit nicely into a URI. (4) representing the distinction between 'here's how to obtain *this very module* versus *here's now to obtain the smallest unit that you can expect to type 'mvn at'.
If we are looking to 3.1, I think that all of these would be addressed best by making the <scm> element of the POM more complex, by treating it as a bag of properties, consisting of: 1: An SCM plugin identifier. 2: whatever the SCM would like to know to identify the sensible unit of checkin / checkout (we need a term for this. In Git it's a repo, for svn it's just a path). 3: A path within this unit for this project. 4: other, per-scm, parameters. Before 3.1, we can, of course, cram all this into one URI. The issue is how to separate stuff that is viable for the scm itself from our other information. Using a # inside 'the url' is unsafe, I submit, since some scm or another could really use a fragment for something. How about: scm2:new-maven-params:provider-tag:current-provider-params No one is forced to switch to scm2. If they want the features it enables, they have to eschew tools that don't support it. One thing still seems insufficient about this to me. Whether a project requires an aggregation environment to build is not, really, just an scm question. Right now, nothing inside a project states whether it is really independent (published parent) or not. In the case of complex parent structures, there is no simple scheme that does the job. Item 3 above sort of solves the problem. but does not distinguish between 'this is an independent project at relative path x within a lump of stuff you get from the scm' and 'this is only buildable as a module of some other aggregating project.' Do we really need to solve that? If so, we could add one more fact: the g:a of the parent from which a build makes sense. Maven could then chase up the parent tree to it. On Fri, Jul 15, 2011 at 4:13 PM, Hervé BOUTEMY <[email protected]> wrote: > Le vendredi 15 juillet 2011, John Casey a écrit : >> On 7/14/11 6:41 PM, Hervé BOUTEMY wrote: >> > we call it a URL, but it's a String in the POM [2] >> > Nothing prevents another way of interpreting this String: say properties >> > format? >> > If we want to transform this String to a DOM object in the POM, with >> > specific XML definition for each SCM, I only see the backward >> > compatibility as a strong problem >> > >> > Whatever the format is, maven-scm-api should provide an API to derivate a >> > module definition form its parent: AFAIK, this API doesn't exist, so >> > there should be a Jira issue for this in SCM. >> > Then Maven Core should use it when merging parent, instead of simply >> > appending module name [3]: another Jira issue is needed in MNG (for 3.1 >> > for example) >> >> I like that idea of having some sort of merge/inheritance calculator >> that's provider-specific. > another idea that would perhaps be easier: modify scm urls to ensure adding > path gives a viable url > eg for git: scm:git:git://server_name[:port]/path_to_repository#path > > I don't really know if this works in every case (tagging, or branching) > but this would permit us to keep the simple algorithm in Maven Core, and avoid > scm dependency (api + detected provider) > > there si a complete design to define > > Regards, > > Hervé > >> >> > And perhaps a proposal [4] to let us work on preparing this feature, >> > making choices, pointing to the Jira issues? >> > >> > Regards, >> > >> > Hervé >> > >> > [2] http://maven.apache.org/ref/3.0.3/maven-model/maven.html#class_scm >> > >> > [3] http://maven.apache.org/ref/3.0.3/maven-model- >> > builder/xref/org/apache/maven/model/merge/MavenModelMerger.html#438 >> > >> > [4] https://cwiki.apache.org/confluence/display/MAVEN/Proposals >> > >> > Le jeudi 14 juillet 2011, John Casey a écrit : >> >> The thing that's problematic here is that we're getting fairly deep down >> >> the rabbit hole on these sub-languages...it'd be so much better if we >> >> had a way to support a proper format for Git SCM information, rather >> >> than embedding all that information in a really complex pseudo-URL. >> >> >> >> On 7/14/11 4:19 PM, Hervé BOUTEMY wrote: >> >>> SCM url have mutiple parts when multiple parts mean something. >> >>> As you speak about git, [1] shows how tech and push urls can be >> >>> different for example >> >>> The algorithm to automatically derivate SCM url of a sub-module from >> >>> parent SCM should be provider dependendant, available from >> >>> maven-scm-api. And Maven Core would be dependendant on this API and >> >>> detected provider to calculate >> >>> >> >>> I remember of such a discussion a little while ago on this list, but I >> >>> don't remember the conclusion at that time >> >>> >> >>> Regards, >> >>> >> >>> Hervé >> >>> >> >>> [1] http://maven.apache.org/scm/git.html >> >>> >> >>> Le jeudi 14 juillet 2011, Andreas Sewe a écrit : >> >>>> Hi, >> >>>> >> >>>>> I'm not 100% sure it should be inherited at all. Inheriting unchanged >> >>>>> is only valid for something like Git, but probably never for SVN. >> >>>>> However, as you point out, Maven's current guess is usually not good >> >>>>> enough either. >> >>>> >> >>>> the problem is really that Maven currently has only a single element >> >>>> for something that requires two: one containing an absolute path to >> >>>> the current project's SCM, and one containing the relative path used >> >>>> to move from the aggregator's SCM to the child's. >> >>>> >> >>>> Just my $0.02. >> >>>> >> >>>> Andreas >> >>>> >> >>>> --------------------------------------------------------------------- >> >>>> 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] >> > >> > --------------------------------------------------------------------- >> > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
