Skip navigation
1 2 3 4 Previous Next


51 posts

In the latest version of CDW plugin for Jira (0.9.21) we implemented the feature that enables project administrators to set a default tester for each component of the administered project.


The feature works as following:

  • In the project administration, the user with admin privileges for the project selects the Component Testers tab leading to the feature UI. There for each component of the project the administrator can insert a username of the user that will be used as a default tester for the component. User picker (icon near the Default Tester input fields) can be used to find a specific user by their email or full name.

Screenshot from 2016-08-01 13:56:57.png


  • Then, once the tester for the components are set in the admin interface of the project, each newly created issue that has the component assigned and no tester set will get assigned this default tester.

Screenshot from 2016-08-01 14:02:15.png

Screenshot from 2016-08-01 14:02:48.png

  • Note that to trigger this functionality, exactly one component and no tester must be set in newly created issue.
  • If more, or no components are set or the tester field is filled on creation, the value of tester field will remain as at the issue creation.

Screenshot from 2016-08-01 14:19:48.png

See that the tester in newly created issue was filled according to the preferences set in the project admin UI.


The feature was implemented as a solution to [JIRA-217] Add "QE lead" for component



Hope the feature will help some!

Some people had problems downloading files from the Developers Program. The problem is in processing of company and country fields from the user profile. The most important part of the problem was fixed, however some users still end up in an infinite loop of inserting company and country fields.


If that happens to you, please, go to your profile and set the type of your address to "home". While there, you may also check that the country and company field - they must be filled as well.


We are sorry for the inconvenience. The problem will be fixed tomorrow.

JIRA Agile plugin of JIRA has been updated to latest version 6.7.6.


Search by the Sprint field for JIRA's basic search had been introduced in JIRA Agile 6.7.2. In this release, the Epic Link and Epic Name fields has been added as parameters for the basic search. Just navigate to the basic search, click More and add the Epic Link and/or Epic Name field.



Release contains few bugfixes also. For more details see Release notes JIRA server running at provides streamlined functionality of "Start Progress" action now, which is in align with latest JIRA default workflow.


You had to manually assign issue to yourself to be able to perform "Start Progress" action before this change. Now, the "Start Progress" action is available to all Assignable users (potential developers). Status of the issue is changed and you are made issue's Assignee once you use it, so one less click is necessary and workflow is more user friendly.





Lots of projects hosted in JIRA uses original "Git Pull request workflow" created about four years ago. This workflow allow user to manually switch issue to "Pull Request Sent" status once GitHub PR is created, and manually insert URL of pull request into "Git Pull Request" issue field. This workflow allows projects to better track and process Pull Requests, but heavily depends on manual work.


New JIRA features like DVCS plugin and event based workflow transitions introduces in JIRA 6.3 series allowed us now to create better PR tracking workflow, which removes this manual work.

This workflow automatically switch issue to "Pull Request Sent" status once GitHub PR is created and issue key is mentioned in PR's name or description. Pull Request URL is not stored in "Git Pull Request" issue field, but it is visible in "Development" area of JIRA issue detail screen.

JIRA issue is automatically resolved once GitHub PR is merged then. If GitHub PR is refused then no any JIRA issue status change is done.



Project leads who want use this feature for their JIRA project can follow next steps:

  • GitHub repository must be owned by github "Organization", personal repositories can't be linked
  • jboss-jira-hook github user must be added into the organization's Owners group. Jira needs this to add webhooks into GitHub repository to track changes immediately.
  • then you have to email with request to add your GitHub repository into JIRA configuration and switch your JIRA project to use "GIT Pull Request workflow with automatic PR triggers workflow scheme". You have to specify which Github repositories do you want to add (all owned by some Organization, or few named only) and which JIRA project should be switched.


Thanks pilhuhn for Feature request for this improved workflow and his testing on Hawkular project.

Two weeks ago two independent teams ran into the same issue. They deployed artifacts to and then they found out, that their builds are failing, because Maven was  not able to download some of the checksums. "" is an Apache instance, that load balances two Nexus proxy servers to mitigate the load. Both proxy servers read the data from a single master server.


It took us some time to find the reason, because not all check sums were missing and to make things even more interesting, some checksums were missing on just one of the proxies and some on both. Also in some cases sha1 checksum was missing, while md5 was present and vice versa...


We have a good news and a bad news for you. The good news is the builds will no longer crash due to "not found" checksums. Bad news is unless is resolved, directory listings on artifacts may not be accurate and it may have missing directories (they do not affect builds, just browsing with a web browser).


