November 2016 - jbosstools-issues

[JBoss JIRA] (JBDS-4201) CLI-only installation is available but does not provide necessary info

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-4201?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-4201: ----------------------------- Attachment: InstallConfigRecord.xml > CLI-only installation is available but does not provide necessary info > ---------------------------------------------------------------------- > > Key: JBDS-4201 > URL: https://issues.jboss.org/browse/JBDS-4201 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Enhancement > Components: installer > Affects Versions: 10.2.0.GA > Reporter: Misha Ali > Fix For: 10.3.0.GA > > Attachments: InstallConfigRecord.xml > > > I had some feedback from another writer testing a procedure with devstudio. He was using a CLI-only VM and was confused because the installer worked but offered little information, as would be expected. > Essentially, the non-GUI installation worked (java -jar devstudio_version.jar) but did not ask where to install devstudio, nor did it provide the default target folder it used. The GUI version asks if the user wants to deploy devstudio after the installation, but the non-GUI version does nothing. The resulting user experience was confusion, not knowing where devstudio was installed or how to start it. > My questions here are: > - is the non-GUI way a valid installation path? If yes, we should document it, and if not, we should mention it, either in the docs or when installation happens. > - If the non-GUI installation is a valid path, it should replicate the questions in the wizard, such as where to install devstudio and which jdk to use, etc. The difference between the two installation paths causes confusion. > Any thoughts? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ] Nick Boldt reassigned JBIDE-23384: ---------------------------------- Assignee: Martin Malina (was: Nick Boldt) > Include integration-tests in staging and stable update sites > ------------------------------------------------------------ > > Key: JBIDE-23384 > URL: https://issues.jboss.org/browse/JBIDE-23384 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: updatesite > Affects Versions: 4.4.2.AM2 > Reporter: Martin Malina > Assignee: Martin Malina > Fix For: 4.4.2.Final > > > This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds. > Currently we have this repo: > http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t... > We're referencing it from our root pom: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > And set up a repository definition for it. > This allows us to run an individual test bundle. > This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory: > https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl... > With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/ > Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos. > So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things: > 1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case > 2. Make sure the proper devstudio is used to test against: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te... > -Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates > This also includes the TP, so RedDeer should be the correct version > 3. Make sure the proper integration-tests repo is used for dependencies > Now this is what we currently don't have. Our root pom will set up the snapshots repo: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > So that's why I would like to have a stable repo of this which I could use. > There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom. > To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA: > The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this. > Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this. > Also, I'd be happy to hear if you have some suggestions how to do it differently. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-23384 at 11/24/16 11:16 PM: --------------------------------------------------------------- I've added support for publishing the integration-tests site as part of staging (and release, too). However, I noticed that you don't publish a repository.zip file like the other jbt aggregates. If you want that, you'll need to apply this PR, then I can make some tweaks to the stage/check jobs to ensure the repository.zip is copied from snapshots -> staging, verified, and then later copied from staging -> development. https://github.com/jbosstools/jbosstools-integration-tests/pull/1673 Currently verifying the PR works in this temporary job which builds from my fork: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-integrati... Which publishes here: http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-int... And the zip is: http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-int... So the PR works. If you want to include a zip when staging/releasing, apply this and let me know. was (Author: nickboldt): I've added support for publishing the integration-tests site as part of staging (and release, too). However, I noticed that you don't publish a repository.zip file like the other jbt aggregates. If you want that, you'll need to apply this PR, then I can make some tweaks to the stage/check jobs to ensure the repository.zip is copied from snapshots -> staging, verified, and then later copied from staging -> development. https://github.com/jbosstools/jbosstools-integration-tests/pull/1673 Currently verifying the PR works in this temporary job which builds from my fork: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-integrati... It should publish a repo zip here, if it works... http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-int... > Include integration-tests in staging and stable update sites > ------------------------------------------------------------ > > Key: JBIDE-23384 > URL: https://issues.jboss.org/browse/JBIDE-23384 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: updatesite > Affects Versions: 4.4.2.AM2 > Reporter: Martin Malina > Assignee: Nick Boldt > Fix For: 4.4.2.Final > > > This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds. > Currently we have this repo: > http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t... > We're referencing it from our root pom: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > And set up a repository definition for it. > This allows us to run an individual test bundle. > This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory: > https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl... > With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/ > Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos. > So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things: > 1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case > 2. Make sure the proper devstudio is used to test against: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te... > -Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates > This also includes the TP, so RedDeer should be the correct version > 3. Make sure the proper integration-tests repo is used for dependencies > Now this is what we currently don't have. Our root pom will set up the snapshots repo: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > So that's why I would like to have a stable repo of this which I could use. > There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom. > To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA: > The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this. > Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this. > Also, I'd be happy to hear if you have some suggestions how to do it differently. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23384: ------------------------------------ I've added support for publishing the integration-tests site as part of staging (and release, too). However, I noticed that you don't publish a repository.zip file like the other jbt aggregates. If you want that, you'll need to apply this PR, then I can make some tweaks to the stage/check jobs to ensure the repository.zip is copied from snapshots -> staging, verified, and then later copied from staging -> development. https://github.com/jbosstools/jbosstools-integration-tests/pull/1673 Currently verifying the PR works in this temporary job which builds from my fork: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-integrati... It should publish a repo zip here, if it works... http://download.jboss.org/jbosstools/neon/snapshots/builds/jbosstools-int... > Include integration-tests in staging and stable update sites > ------------------------------------------------------------ > > Key: JBIDE-23384 > URL: https://issues.jboss.org/browse/JBIDE-23384 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: updatesite > Affects Versions: 4.4.2.AM2 > Reporter: Martin Malina > Assignee: Nick Boldt > Fix For: 4.4.2.Final > > > This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds. > Currently we have this repo: > http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t... > We're referencing it from our root pom: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > And set up a repository definition for it. > This allows us to run an individual test bundle. > This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory: > https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl... > With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/ > Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos. > So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things: > 1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case > 2. Make sure the proper devstudio is used to test against: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te... > -Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates > This also includes the TP, so RedDeer should be the correct version > 3. Make sure the proper integration-tests repo is used for dependencies > Now this is what we currently don't have. Our root pom will set up the snapshots repo: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > So that's why I would like to have a stable repo of this which I could use. > There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom. > To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA: > The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this. > Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this. > Also, I'd be happy to hear if you have some suggestions how to do it differently. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23384: ------------------------------------ add integration-tests to verification tests in checkStagingURLs.sh > Include integration-tests in staging and stable update sites > ------------------------------------------------------------ > > Key: JBIDE-23384 > URL: https://issues.jboss.org/browse/JBIDE-23384 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: updatesite > Affects Versions: 4.4.2.AM2 > Reporter: Martin Malina > Assignee: Nick Boldt > Fix For: 4.4.2.Final > > > This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds. > Currently we have this repo: > http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t... > We're referencing it from our root pom: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > And set up a repository definition for it. > This allows us to run an individual test bundle. > This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory: > https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl... > With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/ > Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos. > So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things: > 1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case > 2. Make sure the proper devstudio is used to test against: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te... > -Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates > This also includes the TP, so RedDeer should be the correct version > 3. Make sure the proper integration-tests repo is used for dependencies > Now this is what we currently don't have. Our root pom will set up the snapshots repo: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > So that's why I would like to have a stable repo of this which I could use. > There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom. > To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA: > The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this. > Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this. > Also, I'd be happy to hear if you have some suggestions how to do it differently. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23384) Include integration-tests in staging and stable update sites

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23384?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-23384: ------------------------------------ add integration-tests to verification tests in checkStagingURLs.sh > Include integration-tests in staging and stable update sites > ------------------------------------------------------------ > > Key: JBIDE-23384 > URL: https://issues.jboss.org/browse/JBIDE-23384 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: updatesite > Affects Versions: 4.4.2.AM2 > Reporter: Martin Malina > Assignee: Nick Boldt > Fix For: 4.4.2.Final > > > This will allow us the use case of running integration tests against the latest release of devstudio. This use case is required by EAP QE running our tests against their EAP development builds. > Currently we have this repo: > http://download.jboss.org/jbosstools/neon/snapshots/updates/integration-t... > We're referencing it from our root pom: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > And set up a repository definition for it. > This allows us to run an individual test bundle. > This is mostly useful to satisfy test dependencies - tests depend on RedDeer as a whole which is in the target platform. But most tests also have a RedDeer extension in the plugins directory: > https://github.com/jbosstools/jbosstools-integration-tests/tree/master/pl... > With that, let's move on to why it would be useful to have a stable repo for this, e.g. http://download.jboss.org/jbosstools/neon/stable/updates/integration-tests/ > Imagine you want to run integration tests against the latest stable build. If you just checkout the integration tests and run a test plugin (using mvn verify), it will use everything from the latest nightly repos. > So to use latest stable release (jbt 4.4.1.Final / devstudio 10.1.0.GA), you need a couple of things: > 1. Checkout the corresponding branch of the integration tests - jbosstools-4.4.1.x in this case > 2. Make sure the proper devstudio is used to test against: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/te... > -Ddevstudio.repository=https://devstudio.redhat.com/10.0/stable/updates > This also includes the TP, so RedDeer should be the correct version > 3. Make sure the proper integration-tests repo is used for dependencies > Now this is what we currently don't have. Our root pom will set up the snapshots repo: > https://github.com/jbosstools/jbosstools-integration-tests/blob/master/po... > So that's why I would like to have a stable repo of this which I could use. > There is a workaround - run "mvn install" on the whole integration-tests repo before you run your test. This will install the correct version in your local repo and that may be then used by your test. But maven will probably still prefer the newer versions from the snapshots repo that is set up in the pom. > To give you an example what can break when you use the newest org.jboss.ide.eclipse.as.reddeer plugin, but run the EAP tests against devstudio 10.1.0.GA: > The EAP 7 server adapter had 7.0 in the type name in 10.1.0.GA, but in current master it's 7.x (to accommodate for the upcoming EAP 7.1). So if you want to test EAP 7.0.1 CP candidate build against devstudio 10.1.0.GA it will fail on this. > Sorry for the lengthy explanation, but I hope it's now clear why I'm requesting this. > Also, I'd be happy to hear if you have some suggestions how to do it differently. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23519) For JBIDE 4.4.2.Final: Prepare for 4.4.2.Final / 10.2.0.GA [arquillian]

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23519?page=com.atlassian.jira.plugi... ] Snjezana Peco closed JBIDE-23519. --------------------------------- Resolution: Done > For JBIDE 4.4.2.Final: Prepare for 4.4.2.Final / 10.2.0.GA [arquillian] > ----------------------------------------------------------------------- > > Key: JBIDE-23519 > URL: https://issues.jboss.org/browse/JBIDE-23519 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: arquillian > Reporter: Friendly Jira Robot > Assignee: Snjezana Peco > Priority: Blocker > Labels: task > Fix For: 4.4.2.Final > > > For JBIDE 4.4.2.Final [arquillian]: Please perform the following tasks: 0. Make sure your component has no remaining unresolved JIRAs set for fixVersion = 4.4.2.Final or 10.2.0.GA [Unresolved JIRAs with fixVersion = 4.4.2.Final, 10.2.0.GA|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22J...] 1. Check out your existing *{color:orange}master{color}* branch: {code} git checkout master {code} 2. Update your *{color:orange}master branch{color}* root pom to use the latest parent pom version, *{color:orange}4.4.2.Final-SNAPSHOT{color}*: {code} <parent> <groupId>org.jboss.tools</groupId> <artifactId>parent</artifactId> <version>4.4.2.Final-SNAPSHOT</version> </parent> {code} Now, your root pom will use parent pom version: features plugins pom.xml pom.xml.orig README.md site tests *{color:orange}4.4.2.Final-SNAPSHOT{color}* in your *{color:orange}master{color}* branch 3. Branch from your existing master branch into a new *{color:blue}jbosstools-4.4.2.x{color}* branch: {code} git checkout master git pull origin master git checkout -b jbosstools-4.4.2.x git push origin jbosstools-4.4.2.x {code} Now, your root pom will use parent pom version: features plugins pom.xml pom.xml.orig README.md site tests *{color:blue}4.4.2.Final-SNAPSHOT{color}* in your *{color:blue}jbosstools-4.4.2.x{color}* branch, too. 4a. Ensure you've *built your code* using the latest *minimum* target platform version 4.60.2.Final {code} mvn clean verify -Dtpc.version=4.60.2.Final {code} 4b. Ensure you've *run your tests using the latest *maximum* target platform version 4.60.2.Final {code} mvn clean verify -Dtpc.version=4.60.2.Final {code} 5. Close (do not resolve) this JIRA when done. 6. If you have any outstanding [New + Noteworthy JIRAs|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JBIDE...] to do, please complete them next. > [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for arquillian task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23519) For JBIDE 4.4.2.Final: Prepare for 4.4.2.Final / 10.2.0.GA [arquillian]

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23519?page=com.atlassian.jira.plugi... ] Snjezana Peco closed JBIDE-23519. --------------------------------- Resolution: Done > For JBIDE 4.4.2.Final: Prepare for 4.4.2.Final / 10.2.0.GA [arquillian] > ----------------------------------------------------------------------- > > Key: JBIDE-23519 > URL: https://issues.jboss.org/browse/JBIDE-23519 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: arquillian > Reporter: Friendly Jira Robot > Assignee: Snjezana Peco > Priority: Blocker > Labels: task > Fix For: 4.4.2.Final > > > For JBIDE 4.4.2.Final [arquillian]: Please perform the following tasks: 0. Make sure your component has no remaining unresolved JIRAs set for fixVersion = 4.4.2.Final or 10.2.0.GA [Unresolved JIRAs with fixVersion = 4.4.2.Final, 10.2.0.GA|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22J...] 1. Check out your existing *{color:orange}master{color}* branch: {code} git checkout master {code} 2. Update your *{color:orange}master branch{color}* root pom to use the latest parent pom version, *{color:orange}4.4.2.Final-SNAPSHOT{color}*: {code} <parent> <groupId>org.jboss.tools</groupId> <artifactId>parent</artifactId> <version>4.4.2.Final-SNAPSHOT</version> </parent> {code} Now, your root pom will use parent pom version: features plugins pom.xml pom.xml.orig README.md site tests *{color:orange}4.4.2.Final-SNAPSHOT{color}* in your *{color:orange}master{color}* branch 3. Branch from your existing master branch into a new *{color:blue}jbosstools-4.4.2.x{color}* branch: {code} git checkout master git pull origin master git checkout -b jbosstools-4.4.2.x git push origin jbosstools-4.4.2.x {code} Now, your root pom will use parent pom version: features plugins pom.xml pom.xml.orig README.md site tests *{color:blue}4.4.2.Final-SNAPSHOT{color}* in your *{color:blue}jbosstools-4.4.2.x{color}* branch, too. 4a. Ensure you've *built your code* using the latest *minimum* target platform version 4.60.2.Final {code} mvn clean verify -Dtpc.version=4.60.2.Final {code} 4b. Ensure you've *run your tests using the latest *maximum* target platform version 4.60.2.Final {code} mvn clean verify -Dtpc.version=4.60.2.Final {code} 5. Close (do not resolve) this JIRA when done. 6. If you have any outstanding [New + Noteworthy JIRAs|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JBIDE...] to do, please complete them next. > [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for arquillian task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23519) For JBIDE 4.4.2.Final: Prepare for 4.4.2.Final / 10.2.0.GA [arquillian]

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23519?page=com.atlassian.jira.plugi... ] Snjezana Peco reassigned JBIDE-23519: ------------------------------------- Assignee: Snjezana Peco > For JBIDE 4.4.2.Final: Prepare for 4.4.2.Final / 10.2.0.GA [arquillian] > ----------------------------------------------------------------------- > > Key: JBIDE-23519 > URL: https://issues.jboss.org/browse/JBIDE-23519 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: arquillian > Reporter: Friendly Jira Robot > Assignee: Snjezana Peco > Priority: Blocker > Labels: task > Fix For: 4.4.2.Final > > > For JBIDE 4.4.2.Final [arquillian]: Please perform the following tasks: 0. Make sure your component has no remaining unresolved JIRAs set for fixVersion = 4.4.2.Final or 10.2.0.GA [Unresolved JIRAs with fixVersion = 4.4.2.Final, 10.2.0.GA|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22J...] 1. Check out your existing *{color:orange}master{color}* branch: {code} git checkout master {code} 2. Update your *{color:orange}master branch{color}* root pom to use the latest parent pom version, *{color:orange}4.4.2.Final-SNAPSHOT{color}*: {code} <parent> <groupId>org.jboss.tools</groupId> <artifactId>parent</artifactId> <version>4.4.2.Final-SNAPSHOT</version> </parent> {code} Now, your root pom will use parent pom version: features plugins pom.xml pom.xml.orig README.md site tests *{color:orange}4.4.2.Final-SNAPSHOT{color}* in your *{color:orange}master{color}* branch 3. Branch from your existing master branch into a new *{color:blue}jbosstools-4.4.2.x{color}* branch: {code} git checkout master git pull origin master git checkout -b jbosstools-4.4.2.x git push origin jbosstools-4.4.2.x {code} Now, your root pom will use parent pom version: features plugins pom.xml pom.xml.orig README.md site tests *{color:blue}4.4.2.Final-SNAPSHOT{color}* in your *{color:blue}jbosstools-4.4.2.x{color}* branch, too. 4a. Ensure you've *built your code* using the latest *minimum* target platform version 4.60.2.Final {code} mvn clean verify -Dtpc.version=4.60.2.Final {code} 4b. Ensure you've *run your tests using the latest *maximum* target platform version 4.60.2.Final {code} mvn clean verify -Dtpc.version=4.60.2.Final {code} 5. Close (do not resolve) this JIRA when done. 6. If you have any outstanding [New + Noteworthy JIRAs|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JBIDE...] to do, please complete them next. > [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for arquillian task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23523) For JBIDE 4.4.2.Final: Prepare for 4.4.2.Final / 10.2.0.GA [forge]

