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.

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.

Enjoy

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 10.38.5.26.

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 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.

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.

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.

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.

"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.