What Went Wrong?


For all the servers we use Sonatype Nexus version 2.7. If I want to explain the problem  it is important to explain how the Proxy Repository with Smart Proxy feature works.


Proxy Repository works like a cache. You build some project with a dependency on some artifact. Maven has a deterministic way how to calculate the URL of the downloaded file (artifact).  Your Maven client calculates this URL and tries to download the file from the calculated location in your proxy server.


Now two things can happen - the proxy repository already has the file and your Maven client downloads it from this location. Or the file is not present in the proxy repository on that URL. The proxy repository has "remote repository" defined. If the file is not found locally, Nexus tries to find the file in the remote repository. Then it either returns and stores the artifact or return not found to your client.


Nexus also knows, that if it downloads an artifact, there may be checksums available for it. The checksum is calculated as <URL of your artifact> + ".md5" or <URL of your artifact> + ".sha1". When Nexus downloads your artifact, it also remembers, if the checksums were present for this artifact.


I mentioned a Smart Proxy Feature. Normally the proxy repository remains empty, unless someone builds his project and his Maven client downloads some files from the proxy. With each build, the proxy repository is slowly filled with artifacts that are requested. This is useful, because if you for example use Maven Central as the remote repository, your proxy server is not flooded by zillions of artifacts from the remote, that no one uses. However directory listings on the proxy server do not display the directory listings of the remotes, but the artifacts cached locally. This means builds are OK, but people browsing such repository often complain about "missing artifacts".


Smart Proxy feature allowed us to solve this problem. Whenever someone deployed artifacts to the master server (= remote repository for the proxies), the smart proxy immediately pushed those to the configured proxy servers. However here lies the pitfall.


In the current version of Nexus when artifacts are released, they are pushed to the proxy servers immediately. Proxy server also checks for existence of checksums, however in some cases the proxy server checks for their existence after the master server releases the artifact but before the master manages to properly release the checksums. The proxy server marks a note the artifact does not have the checksum even if it should have it. And in case your Maven client is configured to always check the checksums, your build will fails.


How We Fixed the Problem


Ideal solution would be to fix the Smart Proxy feature. This will be done sooner or later by Sonatype, you can monitor the progress here However I needed it to be fixed now so the builds do not fail anymore.  I had to disable the smart proxy feature for now. That way the artifact is requested by the nearest build and it is very unlikely to happen a microsecond after the artifact is published. That way the master server has enough time to release the checksums as well.


The builds will no longer fail, however due to the continuous populating of the proxy repositories directory listing will not always display all available artifacts. And do you remember I mentioned we have two proxy servers behind a load balancer? If you think it might mean one directory listing could possibly display different artifacts when accessed several times (the same URL), you are right.


There is a way how to fix this, but the way is very annoying. If you are a team leader you should consider it though. After you release your artifacts, you need to download all of them from both proxy servers.


Their URLs are and You have to be in Red Hat intranet and you might have to add those two to your hosts file. The IP address of both is


Final Word


I would like to thank vladimir_v and Rich Seddon (and his colleagues) from Sonatype for their help during the investigation of the problem. As soon as is fixed and I will update our Nexus to the fixed version and re-enable smart proxy so the both proxy servers become automatically populated again.


I’m pleased to announce that Fusesource forums has been migrated to forums on Monday 18th of August, 2014.


Most of the content has been migrated as archive to Fusesource Archive space at and then to two individual spaces 

Fuse ESB Enterprise at and Fuse MQ Enterprise


All original URLs are permanently redirected to corresponding content at



Over 16.000 posts migrated, including 830 attachments.

Over 1.500 new user accounts created. Accounts with same e-mail has been matched.


If your account has been newly created use Forgot password at or  Forgot username features to access your account.


Special thanks go to Jakub Senko who implemented the migration plugin, Vladimir Vasilev who helped with eng-ops part on side and Jon Anstey for his help on side.




Libor Krzyžanek Development Team

