Mark, I only see a cycle if the scm modules have to call back into the model to get the facts they need to answer the question the model is asking. If the model can load all of the scm facts for the current project and its parents into some data structure and pass it into the scm to ask it to fill in what's missing for the current project, then there's no cycle.
--benson On Sat, Jul 16, 2011 at 6:36 PM, Mark Struberg <[email protected]> wrote: > Hi folks! > > Just back from vacation so I try to slowly catch up speed ... > > There are a few things to take care off: > > a.) We must not introduce a circle: model -> scm -> model. In other words: we > cannot ask the scm provider to give us additional information to build the > model before the model has been built. This is a chicken-egg problem... > > b.) Yes, an URL is a coordinate to access the repository. Since GIT (and > other DSCMs) allow different protocols for push and pull, we needed > optionally add 2 path information to the URL. > > > We could now either opt for a clean solution, but this would most likely not > work with POM model-4.0. > > Or we could just add another step of indirection (the classical computer > science pattern): We introduce a SCM-URL-behaviour mapping. > * BehaviourA ('relative') is the one used by e.g. SVN and CVS: automatically > adding the submodule file path to the SCM URL while building the MavenModel. > * BehaviourB ('static') means to let the SCM URL untouched when constructing > the MavenModel. > > There must be a mapping somewhere between scm url regexp -> SCM-URL-Strategy, > e.g. "scm:svn"->relative, "scm:git"->static, "scm:jgit"->static,... > > This could be maintained in settings.xml and we deliver a default one in the > global settings.xml. That way it would be predefined but maintainable by the > user. > > LieGrue, > strub > > > --- On Fri, 7/15/11, Benson Margulies <[email protected]> wrote: > >> From: Benson Margulies <[email protected]> >> Subject: Re: SCM info and modules >> To: "Maven Developers List" <[email protected]> >> Date: Friday, July 15, 2011, 8:47 PM >> 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]
