The Model gets constructed and only if that step is finished, all the information to determine the correct scm provider GAV is available!
But at this point in time it's too late to modify the SCM url because afaik the Model cannot get amended, right? At least that's what I remember from grabbing into this very problem 2 years ago. That was maven-2 back then, so not sure if things have changed in mvn-3... LieGrue, strub --- On Sat, 7/16/11, Benson Margulies <[email protected]> wrote: > From: Benson Margulies <[email protected]> > Subject: Re: SCM info and modules > To: "Maven Developers List" <[email protected]> > Date: Saturday, July 16, 2011, 11:08 PM > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
