maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hervé BOUTEMY <herve.bout...@free.fr>
Subject Re: What is the correct Git SCM URL for a branch?
Date Tue, 10 Sep 2013 22:16:21 GMT
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
> 
> <chrisgwarp@gmail.com>:
> > On Sun, Sep 1, 2013 at 8:21 PM, Hervé BOUTEMY <herve.boutemy@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.boutemy@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-unsubscribe@maven.apache.org
> >> > > For additional commands, e-mail: dev-help@maven.apache.org
> >> 
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: dev-help@maven.apache.org
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message