1 2 3 4 Previous Next


49 posts

JIRA Agile plugin of jboss.org 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 https://confluence.atlassian.com/display/AGILE/JIRA+Agile+6.7.6+Release+Notes

jboss.org JIRA server running at https://issues.jboss.org 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 jboss.org 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 help@jboss.org 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 repository.jboss.org and then they found out, that their builds are failing, because Maven was  not able to download some of the checksums. "repository.jboss.org" 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 https://issues.sonatype.org/browse/NEXUS-7654 is resolved, directory listings on repository.jboss.org 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 https://issues.sonatype.org/browse/NEXUS-7654. 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 proxy01-repository.jboss.org and proxy02-repository.jboss.org. 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 Vasilev and Rich Seddon (and his colleagues) from Sonatype for their help during the investigation of the problem. As soon as https://issues.sonatype.org/browse/NEXUS-7654 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 jboss.org forums on Monday 18th of August, 2014.


Most of the content has been migrated as archive to Fusesource Archive space at https://community.jboss.org/en/fusesource-archive and then to two individual spaces 

Fuse ESB Enterprise at https://community.jboss.org/en/esb-enterprise and Fuse MQ Enterprise https://community.jboss.org/en/mq-enterprise.


All original URLs are permanently redirected to corresponding content at commnity.jboss.org.



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 https://community.jboss.org/emailPasswordToken%21input.jspa or  Forgot username https://community.jboss.org/forgot-username%21input.jspa 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 jboss.org side and Jon Anstey for his help on fusesource.com side.




Libor Krzyžanek

jboss.org Development Team

People report a bug that when they refresh Maven repository in their web browser (repository.jboss.org), 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 repository.jboss.org. 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 repository.jboss.org. 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 help@jboss.org so we can investigate it.

As we announced a week ago, we switched repository.jboss.org 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 repository.jboss.org 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 repository.jboss.org 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 jboss.org website released few days ago.


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

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


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



If social account is not linked with any jboss.org account yet, you can do that via next screen allowing you to link it with your existing jboss.org 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 jboss.org user profile page.



Based on statistics this new feature is very useful since aprox. 30% of newly created jboss.org 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 jboss.org 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 issues.jboss.org 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 issues@jboss.org

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.




Jboss Maven repository (repository.jboss.org) supposed to have three levels of users of staging profiles. Anonymous users had no rights to Nexus staging suite. A JBoss Developer group was supposed be able to deploy artifacts to staging group and a Productization group was supposed to be able to release and promote staging artifacts.


However for some historical reason the last two groups were merged together allowing the developer group to be able to release and promote artifacts as well.


After the server upgrade today, these two groups will be distinguished again. So that means it is possible it may affect your work - it did not matter, if you had been  just in the "JBoss Developer" group before, but if so and you need to release or promote staged artifacts, you need to ask me (e-mail to help(at)jboss.org) and your project leader (to confirm your privilege).

Right now anonymous users have read access to all the artifacts on this server. This policy is about to be changed. The old repositories, that were accessible will remain accessible for anonymous users in future and also some other repositories will be added.


However some of the new repositories will not be accessible for general public (they will contain immature testing stuff). Why am I writing about a change, that most of the people will not even notice?


The thing is I might have missed something. If you want to know if your project will be OK, you can try to build it using  "jboss-anonymous" account (password "anonymous") instead of the anonymous access. If it fails due to missing rights, please, report the issue here.

Filter Blog

By date:
By tag: