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]
