Skip navigation
1 2 3 4 Previous Next

Website

51 posts

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.

Hi,

 

     We've released a new theme for project pages deployed on jboss.org domain. It's based on Bootstrap v.2.3.1 on top of which our JBoss Community theme is applied. To make the theme as easy to start with as possible, we've developed an Awestruct site project https://github.com/jbossorg/bootstrap-community which can be forked on github and used as a starting point for any jboss.org project site. Thanks to this project you gain all the needed configuration done together with layouts, custom Awestruct extensions and the theme itself applied. If you're interested to see how it looks live after it's built and deployed, click on the screenshot below.

 

example.png

 

For more information on how to start with your jboss.org project site please refer to README.md file of the github project.

Hi,

 

now you can send documentation pages from Confluence running at https://docs.jboss.org/author to your Amazon Kindle reader.

ConfluenceToKindle.png

 

This feature was introduced over new Confluence to Kindle plugin.

Hi,

 

during jboss.org JIRA outage last week we introduced new plugin called JIRA DVCS Connector for Bitbucket and GitHub.

This plugin allows to directly show commits from Github repositories on JIRA issue page, with links pointing back to the Github directly. So it's not necessary to use FishEye at source.jboss.org anymore for this kind of functionality.

 

New "Commits" tab is shown on issue detail page. It contains informations about GitHub commits with key of the issue mentioned in the commit message.

JIRA-Github-tab.png

Plugin allows JIRA issue transitions directly from a Github commit message also.

 

JIRA DVCS connector plugin uses Github web hooks to propagate commits into JIRA immediatelly, which brings small restriction into process of connection.

 

Project lead, who wants to link his project's Github repository with JRA, must follow next steps:

  1. Repository must be owned by github "Organization", personal repositories can't be linked
  2. jboss-jira-hook github user must be added into the organization's Owners group. Jira needs this to add webhooks.
  3. then you have to send email to help@jboss.org and ask jira administrators to add repository into JIRA DVCS configuration. You have to specify which Github repositories do you want to add (all owned by some Organization, or few named only), and if you want to allow automatic JIRA issue transitions from a Github commit messages.

 

Enjoy.

jboss.org JIRA instance has been updated last Thursday to bring you latest version of JIRA and GreenHopper, as you can see in release notes.

 

JIRA upgrade from 5.2.5 to 5.2.7 brings mainly few bugfixes, no any significant change for users was introduced here.

 

GreenHopper upgrade from 6.1.1 to 6.1.3.2 brings few new features, for example:

  • Search for Issues by Epic Name
  • Search for Sprint by Name
  • Add more Fields to the Issue Detail View
  • Create Issue when viewing an Epic in JIRA

You can find links to complete release notes for all new versions in ORG-1616.

 

Two new plugins was introduced also. Separate blogpost will be published for both of them later to introduce what they bring for users.

Hi,

 

a few weeks ago we configured jboss.org JIRA instance (issues.jboss.org) to allow remote linking of issues with Hibernate JIRA (hibernate.onjira.com) and Apache JIRA (issues.apache.org/jira). This feature allows better linking of issues with upstream/downstream project issues. Linking with Hibernate JIRA is bidirectional, so you can link from Hibernate JIRA issues to jboss.org issues too. Linking with Apache jira is possible from jboss.org JIRA only,  linking is not configured on Apache jira side.

 

The feature is available from common jira issue Link action. Linking dialog now contains new field called "Server", where you can specify JIRA server you want to link issue from. Then you can directly type in issue key from selected server, or search issue against the server.

jira-link-remote.png

Details about JIRA remote issue linking are available in JIRA documentation.

jboss.org JIRA instance has been updated this Wednesday to bring latest version of JIRA and other installed plugins and some bugfixes as you can see in release notes.

 

JIRA

JIRA point upgrade from 5.2 to 5.2.5 brings mainly bugfixes and performance improvements. One noticeable change is move of reports from dropdown menu to the panel on the Project Summary page, so they are more accessible now.

