here is current state: - using github link does fix web access in modules problems: see actual 3.1.1staging [1] - with MPIR-291, branches and tags are supported: "git clone --branch <tag>" instructions are generated - with MPIR-290, I did a hack to remove module path from git clone instructions
with these enhancements, I think git in reports is consistent now: no more non-working instructions generated What is still missing IMHO is: - git scm transform rule during release to modify web access link - update in scm component scm:git: format to support module path at end, to replace MPIR-290 hack with something better designed any other idea? anybody to work on some of the remaining points? Regards, Hervé [1] http://maven.apache.org/ref/3-LATEST/maven-core/source-repository.html Le lundi 2 septembre 2013 20:13:42 Robert Scholte a écrit : > Op Mon, 02 Sep 2013 07:13:27 +0200 schreef Chris Graham > > <chrisgw...@gmail.com>: > > On Sun, Sep 1, 2013 at 8:21 PM, Hervé BOUTEMY <herve.bout...@free.fr> > > > > wrote: > >> if I read Jazz SCM url format [1], in a multi-module build, scm info > >> automatically calculated from root to modules (ie appending artifact-id) > >> will > >> give wrong scm info, no? > >> did you try it? > > > > All of my testing was for multi module projects. Nested ones. So it was > > never a problem. > > > > There is an ugly work around/hack (that automatically happens) for > > non-nest > > projects. So add a dummy path to the end of the Component name, and it > > seems to work out. > > > > As the SCM section is only in the root pom, it does not seem to be > > effected. > > > > A tag (in maven SCM terms) is the equivalent of a snapshot of a component > > (in Jazz SCM terms). Technically, it is a collection of Change Sets, but > > effectively works out to be a "tag" for a given component. > > > > So I think of all modules as a part of the same component (just like all > > modules under a trank/branch in svn). so it tends to work nicely. > > > >> there are 2 other parts: > >> - m-release-p: did you add any logic to deal with plugin scm info > >> modification > >> when tagging a version? > > > > I didn't, but I think that Robert had to add some logic in there that > > applied to Jazz (and I think some others as well). I'd have to go back > > and > > look. > > Indeed, there are several ScmTranslator implementations, see > http://svn.apache.org/repos/asf/maven/release/trunk/maven-release-manager/sr > c/main/java/org/apache/maven/shared/release/scm/ It's still a dream to > remove any scm implementation specific code from this project... > > Robert > > >> - m-pir-p: when you do a checkout (or clone, or view, I don't know the > >> exact > >> term for Jazz), IIUC, you get a repository copy: did you write some > >> instructions in the generated page to cd to module base directory? > >> (again > >> for > >> multi-module builds) > > > > You're the first to ask about this. > > > > I just quickly run a site build, and the generated URL's in the Source > > Repository pages are wrong, as they assume the ability to check out just > > one module of a multi module project (eg SVN terms, a svn checkout of > > .../trunk/Module). This shows the CVS/SVN embedded thinking that is > > pretty > > much implicit across much of the SCM and Release modules. > > > > I do not believe that it is possible to check out (via the command line, > > I > > think that you _may_ be able to via the GUI) one sub dir (ie Module) of a > > Jazz SCM Component. > > > > A checkout in Jazz SCM terms is a "Load". :-) > > > > See: > > > > http://maven.apache.org/scm/maven-scm-providers/maven-scm-provider-jazz/in > > dex.html > > > > > > [1] http://maven.apache.org/scm/jazz.html > > > >> Le dimanche 1 septembre 2013 09:54:39 Chris Graham a écrit : > >> > I did something similar in the Jazz provider. It's a complex URL, or > >> > >> can > >> be > >> > >> > if it needs to be, but it's still a single line. > >> > > >> > It's just a matter of making the parser smarted. And that's local to > >> > >> the > >> > >> > provider, so go nuts. I also put lots of unit tests in there to > >> > >> illustrate > >> > >> > the correct and incorrect usage. > >> > > >> > -Chris > >> > > >> > On Fri, Aug 30, 2013 at 6:33 AM, Hervé BOUTEMY <herve.bout...@free.fr > >> > > >> >wrote: > >> > > Le samedi 24 août 2013 23:08:05 Robert Scholte a écrit : > >> > > > I agree that a single SCM line doesn't really match anymore with > >> > >> systems > >> > >> > > > like DSCM (git, Mercurial) > >> > > > It would have been better if we could think of a better way to > >> > >> define > >> > >> > > this > >> > > > >> > > > in a newer POM-model. > >> > > > >> > > it was overkill at the time Maven was done, and even today, > >> > >> splitting > >> scm > >> > >> > > developerConnection into 3 parts seems overkill for classical SCMs, > >> > >> even > >> > >> > > if > >> > > doable > >> > > > >> > > notice that even with "single SCM line", we can have multiple > >> > >> fields, > >> like > >> > >> > > we > >> > > already have for example with git to distinguish fetch and push > >> > >> urls: > >> > > <developerConnection>scm:git: > >> > > [fetch=] > >> > >> http://mywebserver.org/path_to_repository[push=]ssh://username@otherserve > >> r > >> > >> > > :8898/~/repopath.git </developerConnection> > >> > > > >> > > in the same spirit, we could support a branch and a path parts > >> > >> > > <developerConnection>scm:git: > >> https://git-wip-us.apache.org/repos/asf/maven.git[branch=]maven-3.0.x[pat > >> h > >> > >> > > =]/maven-core </developerConnection> > >> > > > >> > > with such scm url format, we have the structure we like without POM > >> > >> format > >> > >> > > change, and module value inheritance by adding artifact-id to the > >> > >> url > >> > >> > > stays > >> > > simple and consistent > >> > > > >> > > > >> > > Regards, > >> > > > >> > > Hervé > >> > >> --------------------------------------------------------------------- > >> > >> > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> > > For additional commands, e-mail: dev-h...@maven.apache.org > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
