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.

In fact, when talking about this (like in the other thread[1]) if we're going to divide the pom (build-time, dep-time), we might wonder if this info is still required, because: - there's some kind of redundancy in it. During build-time it is not interesting. On the other hand, during packaging it is super interesting: How nice would it be if the URL, branch/tag (DSCM) or path (non-DSCM) and revision were added to the pom. This also solves the chicken/egg problem when talking about including the revision in the pom.xml. During build-time this is impossible to add this to the pom.xml, but when using it as a dependency it is great if you had the exact SCM coordinates. - In all cases you'd like to refer to the trunk/master, since contributers should check out that part of a repository instead of a tag.

Robert

[1] http://markmail.org/message/af5odr62vxmlpubc


Op Sat, 24 Aug 2013 18:54:06 +0200 schreef Hervé BOUTEMY <herve.bout...@free.fr>:

Le samedi 24 août 2013 17:12:20 Fred Cooke a écrit :
Apologies, however as Herve noted, the web URL is variable across different
web implementations so it too should likely be left as is, being a human
chosen URL for human use. The previous SVN butchering of such fields
doesn't necessarily apply to other systems like HG or Git. My 2c.
"butchering" = immediate negative judgement, which does not help working
together

there is no butchering: just a common assumption done in pom inheritence that
scm web view module path would be equal to parent web view path + '/' +
artifact id

this is true for most commons ways of navigating in a web browser to something
that is like a directory structure
so whatever SCM you're using, if it provides a web view tool, having such a
simple algorithm should be sufficient to deduce module web view url from
parent's one: it does not seem crazy to consider web view tool developers have
applied this convention. Then with this simple algorithm, Maven can avoid
explicit configuration in module pom

I'm here talking about web view

And let's start generalization to other SCM parameters, since this extends
quite naturally now

For SCM connection and developerConnection urls, however, I admit that this algorithm might be too simplistic, but assumed sufficient since CVS and svn
checkout urls have such properties
But even there, such assumption is not crazy (going from parent SCM location to module should be like doing "cd artifact-id") and should be feasible if SCM
format is explicitely defined by convention to behave like this (such
convention has not yet been defined).
And since SCM parameter in Maven pom is a Maven SCM component url (scm:*), which contains a native SCM repository url (in SCM-specific format), but is not
limited to this info, nothing prevents us to extend Maven SCM url to add
information for SCM types that do not define branch or directory from
repository root in their native url format (like every DVCS, some commercial
SCMs)

Then Maven SCM API should be changed to improve ScmRepository API: actually, ScmRepository is told to represent a SCM repository, but in fact, IMHO, it
represents a repository + a branch + a directory

Does it sound reasonable?

Regards,

Hervé


