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. > - 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/index.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@otherserver > > > :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[path > > > =]/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 > >