by George Gastaldi (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23523?page=com.atlassian.jira.plugi... ] George Gastaldi closed JBIDE-23523. ----------------------------------- Assignee: Jeff MAURY Resolution: Done > For JBIDE 4.4.2.Final: Prepare for 4.4.2.Final / 10.2.0.GA [forge] > ------------------------------------------------------------------ > > Key: JBIDE-23523 > URL: https://issues.jboss.org/browse/JBIDE-23523 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: forge > Reporter: Friendly Jira Robot > Assignee: Jeff MAURY > Priority: Blocker > Labels: task > Fix For: 4.4.2.Final > > > For JBIDE 4.4.2.Final [forge]: Please perform the following tasks: 0. Make sure your component has no remaining unresolved JIRAs set for fixVersion = 4.4.2.Final or 10.2.0.GA [Unresolved JIRAs with fixVersion = 4.4.2.Final, 10.2.0.GA|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22J...] 1. Check out your existing *{color:orange}master{color}* branch: {code} git checkout master {code} 2. Update your *{color:orange}master branch{color}* root pom to use the latest parent pom version, *{color:orange}4.4.2.Final-SNAPSHOT{color}*: {code} <parent> <groupId>org.jboss.tools</groupId> <artifactId>parent</artifactId> <version>4.4.2.Final-SNAPSHOT</version> </parent> {code} Now, your root pom will use parent pom version: features plugins pom.xml pom.xml.orig README.md site tests *{color:orange}4.4.2.Final-SNAPSHOT{color}* in your *{color:orange}master{color}* branch 3. Branch from your existing master branch into a new *{color:blue}jbosstools-4.4.2.x{color}* branch: {code} git checkout master git pull origin master git checkout -b jbosstools-4.4.2.x git push origin jbosstools-4.4.2.x {code} Now, your root pom will use parent pom version: features plugins pom.xml pom.xml.orig README.md site tests *{color:blue}4.4.2.Final-SNAPSHOT{color}* in your *{color:blue}jbosstools-4.4.2.x{color}* branch, too. 4a. Ensure you've *built your code* using the latest *minimum* target platform version 4.60.2.Final {code} mvn clean verify -Dtpc.version=4.60.2.Final {code} 4b. Ensure you've *run your tests using the latest *maximum* target platform version 4.60.2.Final {code} mvn clean verify -Dtpc.version=4.60.2.Final {code} 5. Close (do not resolve) this JIRA when done. 6. If you have any outstanding [New + Noteworthy JIRAs|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JBIDE...] to do, please complete them next. > [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for forge task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 4 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-issues November 2016