On Sat, Aug 24, 2013 at 5:08 PM, Baptiste Mathus <m...@batmat.net> wrote:
> See http://maven.apache.org/pom.html#SCM Hervé is talking about
> xpath:/SCM/url which is indeed a scm web ui and said (developer)Connection
> would be discussed in another thread.
>
> Cheers
>
> Le 24 août 2013 16:57, "Fred Cooke" <fred.co...@gmail.com> a écrit :
> > I understood that the purpose of the SCM *URL* was to be able to *use*
> > it with a tool (where browser != tool), as such, there is only one
> > correct URL, the rest are paths for browsing on a file system or
> > web-front end. I did this knowing it would fail to illustrate the
> > point:
> >
> > fred@cheetah:~/workspaces$ git clone
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x
> > Cloning into 'maven-2.2.x'...
>
> > fatal:
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x/i
> nfo/refs>
> > not found: did you run git update-server-info on the server?
> >
> > On Sat, Aug 24, 2013 at 4:49 PM, Hervé BOUTEMY <herve.bout...@free.fr>
> >
> > wrote:
> > > I made some research and tests and here are my findings
> > >
> > > for the scm url, ie. web access like we have ViewVC url for svn, git
> >
> > provides
> >
> > > GitWeb equivalent to ViewVC (even if a lot of other solutions exist
>
> [1]),
>
> > > which is what is configured on Apache git http
> > > Then the GitWeb url format is in the git documentation [2]
> > >
> > > With this format, you can refer to branches, tags and revisions, like
> > > following examples:
> > >
> > > branches:
> > >   HEAD:
> > >     https://git-wip-us.apache.org/repos/asf/maven.git/tree/HEAD
> > >
> > >   maven-3.0.x:
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-3.0.x
> >
> > >   maven-2.2.x:
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/heads/maven-2.2.x
> >
> > > tags:
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-3.1.0
> >
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-3.0.5
> >
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/tags/maven-2.2.1
> >
> > > revisions: (same examples as previous tags)
>
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/5a0e6574404b4964522
> d90c3438e25574a95466c
>
>
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/fbdd91ba01387485598
> 935fe7d340261239e6a31
>
>
> https://git-wip-us.apache.org/repos/asf/maven.git/tree/238f83f8230b1e0ad32
> 39ca7e4f849591331c801>
> > > From the GitWeb url format documentation [2], we should be able to
> >
> > navigate
> >
> > > into the reporitory directories by ading ":/<path>", but it fails on
> >
> > Apache
> >
> > > GitWeb installation:
> > https://git-wip-us.apache.org/repos/asf/maven.git/tree/HEAD:/maven-core
> >
> > > it works on Git's GitWeb installation
> > >
> > >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/gitweb
> > >
> > > I don't know why Apache GitWeb is failing: previous version? some
> > > configuration?
> > > I know that even if the feature worked, this wouldn't permit us to let
> >
> > Maven
> >
> > > calculate automatically child scm url from parent, since the format
> >
> > requires
> >
> > > ':/' to be added for the first directory:
> > >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2
> > >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/gitweb
> > >
> > > For actuel Maven to correctly calculate the second from the first, we
> >
> > would
> >
> > > need to write
> > >
> > >   http://repo.or.cz/w/git.git/tree/tags/v1.8.2:
> > > or  http://repo.or.cz/w/git.git/tree/tags/v1.8.2:/
> > > which are both unsupported by GitWeb actually
> > >
> > > Notice GitHub's url format works like a charm:
> > > https://github.com/apache/maven/tree/maven-3.1.0
> > > https://github.com/apache/maven/tree/maven-3.1.0/maven-core
> > > https://github.com/apache/maven/tree/maven-3.0.x
> > > https://github.com/apache/maven/tree/maven-3.0.x/maven-core
> > >
> > >
> > > Should we configure scm url to point to GitHub mirror instead of
> > > Apache
> > > canonical repo?
> > >
> > > I still didn't had a look at the way release plugin can transform
>
> branch
>
> > url
> >
> > > to release url during pom.xml modification: I wanted to share these
> >
> > findings
> >
> > > first
> > >
> > > I had some thought about scm connection and developerConnection, but
>
> it's
>
> > > another story and this mail is already quite long: we'll see it after
>
> we
>
> > > improve web access support.
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > >
> > > [1]
>
> https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools#Web_Inte
> rfaces>
> > > [2] http://git-scm.com/docs/gitweb.html#_actions,_and_urls
> > >
> > > Le samedi 10 août 2013 13:12:00 Dennis Lundberg a écrit :
> > >> Hi,
> > >>
> > >> I'm looking at the sources for Maven core in Git, which I'm learning
> > >> as I go along.
> > >>
> > >> "master" is at version 3.1.1-SNAPSHOT and has this in its pom.xml
> > >>
> > >>   <scm>
> > >>
> > >> <connection>scm:git:https://git-wip-us.apache.org/repos/asf/maven.git
> >
> > </conn
> >
> > >> ection>
> >
> > >> <developerConnection>scm:git:
> > https://git-wip-us.apache.org/repos/asf/maven.
> >
> > >> git</developerConnection>
> > >> <url>https://git-wip-us.apache.org/repos/asf?p=maven.git</url>
> > >> <tag>HEAD</tag>
> > >>
> > >>   </scm>
> > >>
> > >> The head "maven-3.0.x" is at version 3.0.6-SNAPSHOT and has this in
>
> its
>
> > >> pom.xml <scm>
> > >>
> > >> <connection>scm:git:https://git-wip-us.apache.org/repos/asf/maven.git
> >
> > </conn
> >
> > >> ection>
> >
> > >> <developerConnection>scm:git:
> > https://git-wip-us.apache.org/repos/asf/maven.
> >
> > >> git</developerConnection>
> > >> <url>https://git-wip-us.apache.org/repos/asf?p=maven.git</url>
> > >> <tag>HEAD</tag>
> > >>
> > >>   </scm>
> > >>
> > >> Since this is identical to what is in "master" I don't think this
> > >> would work if you tried to do a release using the Release Plugin.
> > >> Wouldn't that release what is specified in <tag> i.e. "HEAD". Now, I
> > >> have looked through our documentation and used Google to find a
> > >> solution, but to no avail. From what I have gathered we should change
> > >> the value of <tag>, but to what? Would it involve
> > >> "ref/heads/maven-3.0.x"?
> > >>
> > >> The head "maven-2.2.x" is at version 2.2.2-RC1-SNAPSHOT and has this
> > >> in its pom.xml
> > >>
> > >>   <scm>
> > >>
> > >> <connection>scm:svn:
> > http://svn.apache.org/repos/asf/maven/maven-2/branches/
> >
> > >> maven-2.2.x</connection>
> >
> > >> <developerConnection>scm:svn:
> > https://svn.apache.org/repos/asf/maven/maven-2
> >
> > >> /branches/maven-2.2.x</developerConnection>
> > >> <url>http://svn.apache.org/viewvc/maven/maven-2/branches/maven-2.2.x
> >
> > </url>
> >
> > >> </scm>
> > >>
> > >> Obviously this has not been updated since the move to Git, which is
> > >> one of the things I'm trying to fix.
> > >>
> > >> Hopefully someone who has made a release using Maven Release Plugin
> > >> from a Git branch can shed some light on this.
> > >
> > > ---------------------------------------------------------------------
> > > 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

Reply via email to