[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15483:
------------------------------------
Rather than using a template, I've just decided to generate the composite*.xml files from commandline input, so it can be tweaked more easily from within a Jenkins job.
Thus, we run it like this:
{code}
Usage : ./generateCompositeStagingSiteMetadata.sh -NUM <num builds to include> -NAME 'Site Name' -JOBNAMES <job1,job2,job3,...> -SITES http://download.jboss.org/jbosstools/updates/site/to/include1,http://down....
{code}
Which for JBT 4.1 (keeping the latest 1 build for each component) would be:
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 1 -NAME 'JBoss Tools - Core - Stable Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/4.1.x.kepler/ -SITES http://download.jboss.org/jbosstools/updates/stable/kepler/,http://downlo... -JOBNAMES jbosstools-aerogear_41,jbosstools-arquillian_41,jbosstools-base_41,jbosstools-birt_41,jbosstools-central_41,jbosstools-forge_41,jbosstools-hibernate_41,jbosstools-javaee_41,jbosstools-jst_41,jbosstools-livereload_41,jbosstools-openshift_41,jbosstools-portlet_41,jbosstools-server_41,jbosstools-vpe_41,jbosstools-webservices_41,openshift-java-client-master
{code}
and for the master branch, JBT 4.2 (keeping the latest 2 builds for each component, if available):
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 2 -NAME 'JBoss Tools - Core - Trunk Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/master/-SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2... -JOBNAMES jbosstools-aerogear_master,jbosstools-arquillian_master,jbosstools-base_master,jbosstools-birt_master,jbosstools-central_master,jbosstools-forge_master,jbosstools-hibernate_master,jbosstools-javaee_master,jbosstools-jst_master,jbosstools-livereload_master,jbosstools-openshift_master,jbosstools-portlet_master,jbosstools-server_master,jbosstools-vpe_master,jbosstools-webservices_master,openshift-java-client-master
{code}
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15483 at 9/25/13 12:46 PM:
--------------------------------------------------------------
Rather than using a template, I've just decided to generate the composite*.xml files from commandline input, so it can be tweaked more easily from within a Jenkins job.
Here's the script:
https://raw.github.com/jbosstools/jbosstools-build-ci/master/util/generat...
Thus, we run it like this:
{code}
Usage : ./generateCompositeStagingSiteMetadata.sh -NUM <num builds to include> -NAME 'Site Name' -JOBNAMES <job1,job2,job3,...> -SITES http://download.jboss.org/jbosstools/updates/site/to/include1,http://down....
{code}
Which for JBT 4.1 (keeping the latest 1 build for each component) would be:
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 1 -NAME 'JBoss Tools - Core - Stable Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/4.1.x.kepler/ -SITES http://download.jboss.org/jbosstools/updates/stable/kepler/,http://downlo... -JOBNAMES jbosstools-aerogear_41,jbosstools-arquillian_41,jbosstools-base_41,jbosstools-birt_41,jbosstools-central_41,jbosstools-forge_41,jbosstools-hibernate_41,jbosstools-javaee_41,jbosstools-jst_41,jbosstools-livereload_41,jbosstools-openshift_41,jbosstools-portlet_41,jbosstools-server_41,jbosstools-vpe_41,jbosstools-webservices_41,openshift-java-client-master
{code}
and for the master branch, JBT 4.2 (keeping the latest 2 builds for each component, if available):
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 2 -NAME 'JBoss Tools - Core - Trunk Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/master/-SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2... -JOBNAMES jbosstools-aerogear_master,jbosstools-arquillian_master,jbosstools-base_master,jbosstools-birt_master,jbosstools-central_master,jbosstools-forge_master,jbosstools-hibernate_master,jbosstools-javaee_master,jbosstools-jst_master,jbosstools-livereload_master,jbosstools-openshift_master,jbosstools-portlet_master,jbosstools-server_master,jbosstools-vpe_master,jbosstools-webservices_master,openshift-java-client-master
{code}
was (Author: nickboldt):
Rather than using a template, I've just decided to generate the composite*.xml files from commandline input, so it can be tweaked more easily from within a Jenkins job.
Thus, we run it like this:
{code}
Usage : ./generateCompositeStagingSiteMetadata.sh -NUM <num builds to include> -NAME 'Site Name' -JOBNAMES <job1,job2,job3,...> -SITES http://download.jboss.org/jbosstools/updates/site/to/include1,http://down....
{code}
Which for JBT 4.1 (keeping the latest 1 build for each component) would be:
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 1 -NAME 'JBoss Tools - Core - Stable Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/4.1.x.kepler/ -SITES http://download.jboss.org/jbosstools/updates/stable/kepler/,http://downlo... -JOBNAMES jbosstools-aerogear_41,jbosstools-arquillian_41,jbosstools-base_41,jbosstools-birt_41,jbosstools-central_41,jbosstools-forge_41,jbosstools-hibernate_41,jbosstools-javaee_41,jbosstools-jst_41,jbosstools-livereload_41,jbosstools-openshift_41,jbosstools-portlet_41,jbosstools-server_41,jbosstools-vpe_41,jbosstools-webservices_41,openshift-java-client-master
{code}
and for the master branch, JBT 4.2 (keeping the latest 2 builds for each component, if available):
{code}
./generateCompositeStagingSiteMetadata.sh -NUM 2 -NAME 'JBoss Tools - Core - Trunk Staging Site' -DESTINATION tools@filemgmt.jboss.org:/downloads_htdocs/tools/builds/staging/_composite_/core/master/-SITES http://download.jboss.org/jbosstools/updates/requirements/xulrunner-1.9.2... -JOBNAMES jbosstools-aerogear_master,jbosstools-arquillian_master,jbosstools-base_master,jbosstools-birt_master,jbosstools-central_master,jbosstools-forge_master,jbosstools-hibernate_master,jbosstools-javaee_master,jbosstools-jst_master,jbosstools-livereload_master,jbosstools-openshift_master,jbosstools-portlet_master,jbosstools-server_master,jbosstools-vpe_master,jbosstools-webservices_master,openshift-java-client-master
{code}
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15483?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-15483:
-------------------------------
Description:
Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
Parameters to the generation would need to be:
a) template
b) number of builds per project to include (1, for stable_branch or 2, for trunk)
Constraints:
* Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
* Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
Worries:
* What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
{code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
was:
Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
Parameters to the generation would need to be:
a) template
b) number of builds per project to include (1, for stable_branch or 2, for trunk)
Constraints:
* Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
* Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
Worries:
* What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15483
> URL: https://issues.jboss.org/browse/JBIDE-15483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Reporter: Nick Boldt
> Assignee: Nick Boldt
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite... and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite...
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15484) Provide support for scaled app when tailing log files
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15484?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-15484 at 9/25/13 11:56 AM:
--------------------------------------------------------------------
For our own documentation purpose:
It's crucial to make sure the application is running on several gears.
1.) You need an application that creates some logs:
{code}
git clone https://github.com/jboss-jdf/ticket-monster.git
{code}
Then modify persistence.xml so that hibernate logs its queries to the log:
{code:title=src/main/resources/META-INF/persistence.xml}
<property name="hibernate.show_sql" value="true" />
{code}
Then build, copy the resulting war to the application git-repository and push it to OpenShift:
{code}
mvn clean package
cp target/ticket-monster.war ../../scaled/deployments/
git add ../../scaled/deployments/ticket-monster.war
git commit
git push origin
{code}
2.) to check whether the application is running on several gears, curl the application:
{code}
curl -H "Accept: application/xml; version=1.2" --user USERNAME:PASSWORD https://openshift.redhat.com/broker/rest/domains/foogoo/applications/scaled -X GET | grep gear-count
{code}
In the response you'll spot the gears it's running on via the *gear-count* property:
{code}
<gear-count>2</gear-count>
{code}
3.) Eventually scale it up manually (to have more gears more quickly than by auto-scaling):
{code}
curl -H "Accept: application/xml; version=1.2" --user USERNAME:PASSWORD https://openshift.redhat.com/broker/rest/domains/foogoo/applications/scal... -X POST -devent=scale-up
{code}
4.) Then produce some load via a bash-script that curls to the database-backend within ticketmonster:
{code}
#!/bin/sh
for i in {1..10000}
do
curl "http://scaled-foogoo.rhcloud.com/ticket-monster/rest/shows?event=1&_=1380..." -H "Host: scaled-foogoo.rhcloud.com" -H "Accept: application/json, text/javascript" -H "Referer: http://scaled-foogoo.rhcloud.com/ticket-monster/" -H "X-Requested-With: XMLHttpRequest"
done
{code}
5.) watch the application logs
was (Author: adietish):
For our own documentation purpose:
It's crucial to make sure the application is running on several gears.
1.) You need an application that creates some logs:
{code}
git clone https://github.com/jboss-jdf/ticket-monster.git
{code}
Then modify persistence.xml so that hibernate logs its queries to the log:
{code:title=src/main/resources/META-INF/persistence.xml}
<property name="hibernate.show_sql" value="true" />
{code}
Then build, copy the resulting war to the application git-repository and push it to OpenShift:
{code}
mvn clean package
cp target/ticket-monster.war ../../scaled/deployments/
git add ../../scaled/deployments/ticket-monster.war
git commit
git push origin
{code}
2.) to check whether the application is running on several gears, curl the application:
{code}
curl -H "Accept: application/xml; version=1.2" --user USER:PASSWORD https://openshift.redhat.com/broker/rest/domains/foogoo/applications/scaled -X GET | grep gear-count
{code}
In the response you'll spot the gears it's running on via the *gear-count* property:
{code}
<gear-count>2</gear-count>
{code}
3.) Then produce some load via a bash-script that curls to the database-backend within ticketmonster:
{code}
#!/bin/sh
for i in {1..10000}
do
curl "http://scaled-foogoo.rhcloud.com/ticket-monster/rest/shows?event=1&_=1380..." -H "Host: scaled-foogoo.rhcloud.com" -H "Accept: application/json, text/javascript" -H "Referer: http://scaled-foogoo.rhcloud.com/ticket-monster/" -H "X-Requested-With: XMLHttpRequest"
done
{code}
4.) watch the application logs
> Provide support for scaled app when tailing log files
> -----------------------------------------------------
>
> Key: JBIDE-15484
> URL: https://issues.jboss.org/browse/JBIDE-15484
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Final
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Fix For: 4.1.1.Alpha2, 4.2.0.Alpha1
>
>
> Seems like it's simply a matter of adding a '--gears' parameter in the ssh command when the application is scalable.
> The dialog could provide a checkbox (enabled by default) to let the user choose whether she wants to grab all logs or just those on the HA-Proxy
> See [~lincolnthree]'s blog post on the subject: http://ocpsoft.org/jboss/openshift-pro-tip-scaling-tail-server-logs-on-al...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-15522) Shoud validate when @Path arg at type does not match @PathParam on methods
by Xavier Coulon (JIRA)
Xavier Coulon created JBIDE-15522:
-------------------------------------
Summary: Shoud validate when @Path arg at type does not match @PathParam on methods
Key: JBIDE-15522
URL: https://issues.jboss.org/browse/JBIDE-15522
Project: Tools (JBoss Tools)
Issue Type: Feature Request
Components: webservices
Affects Versions: 4.1.0.Final
Reporter: Xavier Coulon
Assignee: Xavier Coulon
Fix For: 4.2.0.Alpha1
Let's take the following code:
{code}
@Path("/users/{username}")
public class UserResource {
@GET
@Produces("text/xml")
public String getUser(@PathParam("user") String userName) {
...
}
}
{code}
Validation should report a problem because of the mismatch between the {noformat}@Path{noformat} value and the {noformat}@PathParam{noformat} value
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (JBIDE-14929) Verbose application type dissapears after refreshing the connection
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14929?page=com.atlassian.jira.plugi... ]
Andre Dietisheim commented on JBIDE-14929:
------------------------------------------
In JBIDE-15429 I added support for downloadable cartridges in the openshift-java-client. In order to be able to support this I had to make sure that cartridges are loaded with the application (*?include=cartridges*). These changes fixed the cause of this issue. Thus the issue disappeared when I added (refered to the new maven artifact) the new client 2.4.0-SNAPSHOT to the Eclipse tooling
> Verbose application type dissapears after refreshing the connection
> -------------------------------------------------------------------
>
> Key: JBIDE-14929
> URL: https://issues.jboss.org/browse/JBIDE-14929
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Reporter: Stefan Bunciak
> Assignee: Andre Dietisheim
> Priority: Minor
> Fix For: 4.1.1.Alpha2, 4.2.0.Alpha1
>
> Attachments: shorthand-label.png, type1.png, type2.png, verbose-application-type.png
>
>
> !type1.png! -> !type2.png!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months