Hi Alex,

Thanks for the response, that's been very informative, I think if we
considered SVN/Jenkins integration, it'd make life a lot easier. The more
we can automate, the fewer the mistakes, that's pretty much my only
reasoning, though obviously it'd have to be investigated to come up with a
workflow proposal that everyone agrees with.

As for Jenkins/Git, I absolutely agree, we're users of both and I'm a
staunch advocate of both too. Jenkins has its little quirks (I was going to
say, I wish you could create job templates, but turns out you can [1]!!!!)
but works like a dream most the time. And Git, well, I kinda like think Git
is to SVN as Linux is to Windows, both get the job done, but once you get
to appreciate what Git does, it just makes life so much easier.

While we're on the subject, if we could use a github (or similar, though I
don't know any other) system where version control, issue/bug tracking,
wikis and forks were all under one roof... Anyways, enough with my pipe

Thanks again,


[1] http://blog.cloudbees.com/2012/02/using-jenkins-templates-plugin-to.html

On 19 July 2012 17:09, Alexios Giotis <alex.gio...@gmail.com> wrote:

> Hi Mehdi,
> I will continue the hijacking of the commit message ..... I feel that
> opening a new thread might be disturbing and I don't know if the FOP
> community is interested. I hope I am helping a little to improve the
> processes and not spamming your inbox. I am not familiar with the Apache
> infrastructure but some years ago I updated our own development
> infrastructure (SVN / Jira / Jenkins / Artifactory / Confluence / ...) and
> are currently migrating from svn to git.
> On Jul 19, 2012, at 11:39 AM, mehdi houshmand wrote:
> > Having worked a little bit with PDFBox, they seem to have quite tight
> integration between the two such that (I think) JIRA prefixes SVN commits
> automatically with JIRA IDs (the JIRA number.) I don't know if this
> integration comes out the box or whether we need to do something to get it
> working, but it seems like a good idea.
> Actually JIRA has no write access to SVN and is not changing commit
> messages or anything. By looking at SVN [1] and Jira [2], I can tell that
> PDFBox committers are simply following the good practice of prefixing most
> commits with the related Jira issue. I guess that this is now going to be
> followed by FOP committers too. Although all SVN/Jira integration methods
> search the whole commit message for something looking like a Jira issue
> number, I suggest that you agree on a pattern. Two commonly used patterns
> for commit messages are:
> FOP-1: Commit message
> [FOP-1] Commit message
> We follow the 2nd as we may easily spot it, it is used by other tools
> (e.g. maven release plugin) and it's easier to track it with an SVN post
> commit hook that may reject the commit, send notification emails etc.
> [1] http://svn.apache.org/repos/asf/pdfbox/trunk
> [2] https://issues.apache.org/jira/browse/PDFBOX
> Related to the SVN / Jira integration, all the methods that I know,
> require someone with admin access to the infrastructure, and they are:
> ** A plugin installed to Jira. It adds an additional tab that shows the
> commits related to the Jira issue, see [3].
> ** Attlassian FishEye [4]. The Apache Camel project is somehow using it,
> for example scroll a little down and click the "Source" tab in [5]. Looks
> good but it seams that Attlassian is hosting the service.
> ** A plugin [6] installed in Jenkins (continuous integration tool) that
> adds a comment in Jira with the revision and the changed files when a new
> build has been created. Strangely [6] is currently showing a random plugin
> page each time refresh the page. If this is happening while you are reading
> this, use a google cached page.
> I selected and deployed the plugin for Jenkins because when the comment
> appears, the reporter of the issue knows that she could get and test an
> updated snapshot version of that project. The Apache infrastructure hosts
> Jenkins at [7]. I am a very happy Jenkins (Hudson) user and I recommend it.
> It should be very easy for everyone to set up a FOP build (needs SVN
> location, ant target and a selection of some options).
> [3]
> https://studio.plugins.atlassian.com/wiki/display/SVN/Subversion+JIRA+plugin
> [4] http://www.atlassian.com/software/fisheye/overview
> [5] https://issues.apache.org/jira/browse/CAMEL-4954
> [6] https://wiki.jenkins-ci.org/display/JENKINS/JIRA+Plugin
> [7] https://builds.apache.org/
> >
> > Also, I know Jeremias is a PDFBox committer and this applies to anyone
> else familiar with these tools, if they could chime in and give us some
> suggestions as to either useful tools and/or process best-practices. I
> should confess (as has probably been made abundantly obvious from silly
> mistakes) I despise SVN and eagerly anticipate the inevitable migration to
> a DSCVS of some type (preferably but not exclusively Git.)
> I have been using git for over a year and have decided to switch most
> projects to git. It seems to be the preferred distributed version control
> system at the Apache foundation as it provides mirrors of the projects [8].
> The learning curve is steeper compared to other systems but it should be OK
> with the few and experienced FOP developers.
> [8] http://git.apache.org/
> HTH,
> Alexios Giotis

Reply via email to