[ https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s... ] Jakub Senko updated AS7-5353: ----------------------------- Description: (was: Currently, the running the testsuite on Jenkins requires to manually configure new job, which is tedious work. It would be nice to automatize the process of building and testing AS. This can be done by developing a plugin for Maven which would build AS locally and then deploy it to Jenkins for testing and return back the results.) -- 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

[ https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s... ] Jakub Senko updated AS7-5353: ----------------------------- Description: Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins server. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. -- 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

[ https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s... ] Jakub Senko updated AS7-5353: ----------------------------- Description: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins server. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. was: Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins server. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. -- 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

[ https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s... ] Jakub Senko updated AS7-5353: ----------------------------- Description: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. *Technical description (in progress, suggestions welcome)* The maven plugin will consist of two goals. - the first goal will parse the job configuration from pom.xml a when executed, it will create new Job on the given Jenkins instance. configuration may look as simple as: was: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. -- 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

[ https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s... ] Jakub Senko updated AS7-5353: ----------------------------- Description: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. *Technical description (in progress, suggestions welcome)* The maven plugin will consist of two goals. The first goal will parse the job configuration from pom.xml a when executed, it will create new Job on the given Jenkins instance. Configuration to create a simple maven-based job may look as simple as: {code:title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <jobs> <job> <id>test</id> <name>test-${maven.build.timestamp}</name> <scm> <git>${git.url}</git> </scm> <rootPom>myapp/pom.xml</rootPom> </job> <ifExists>skip</ifExists> </jobs> </configuration> {code} The second goal will execute the job, and optionally performs some cleanup: was: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. *Technical description (in progress, suggestions welcome)* The maven plugin will consist of two goals. The first goal will parse the job configuration from pom.xml a when executed, it will create new Job on the given Jenkins instance. Configuration to create a simple maven-based job may look as simple as: {code:title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <jobs> <job> <id>test</id> <name>test-${maven.build.timestamp}</name> <scm> <git>git://github.com/jsenko/sandbox.git</git> </scm> <rootPom>myapp/pom.xml</rootPom> </job> <ifExists>skip</ifExists> </jobs> </configuration>}} {code} The second goal will execute the job, and optionally performs some cleanup: -- 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

[ https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s... ] Jakub Senko updated AS7-5353: ----------------------------- Description: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. *Technical description (in progress, suggestions are welcome)* The maven plugin will consist of two goals. The first goal will parse the job configuration from pom.xml a when executed, it will create new Job on the given Jenkins instance. Configuration to create a simple maven-based job may look as simple as: {code:title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <jobs> <job> <id>test</id> <name>test-job</name> <scm> <git>${git.url}</git> </scm> <rootPom>myapp/pom.xml</rootPom> <ifExists>skip</ifExists> </job> </jobs> </configuration> {code} The second goal will execute the job, and optionally performs some cleanup: {code:title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <runs> <run> <id>test</id> <name>test-${maven.build.timestamp}</name> <results> <!-- this describes which type of results and how are collected --> <result> <type>progress</type> <!-- simple progress bar is drawn while running the build remotely --> </result> <result> <type>shorttest</type> <!-- then a summary of the test results is displayed --> </result> <result> <type>shorttest</type> <!-- and it is also saved to a file --> <file>shorttest.txt</file> </result> </results> <failLocally>true</failLocally> <!-- fail the local maven execution when the remote Jenkins job fails --> </run> </runs> </configuration> {code} was: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. *Technical description (in progress, suggestions welcome)* The maven plugin will consist of two goals. The first goal will parse the job configuration from pom.xml a when executed, it will create new Job on the given Jenkins instance. Configuration to create a simple maven-based job may look as simple as: {code:title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <jobs> <job> <id>test</id> <name>test-job</name> <scm> <git>${git.url}</git> </scm> <rootPom>myapp/pom.xml</rootPom> <ifExists>skip</ifExists> </job> </jobs> </configuration> {code} The second goal will execute the job, and optionally performs some cleanup: {code:title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <runs> <run> <id>test</id> <name>test-${maven.build.timestamp}</name> <results> <!-- this describes which type of results and how are collected --> <result> <type>progress</type> <!-- simple progress bar is drawn while running the build remotely --> </result> <result> <type>shorttest</type> <!-- then a summary of the test results is displayed --> </result> <result> <type>shorttest</type> <!-- and it is also saved to a file --> <file>shorttest.txt</file> </result> </results> <failLocally>true</failLocally> <!-- fail the local maven execution when the remote Jenkins job fails --> </run> </runs> </configuration> {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

[ https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s... ] Jakub Senko updated AS7-5353: ----------------------------- Description: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. *Technical description (in progress, suggestions are welcome)* The maven plugin currently consists of two goals: The first goal will parse the job configuration from pom.xml a when executed, it will create new Job on the given Jenkins instance. Configuration to create a simple maven-based job may look as simple as: {code:xml|title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <jobs> <job> <id>test</id> <name>test-job</name> <scm> <git>${git.url}</git> </scm> <rootPom>myapp/pom.xml</rootPom> <ifExists>skip</ifExists> </job> </jobs> </configuration> {code} The second goal will execute the job, and optionally performs some cleanup: {code:xml|title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <runs> <run> <id>test</id> <name>test-${maven.build.timestamp}</name> <results> <!-- this describes which type of results and how are collected --> <result> <type>progress</type> <!-- simple progress bar is drawn while running the build remotely --> </result> <result> <type>shorttest</type> <!-- then a summary of the test results is displayed --> </result> <result> <type>shorttest</type> <!-- and it is also saved to a file --> <file>shorttest.txt</file> </result> </results> <failLocally>true</failLocally> <!-- fail the local maven execution when the remote Jenkins job fails --> </run> </runs> </configuration> {code} was: *Maven plugin to facilitate testing of local development git branches using distributed execution on Jenkins CI.* Currently, adding a feature or resolving a bug in large open source projects requires several steps: - getting the latest sources - using tools to let the community know about the issue, such as creating a JIRA page or assigning the developer to the issue - when working on the problem, developer builds the code periodically after each sub-problem is solved to see if there are no test regressions - after the work is done, developer usually starts a pull request, after which a Jenkins job is created and run - and if the job is successful, the problem is marked as resolved and the JIRA page updated Often the developer has no access to the community Jenkins machine, or at least until the pull request has started. But that is usually done at the final stages of development. Using Jenkins throughout the whole process would not only take off the load from his machine and provide a consistent testing environment, but would be very useful if there are other contributors working on the problem. If he wants to benefit from this, he has to set up his own Jenkins machine and manually create job(s) to run tests. However, doing this would be a tedious work and developer might consider it too time consuming to do. However, if there was a tool that could not only automate the creation of a Jenkins job, but also execute it and retrieve back the results it could be very useful. This can be integrated into maven as a plugin, and would cause the job to run remotely on a specified Jenkins instance. It can also automate other tasks mentioned earlier such as creating a development branch with a name according to name of the JIRA issue, or starting a pull request. The information about how the Jenkins job should be created and with which parameters it has to run can be defined directly in pom.xml of the project, and thus it will be part of the project itself and accessible to other developers. Apart from this main use-case, the plugin may be (after more development) useful as an administration tool for Jenkins. The configuration of a Jenkins server could be managed as any other community maven project. Also part of the project can be used as a Java API for remote access to Jenkins, which can be used in other projects. *Technical description (in progress, suggestions are welcome)* The maven plugin currently consists of two goals: The first goal will parse the job configuration from pom.xml a when executed, it will create new Job on the given Jenkins instance. Configuration to create a simple maven-based job may look as simple as: {code:title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <jobs> <job> <id>test</id> <name>test-job</name> <scm> <git>${git.url}</git> </scm> <rootPom>myapp/pom.xml</rootPom> <ifExists>skip</ifExists> </job> </jobs> </configuration> {code} The second goal will execute the job, and optionally performs some cleanup: {code:title=pom.xml|borderStyle=solid} <configuration> <url>${jenkins.url}</url> <runs> <run> <id>test</id> <name>test-${maven.build.timestamp}</name> <results> <!-- this describes which type of results and how are collected --> <result> <type>progress</type> <!-- simple progress bar is drawn while running the build remotely --> </result> <result> <type>shorttest</type> <!-- then a summary of the test results is displayed --> </result> <result> <type>shorttest</type> <!-- and it is also saved to a file --> <file>shorttest.txt</file> </result> </results> <failLocally>true</failLocally> <!-- fail the local maven execution when the remote Jenkins job fails --> </run> </runs> </configuration> {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

[ https://issues.jboss.org/browse/AS7-5353?page=com.atlassian.jira.plugin.s... ] Jakub Senko commented on AS7-5353: ---------------------------------- i've also created a document with the description on jboss community pages: https://community.jboss.org/wiki/MavenPluginToFacilitateTestingOfLocalDev... -- 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