On Wed, 20 Jun 2012 23:11:04 +0200, Ricky Clarkson
<[email protected]> wrote:
How do you have your release plugin/scm plugin configured, Fabrizio,
for that to work from git? I saw that various things had changed to
make that possible due to a number of complaints but haven't tried
them out.
Also, does that work for you from Windows? And if so, from paths with
spaces in them?
My setup has been tested extensively with Mercurial on Linux boxes and
(recently) with Subversion with both Linux and Windows boxes. I've also
gave it to a customer who's using Git, who has necessarily applied some
patch, but I've never assisted to a release by him so far. So I can't
speak for Git at the moment, but given the similarity with Mercurial I
don't see any issue.
As I said, with Subversion I can't avoid having some intermediate commits
in the middle. All the setup is coded in my superpom and all of my
projects use it. Everything can be found e.g. here:
http://hudson.tidalwave.it/hudson/job/TheseFoolishThings_Release/
(sources are in the workspace, or you can follow the bitbucket URL; the
job configuration, which should be publicly readable, contains the
sequence of operations to perform the release). The latest version of the
superpom, which contains the Windows fixes, hasn't been used for a late
release of this specific project, so I believe that if Murphy is around
something could break. But I need just the time to relax a bit (I've been
travelling as a shuttle recently) and retry everything.
For the record, the Hudson job has a parameter: "release commit" if you
want to really make a release, or "release cancel" which just tries
everything and then throws away the results. Usually releases go ok, but
when I feel I've made some risky changes I run a "release cancel" so I can
anticipate any problem and save time.
The basic trick is simple: in the release profile, two settings override
1) the URL of the SCM repo, pointing to a local repo created under target,
so when Maven pushes it pushes to it; and 2) the URL of the target Maven
repo, which againt points to a local directory. At the very end, a third
Maven run is performed which pushes the locally created SCM repo to the
remote and copies the artifacts to the remote repository. This has been
blogged about quite a time ago, but I can't recall the URL.
Note that the whole stuff can be simplified, for instance there are
multiple invocations of the antrun plugin to create directories and
initialize the local Mercurial repo. It could be probably done with the
gmaven plugin in Groovy and less lines of code, plus it would easily fit a
conditional for creating instead a Git repo. Also, I developed it a few
years ago and at the time I had to work around a bug in the Mercurial
support from the release plugin, which I believe that in the meantime has
been fixed; probably the trickery about pushing to a local repository
could be dropped today. I've planned to review it sooner or later, but as
far as it's working I don't feel urged to.
For what concerns spaces in paths, I've been bitten so hard in the past
that I'm not considering any more the option of having spaces in a
directory where there's some Java source or code (the problems typically
happen with Windows). That's truly a Java failure, or Windows, or both -
or my faulty understanding of how to quote paths. But it's a minor issue,
really.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
[email protected]
http://tidalwave.it - http://fabriziogiudici.it
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