https://confluence.atlassian.com/download/attachments/313464399/browse_project_summary-annotated.png

 

GreenHopper

GreenHopper has been upgraded from 6.0.8 to 6.1.1 which brings few new features and enhancements. Main enhancement is introduction of Epics, which provide you with an additional hierarchy of story management, providing planning guidance for groups of issues within, or across, projects. For details see 6.1 and 6.1.1 release notes.

 

Balsamiq Mockups

Balsamiq Mockups plugin for JIRA has been upgraded from 2.2.2 to 2.2.4 which brings support for linking to web addresses (URL's) in all controls that support linking and other improvements and fixes. See relese notes for full list of changes.

Pages like http://www.jboss.org/gatein/downloads/gateinportal.html or http://www.jboss.org/drools/downloads use a nice "Directory listing" paragraph. This paragraph mirrors a file system and keeps the download pages up-to-date without the actual page to be manually updated. This paragraph was introduced by Jozef Chocholáček, but in the next release (= 7.8.0 Magnolia) several enhancements and  fixes were done. The release will go public on Wednesday December 5th at 2:00 PM (CET).

 

Latest release hightlight

This feature was present in the previous version, but it was completely overhauled. It is backwards compatible thought. You can place a hightlight to the new version of your product between the paragraph title and the directory listing. Originally the highlight text was hard-coded to "Looking for the latest version? Download". Now it is just a default text, but you can change it to whatever you want. Also originally it was possible to higlight just one link, now it is up to you how many of them you want to use.

 

How to set this up? First of all you need to have a file lastRelease.properties in the root directory of your project. If this file is found, it is not displayed in the paragraph, but its content is parsed and used to set the content of the paragraph instead. Why are those settings in the filesystem and not in the Magnolia paragraph dialog? It is likely the latest versions are generated and deployed by some automatic process. And while it is easy to just copy one more file to some directory, it would be much harder to modify things in a web form automatically.

 

OK. So we have this lastRelease.properties file. It is a classical property file, where on each line you write a key, "=" character and after it its value. The lastRelease.properties has following keys:

 

 

KeyDescription
lastReleaseA link to the page with the last release. The URL can be either absolute (in that case no processing is done on it) or relative. If it is relative a base URL is added to the link (in case of JBoss pages it is http://downloads.jboss.org). If this key is missing, the latest release will not be highlighted and just the directory listing will be displayed in the paragraph.
lastReleaseTextIf ommited, this key defaults to "Looking for the latest version? Download ". If you specify it, your text will be displayed prior to the link on the web page.
lastReleaseURLTextWhile lastRelease specifies the URL to the latest release, the path might not be pretty for human readers. Therefore you can specify a text, that will be displayed in the web browser. If ommited, the paragraph tries to dig some pretty name from the lastRelease value, but the result will not be as nice as if you specify it yourself.

 

If you need more links to the latest versions (i.e. your project has several parts and you want to highlight each part), now you can add numbers to the key after the name starting with 0 and increasing by one in the lastRelease.properties file.  The paragraph will render all the highlights unless finds a missing number. So if you specify lastRelease0, lastRelease1 and lastRelease3 keys, the first two will be displayed, but lastRelease3 will be ignored, because lastRelease2 is not present.

 

The keys lastReleaseText and lastReleaseURLText have their numbered variants and of course the number binds all together. However the defaults are slightly different here, because the long texts are not good if used several times:

 

KeyDescription
lastRelease<n>A link to the page with the last release. If ommited, lastRelease<n+1> and the higher will not be processed.
lastReleaseText<n>The text prior to the link.It defaults to lastReleaseURLText<n> with ": ". If neither lastReleaseURLText<n> is specified, the default value of lastReleaseURLText<n> + ": " is used.
lastReleaseURLText<n>Similar to the unnumbered lastReleaseURLText.

 

Example:

lastRelease=http://absolutepath.some.org/dir/subdir

lastReleaseText=Download the newest version here:

lastReleaseURLText=Latest Release

lastRelease0=latest0

lastRelease1=latest1

lastReleaseText1=Latest release 1:

lastRelease2=latest2

lastReleaseText2=Latest release 2:

lastReleaseURLText2=Download

 

Will render as

directoryListing.jpg

What you can not see on the picture are the values of the links. So the first link (under Latest Release) will be  as http://absolutepath.some.org/dir/subdir, because the path was absolute and therfore unchanged. The second highlight is not nice, because lastReleaseText0 and lastReleaseURL0 were not specified and latest0: latest0 is the best what the paragraph was able to dig out from it. The URL under latest0 will be http://downloads.jboss.org/latest0, because the link is relative. The remaining two highlights are better, because the values are specified.

 

Note: the numbered and unnumbered keys are independent. You can use just numbered, just unnumbered or both variants.

 

Enough about the last release highlights. I need to explain some other new feature before I will be able describe some magic you can do with those highlights.

 

More directory listing paragraphs on a single web page

 

The old directory listing paragraph was supposed to be alone on a web page. Also it interfered with another Magnolia paragraph, but it is another story. It was not mentioned anywhere, so some users put several directory listing paragraphs on a single page. When someone navigated within the directory structure displayed in the paragraph, that paragraph displayed the content of the chosen subdirectory (correct), but the other paragraphs reported errors, because they tried to search for the same subdirectory in their part of file system, but they did not have it.

 

Now the navigation is independent in each paragraph. Originally "dir" attribute was added to the URL of the download page. E.g. http://localhost:8080/exampleformpage.html?dir=java caused the paragraph to render the content of the "java" directory. Now it changed. The dir attribute now holds the identification of the paragraph. I.e. if we have two paragraphs on the single page, the URL might look like http://localhost:8080/author/exampleformpage.html?dir=01%3Ddownloads%3B00%3Djava%3B. The URL says, that in the  paragraph 01 downloads subdirectory should be displayed and the paragraph 00 should display the java subdirectory. It looks horrible, but %3D is "=" and %3B is ";". So if you hover your mouse above the link in your browser, you will see something like http://localhost:8080/author/exampleformpage.html?dir=01=downloads;00=java; . I think that makes things clear.

 

 

The promised "directory listing magic"


In case you know how the dir parameter works, you may use this knowledge to construct the URL to your "latest release highlight" section. And if I speak about this feature as "latest release", the reason why you have it there may be completely different. I.e. if you have a project with several logical parts - one with a validation, second with a persistence or whatever.

 

The easiest way how to use it is to find the directory with the content you would like to highlight in the web browser. Copy the link and use it into your lastRelease.properties file. Keep in mind that that way you can set all the directory listing paragraphs of a single page.

 

 

Complete list of directoryListing paragraph changes in the new version

 

(just in the case someone cares).

 

- fixed crashes when serveral directoryListing paragraphs were on the same page

+ when date is selected as a sorting column, a file name is a secondary column

- fixed a problem with broken colors after sorting in directoryListing paragraph

- removed several possibilities to crash directoryListing paragraph by adding wrong paths

+ if more than just one directoryListing paragraph are present on a page, user can navigate independently in each. The system rembers the position in each paragraph instead of displaying an error

- fixed a problem with expanding of checksums of files, that have the same checksum (a completely different div on the page was expanded)

* newer version of Modeshape library is used

+ added some info about how to use the paragraph into Magnolia form of the paragraph.

- fixed a problem with spaces in the latest release highlight links.

Hi all,

 

new integration point for JBoss Community systems is here as I promised last week. It's based on feature request ORG-1560 and allows you to display build results from Jenkins instance running at the hudson.jboss.org on the issues.jboss.org hosted JIRA dashboard or on some pages of community.jboss.org.

Displaying build status on JIRA Dashboard

If you want to display build status on jira dashboard, simply login to JIRA and display your dashboard (you have to create your personal dashboard if not created one yet and use only default dashboard). Then use "Add Gadget" button at top right, select "Other" group in "Gadget directory", and use "Add now" button for "Build Status" gadget.

JiraBuildGadget1.png

Then you can close "Gadget directory" and configure gadget on dashboard to show selected build. Use small arrow button on top right of gadget window to open menu, and use "Edit" item here. Then you can put name of selected jenkins job into provided input field and "Save" it.

JiraBuildGadget2.png

Page is reloaded and voila, build status for selected job is shown here.

JiraBuildGadget3.png

Color around Job title is changing depending on status of last builds to provide you quick visual information. It can be green, yellow or red. Job title acts as link to the job page in Jenkins server. And there are links to the latest, latest successful and latest stable builds of given Job too.

 

If you want to monitor more jobs simply add other "Biuld Status" gadgets into Dashboard.

Displaying build status in community.jboss.org

Very similar process can be used to display build status in some pages of community.jboss.org system. It can be used on all pages with configurable layout as is Personal dashboard, Space main page, Group main page etc. 

SBSBuildGadget.png

Technical background

Build status displaying is based on Google Gadget technology, so in reality it can be used in each system/container supporting this technology. Gadget is hosted as plugin in JIRA, and uses Jenkins REST API to obtain build status information to be displayed.

If you want to use this gadget in another gadget container system, you can find URL to the Gadget definition xml file on JIRA "Gadget directory" page, it's https://issues.jboss.org/rest/gadgets/1.0/g/org.jboss.jira.plugin.build-gadgets:build-status-gadget/gadget.xml .

 

And finally, source code for this gadget is available at https://github.com/jbossorg/jira-jenkins-gadget

 

Enjoy

Hi,

 

this week we performed upgrade of JIRA instance running at issues.jboss.org to fix some bugs and bring you few new features.

JIRA point version upgrade from 5.1.4 to 5.1.7 is about bugfixes only, but GreenHopper upgrade from 6.0.3 to 6.0.6 brings you something new as you can see in release notes:

 

We also continue to improve our community members experience, productivity and collaboration by better integration of distinct systems. Latest addition to this topic on JIRA side is automatick linking to the RedHat bugzilla, based on  ORG-1098 feature request.

Simly if you use something like BZ-12345 or BZ#12345 or Bug 12345 in JIRA issue descriptions, comments etc. it's automatically rendered as link pointing to the bug in RedHat bugzilla.

And we are working on more integrations in our systems, stay tuned ;-)

 

Enjoy.

As you probably noticed, jboss.org JIRA instance running at http://issues.jboss.org have been upgraded today to JIRA 5.1.4 and GreenHopper 6.0.3

 

This minor JIRA update patches few problems as you can see in Release Notes. Probably most noticeable for common user is better handling of text selection in fields on issue detail page, which do not force inline editing anymore.

 

GreenHopper has been updated from 6.0 to 6.0.3 which seems as minor upgrade too. But beside bunch of bugfixes it brings much more new feature than expected, as you can see in https://confluence.atlassian.com/display/GH/GreenHopper+6.0.2+Release+Notes and https://confluence.atlassian.com/display/GH/GreenHopper+6.0.3+Release+Notes. Main enhancements and changes:

  • Multiple active sprints
  • Ability to rename future sprints
  • Burndown Report shows what didn't get done
  • Customisable Issue Detail View
  • Visual indicators for distinct types of board.
  • Easier management of Remaining Estimate

 

Enjoy

Hi,

 

we are happy to announce upgrade of JBoss Community Search service http://search.jboss.org/.

 

Indexing More Mail Lists

 

We are starting indexing more community mailing lists, in particular we added CDI, Bean Validation, JBoss Forge, PicketLink, JBoss Developer Framework and JBoss-RPM mail lists.

 

Respective filters were added to the Project filter:

project-filter.png

Adding OpenSearch Support

OpenSearch is a collection of technologies that allow publishing of search results in a format suitable for syndication and aggregation. For example many web browsers have built-in support for OpenSearch.

 

Ricardo Martinelli Oliveira approached our team with the idea to implement it for JBoss Community search and he provided first implementation. We took his idea a step further and developed a solid OpenSearch support including extensions like search suggestions and autodiscovery that will make sure it adapts to any changes we make in the underlying implementation going forward (so once you install it, it will not stop working when we rename the URL endpoint).

 

The following is how you can make use of OpenSearch in Firefox, Google Chrome and Safari browsers. For video demo see below:

Firefox

Firefox recognises OpenSearch plugins and gives you a chance to add them into your plugin list with a few clicks. It also supports search suggestions.

 

  • When you visit search.jboss.org Firefox will recognise OpenSearch plugin and if it hasn't been already installed you can install it by clicking on a magnifier symbol in search field. Then select And JBoss Community.
  • To make use of the plugin place your cursor into the search field, select JBoss Community and start typing. Note that you can get search suggestions at this point.
  • More: Learn to Manage Your Search Engines in Firefox.

Google Chrome

Google Chrome recognises and adds OpenSearch plugins automatically on the fly. So, as soon as you visit search.jboss.org for the first time, you can easily make use of the plugin. Google Chrome also supports search suggestions.

 

  • Visit search.jboss.org to make sure the OpenSearch plugin has been installed.
  • To make use of the plugin start typing in the web browser address bar search.jboss.org and at some point the browser will tell you that you can "Press tab to search JBoss Community".
  • Press tab. Now you can insert your query. Note that Google Chrome gives you search suggestions at this point.
  • More: Manage search engines in Google Chrome.

Safari

Safari browser is one of a few browsers that do not support OpenSearch out of the box. However, there is a nice Safari plugin called OpenSearchForSafari that adds support for it.

 

  • First you need to install the plugin.
  • Then visit search.jboss.org, note that the plugin signals a new OpenSearch plugin has been detected on this page and can be added to the list of your plugins. Just click the icon or use ⌥⌘O (Option-Command-O) and add the "JBoss Community" plugin.
  • Once you have the plugin added you can search in JBoss Community easily. Unfortunately, the OpenSearchForSafari plugin does not allow for sorting of individual plugins so each time you issue a new search you have to select appropriate plugin from the list.
  • Unfortunately, OpenSearchForSafari does not support search suggestions.

 

 

The following video shows you how to install and use OpenSearch for search.jboss.org in Firefox, Google Chrome and Safari browsers respectively:

 


http://www.jboss.org uses a plugin, that displas the last tweets from #jbossdeveloper. Very nice and useful plugin. However Jaikirian Pai suggested, that it would be nice, if the displayed Twitter account name was clickable and led to the user's profile. It was good idea. However it took some time to find out how to do that. Twitter has some documentation, but the features they describe do not include this (well at least it is well hidden and so I was unable to find it there).

 

So I thought this article might help you, if you want to do the same thing. If you know the user's account number, you can use following link:

 

http://twitter.com/account/redirect_by_id?id=<account number>

 

I.e. my profile is http://twitter.com/account/redirect_by_id?id=612507302

 

It is really just that easy, if you know the link.

 

And how to get the account number? Well there are many ways. If you are in Java,  twitter4j can be pretty handy. But this is another story, that depends on what you have at your disposal. Or if you just want yours, you can use this web page http://www.idfromuser.com. Remember to use @ before your name.

http://www.jboss.org runs mainly on Magnolia CMS. It is a web application, that runs on JBoss application server. Eng-ops (= the team responsible for maintaining infrastructure) reported, that logging does not work properly (the bug), because the logs are larger and larger and they are becomming huge. Jozef, the former colleague of mine, updated the configuration of the application server. We use log4j so the whole thing did not appear to be complicated. But the reality is sometimes quite interesting and so this issue remained unsolved for quite a long time.

 

Prequel - console.log is too long

 

First information I got was, that console.log is too long and everything from Java is logged into it. What I found in jboss-log4j.xml was very interesting:

 

   <!-- ============================== -->

   <!-- Append messages to the console -->

   <!-- ============================== -->

 

  <!-- appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">

      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>

      <param name="Target" value="System.out"/>

      <param name="Threshold" value="INFO"/>

 

      <layout class="org.apache.log4j.PatternLayout">

         <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>

      </layout>

   </appender -->

............................. 

 

  <!-- ======================= -->

   <!-- Setup the Root category -->

   <!-- ======================= -->

 

   <root>

      <!-- appender-ref ref="CONSOLE"/ -->

      <appender-ref ref="FILE"/>

   </root>

 

I knew little about log4j at start, but I knew what <!-- and --> does in xml. Just comment! So what the hell.... I asked Eng-ops to delete the old console.log file and to restart JBoss AS. The console.log was recreated and contained just a few lines of code. I also tried to raise some errors from applicaton, that might appear in this log (big thanks to Google for changing the API for getting Google analytics for giving me the error I needed). The error did not appear in the console.log, but in the log, that belonged to the specific web application responsible for rendering the web page instead. Nice! I asked again and was told, that the problem is actually server.log, not console.log. Aehmmm.....

 

The real fun - server.log too long

 

The configuration of the logger appeared to be valid:

 

  <!-- A time/date based rolling appender -->

   <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">

      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>

      <param name="File" value="${jboss.server.log.dir}/server.log"/>

      <param name="Append" value="true"/>

      <param name="Threshold" value="INFO"/>

 

      <!-- Rollover at midnight each day -->

      <param name="DatePattern" value="'.'yyyy-MM-dd"/>

 

      <layout class="org.apache.log4j.PatternLayout">

         <!-- The default pattern: Date Priority [Category] Message\n -->

         <param name="ConversionPattern" value="%d %-5p [%c] %m%n"/>

      </layout>

   </appender>

 

I copy pasted  it on my local machine and it worked very well. When a new day came, the server.log was renamed to server.log.<date> and the logging to server.log started from the current day. Exactly as it should have been. But alas! You could see something like that on the staging:

......

2012-08-30 17:32:51,130 INFO  [info.magnolia.cms.beans.config.PropertiesInitializer] Loading configuration at .................

2012-08-31 11:19:35,610 INFO  [com.arjuna.ats.jbossatx.jta.TransactionManagerService] JBossTS Transaction Service (JTA version) - JBoss Inc.

......

 

So no roll over at all. What could possibly be wrong? Why on one machine it does work and on the other does not? A different version of log4j? Perhaps. A different locale and thus date-time format? Also possible. Thanks God log4j is the open source and thus the source code is available for everyone. I.e. here. If you check the code, you can find, that the content of the log is irrelevant. The only thing that matters is the modification date and time of the log file. It still does not answer why the roll over does not happen.

Unless you check the way, how the JBoss is started. We use a script for it, that has something like that inside:

 

   for logfile in boot.log cluster.log console.log server.log; do

        if [ -f /var/log/$NAME/$JBOSSCONF/$logfile ]; then

            if [ "$JBOSSUS" != "RUNASIS" ]; then

                $SU $JBOSSUS -s /bin/sh -c "touch /var/log/$NAME/$JBOSSCONF/$logfile >/dev/null 2>&1"

                if [ ! $? -eq 0 ]; then

                    failure $"${NAME} startup"

                    echo -n -e "\nLogfile /var/log/$NAME/$JBOSSCONF/$logfile exists but not writable by $JBOSSUS."

                    echo -n -e "\n"

                    return 4

                fi

            else

                if [ ! -w /var/log/$NAME/$JBOSSCONF/$logfile ]; then

                    failure $"${NAME} startup"

                    echo -n -e "\nLogfile /var/log/$NAME/$JBOSSCONF/$logfile exists but not writable."

                    echo -n -e "\n"

                    return 4

                fi

            fi

        fi

    done

 

 

And this is it. Touch changes the time, whe the server starts. And because there are logs to be written just when the application server starts, the date of the log file is always the current date and the roll over  never happen.

Filter Blog

By date:
By tag: