> Let children have sparse scm, and make it the job of the > scm provider, at runtime ...
Thought about that too. That would work for maven-scm, but there are lots of other plugins and extensions which access the URL information too. For example the site-reporting plugin uses it to report the SCM information. maven-changelog-plugin, etc. I think it could be possible, but would need some work... Anyone got a show-stopper for this approach? Too late for me to think about it over here, will ping back tomorrow morning. 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:31 PM > Mark, > > Oh, drat, I see, to pick a provider, we have to have > finished > processing extensions and all that other good > model-building stuff. > > OK, another thought. > > As per a previous comment in this thread, death to > inheritance in scm. > Let children have sparse scm, and make it the job of the > scm provider, > at runtime, to assemble all the information (including > correct 'url') > by working up the models of the parents. > > --benson > > > On Sat, Jul 16, 2011 at 7:25 PM, Mark Struberg <[email protected]> > wrote: > > 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] > > > > > > --------------------------------------------------------------------- > 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]
