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]