People report a bug that when they refresh Maven repository in their web browser (, they get different results (missing artifacts). This appears like a big bug, however I would like to shed light into this rather cosmetic problem.


It is caused by our new infrastructure behind Originally there was just one server that handled artifacts. As the load increased this solution started not to be good enough. Therefore we added two proxy machines in front of the original one. They serve as mirrors for the original instance and they are load balanced by Apache. A classical mirror is a complete copy of all artifacts. The proxy machines are not classical mirrors though. The files are served using proxy repositories of Sonatype Nexus, that stores just content people ask for on the machines. When an artifact is requested, Nexus delivers it from the local content and if he does not find it locally it tries to obtain it from the master. However directory listing in the web browser is always served from the locally stored content.


And this is the reason, why the two machines have different directory listing. If one artifact is requested by someone the load balancer uses one of the mirrors and the artifact is added to the directory listing of that particular instance. But when one display the repository listing and then refreshes it,  what may happen is that the listing will be displayed from the second instance, that does not have the artifact yet .


So i you worry about your builds - no worry! Both mirrors are identical and always return all the requested artifacts (even if it appears they are not there). Browsing the repositories using web browser may be confusing though. I will fix the issue somehow buthe builds are fine so the problem is not that big as it appears to be.

Today we switched to the new hardware for Two new dedicated servers now serve artifacts to the whole community.


We are happy, that we achieved a significant increase of request handling speed. After one hour of service there are no errors reported yet, but, please, if you find something odd, report it to so we can investigate it.

As we announced a week ago, we switched to a new hardware. Unfortunately our Apache does not seem to handle current load and so we are switching back to the original hardware. We are sorry for any inconvenience during the last hour.

There were troubles in the past with Maven repository, because the server was heavily overloaded by requests from the community. We did quite a lot of optimizations. A part of the load has already been removed by adding Akamai infrastructure in front of product artifacts. Also we added some automatic cleaning tasks to the system and optimized authentication plugin. As a result the server is now quite stable. Calling it fast would be exaggerating though. But there is a hope.....


Next week (2014-07-14 12:00 PM UTC)  we scheduled switching the load from one old machine to  two brand new servers that would split the load between one another. Why I am writing about it? Well it is a good news for anyone using but on the other hand there might be a risk of some issues we are not aware yet.


So I would like to ask project leaders: if you plan some important event on Monday July, 14th (release, conference etc.), please, contact me so we can reschedule the hardware changes to some "safer" date.

We're proud to announce new feature 'Social Log In and Sign Up' for website released few days ago.


It allows you to use your Google, GitHub, LinkedIn, Facebook and/or Twitter account to create a new user account. You can also link these accounts to your existing account.

The linking allows you to login to website later without entering other password if you are logged in on Google for example. You can simply resolve "I forgot password" cases also, by logging in over linked account and changing password then.


You can find Social provider icons directly on login page and use them for Log In or Sign Up.



If social account is not linked with any account yet, you can do that via next screen allowing you to link it with your existing account or create a new one.

Registration form is prefilled by name and email obtained from your social account to save your work a bit.



Later you can manage your Social accounts links from user profile page.



Based on statistics this new feature is very useful since aprox. 30% of newly created user accounts are created over it now. Google provider is the most popular one, making over three quarters of all uses. Facebook provider is second well ahead of other providers.


I'm pleased to announce new feature in forums.


You can reply to the forum's e-mail notification directly in your e-mail client.


Here's how it works:

  1. Someone posts a discussion message (either a new thread or a reply to an existing one).
  2. The forums sends email notifications to those people who have requested them.
  3. After reading the content of the post in the notification email, someone replies to the notification email with their response (taking care not to delete the token in the subject line).
  4. Forums parses the e-mail and locates the discussion thread to which the reply belongs and posts the reply to the community.


Note that this feature supports only discussion replies -- posts of new content and replies to other kinds of content aren't supported.



"comment by email" feature has been enabled for jira running at during today's outage.

It means you can reply to a notification email received from jira, and your text will be added as comment for the issue received email was about.


"Add a comment from the non quoted email body" handler is used. This message handler creates a comment, but only uses the 'non quoted' lines of the body of the email message. A quoted line is any line that starts with a '>' or '|' symbol and such lines of text will not be added to the comment. The issue to which the comment is added is chosen from the first issue key found in the email subject. The author of the comment is taken from the address of the email message's From: field. Messages from unknown email addresses are ignored silently.


As part of this task we have to change email address JIRA uses as From in emails to

You have to upgrade your "from JIRA" email filters if they depend on it.

Community Updates (aka Community Digest) are turned off by default from 13th of November, 2013.

It means that all users who have never changed their email preferences they'll not receive Community Updates.


If you'd like to turn it on back simply go to email preferences and change value of Community Digest field from "Never" to any other option e.g. Once-a-week summary.




Filter Blog

By date:
By tag: