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/src/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/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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
