[JBoss JIRA] (JBIDE-18454) Cant connect to OpenShift running on RHEL 6.6 (javax.net.ssl.SSLException: Could not generate DH keypair)
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18454?page=com.atlassian.jira.plugi... ]
Andre Dietisheim edited comment on JBIDE-18454 at 10/2/14 3:09 AM:
-------------------------------------------------------------------
[~maxandersen] I created OSJC-125 to fix the openshift-java-client. The PR for it (not merged yet: https://github.com/openshift/openshift-java-client/pull/159) shows the changes in code. And yes, I tested clonding, tail files, port forwarding etc. I suggest we test a manually built java client in the tooling before that merge.
was (Author: adietish):
[~maxandersen] I created OSJC-125 to fix the openshift-java-client. The PR for it (not merged yet) shows the changes in code. And yes, I tested clonding, tail files, port forwarding etc. I suggest we test a manually built java client in the tooling before that merge.
> Cant connect to OpenShift running on RHEL 6.6 (javax.net.ssl.SSLException: Could not generate DH keypair)
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18454
> URL: https://issues.jboss.org/browse/JBIDE-18454
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.0.CR1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Priority: Blocker
> Fix For: 4.2.0.CR2
>
> Attachments: ssl-error-on-connect.png
>
>
> In https://bugzilla.redhat.com/show_bug.cgi?id=1145848 openshift-java-client cant connect to OpenShift running on RHEL 6.6 when using jdks (openjdk and sun) < 1.8 on linux. We have to verify that this affects the Eclipse based tooling (that's also using openshift-java-client)
> {code}
> java.io.IOException: com.openshift.client.OpenShiftEndpointException: Could not request https://broker.ose21z-auto.com.cn/broker/rest/api: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
> at hudson.plugins.openshift.OpenShiftCloud.getOpenShiftConnection(OpenShiftCloud.java:186)
> at hudson.plugins.openshift.OpenShiftCloud.getSlaves(OpenShiftCloud.java:877)
> at hudson.plugins.openshift.OpenShiftCloud.provisionSlave(OpenShiftCloud.java:451)
> at hudson.plugins.openshift.OpenShiftCloud.provision(OpenShiftCloud.java:413)
> at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:281)
> at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:51)
> at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:368)
> at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: com.openshift.client.OpenShiftEndpointException: Could not request https://broker.ose21z-auto.com.cn/broker/rest/api: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-18483) For JBIDE 4.2.0.CR2: Prepare for CR2 release [LiveReload]
by Xavier Coulon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18483?page=com.atlassian.jira.plugi... ]
Xavier Coulon resolved JBIDE-18483.
-----------------------------------
Assignee: Xavier Coulon
Resolution: Rejected
No change since 4.2.0.CR1
> For JBIDE 4.2.0.CR2: Prepare for CR2 release [LiveReload]
> ---------------------------------------------------------
>
> Key: JBIDE-18483
> URL: https://issues.jboss.org/browse/JBIDE-18483
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: livereload
> Reporter: Nick Boldt
> Assignee: Xavier Coulon
> Priority: Blocker
> Labels: task
> Fix For: 4.2.0.CR2
>
>
> For JBIDE 4.2.0.CR2 [LiveReload]: Please perform the following tasks:
> 0. If nothing has changed in your component since JBT 4.2.0.CR1 or JBDS 8.0.0.CR1 (eg., XulRunner, Freemarker, BIRT), *{color:red}Reject this JIRA{color}*.
> Otherwise, for all other projects:
> 0. Make sure your component has no remaining unresolved JIRAs set for fixVersion = 4.2.0.CR2, 4.2.0.Final, 8.0.0.CR2 or 8.0.0.GA. Unresolved issues should be marked with a *respin-* label, unless they are issues which cannot be completed until closer to GA.
> [Unresolved JIRAs with fixVersion = 4.2.0.CR2, 4.2.0.Final, 8.0.0.CR2, 8.0.0.GA|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JB...]
> 1. In the *{color:blue}jbosstools-4.2.x{color}* branch, update your root pom to use parent pom version *{color:blue}4.2.0.CR2-SNAPSHOT{color}*
> {code}
> <parent>
> <groupId>org.jboss.tools</groupId>
> <artifactId>parent</artifactId>
> <version>4.2.0.CR2-SNAPSHOT</version>
> </parent>
> {code}
> 3. Ensure you've built & run your plugin tests using the latest target platform versions
> {code}
> mvn clean verify -Dtpc.version=4.40.0.CR2-SNAPSHOT
> mvn clean verify -Dtpc.version=4.41.0.CR2-SNAPSHOT
> {code}
> 5. If you did not already do so, *{color:orange}IN YOUR MASTER BRANCH{color}*:
> {code}
> git checkout master
> git pull origin master
> {code}
> 6. Update your *{color:orange}master branch{color}* parent pom to use the latest version, *{color:orange}4.3.0.Alpha1-SNAPSHOT{color}*:
> {code}
> <parent>
> <groupId>org.jboss.tools</groupId>
> <artifactId>parent</artifactId>
> <version>4.3.0.Alpha1-SNAPSHOT</version>
> </parent>
> {code}
> Now, your root pom will use parent pom version:
> * *{color:blue}4.2.0.CR2-SNAPSHOT{color}* in your *{color:blue}jbosstools-4.2.x{color}* branch, and
> * *{color:orange}4.3.0.Alpha1-SNAPSHOT{color}* in your *{color:orange}master{color}* branch.
> 4. Close (do not resolve) this JIRA when done.
> [Search for all task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...], or [Search for LiveReload task JIRA|https://issues.jboss.org/issues/?jql=%28%28project+in+%28JBDS%29+and...]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (TOOLSDOC-521) Review JIRA queries in Release Notes
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-521?page=com.atlassian.jira.plug... ]
Michelle Murray commented on TOOLSDOC-521:
------------------------------------------
[~mmalina], for GA I propose [1]:
Resolved:
(project in (JBDS) AND affectedVersion < "8.0.0.Alpha1" AND fixVersion in ("8.0.0.Alpha1","8.0.0.Alpha2","8.0.0.Beta1","8.0.0.Beta2","8.0.0.Beta3","8.0.0.CR1","8.0.0.CR2","8.0.0.GA") AND fixVersion not in ("7.1.0.Beta1","7.1.0.CR1") OR project in (JBIDE) AND affectedVersion < "4.2.0.Alpha1" AND fixVersion in ("4.2.0.Alpha1","4.2.0.Alpha2","4.2.0.Beta1","4.2.0.Beta2","4.2.0.Beta3","4.2.0.CR1","4.2.0.CR2","4.2.0.Final") AND fixVersion not in ("4.1.0.CR1","4.1.1.Alpha1","4.1.1.Alpha2","4.1.1.Beta1","4.1.1.CR1","4.1.2.CR1")) AND type in (Bug) AND resolution in (Done)
Known:
(project in (JBDS) AND affectedVersion >= "7.0.0.GA" AND affectedVersion <= "8.0.0.GA" AND (resolution in (Unresolved) OR resolution in (Done) AND fixVersion > "8.0.0.GA") OR project in (JBIDE) AND affectedVersion >= "4.1.0.Final" AND affectedVersion <= "4.2.0.Final" AND (resolution in (Unresolved) OR resolution in (Done) AND fixVersion > "4.2.0.Final")) AND type in (Bug)
I believe these retrieve the desired bugs.
Now discuss!
[1] http://docbuilder.usersys.redhat.com/22666/
> Review JIRA queries in Release Notes
> ------------------------------------
>
> Key: TOOLSDOC-521
> URL: https://issues.jboss.org/browse/TOOLSDOC-521
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Task
> Components: Release Notes
> Affects Versions: 4.2.0.CR1
> Reporter: Martin Malina
> Assignee: Michelle Murray
> Fix For: 4.2.0.Final
>
>
> When reviewing RNs for JBDS 8.0.0.CR1, we came to the conclusion that the JIRA queries may need updating.
> For reference, here's is discussion between me and Michelle on the subject:
> {quote}
> 01:23 mmalina: mmurray: I have a question about RN - resolved issues: (project in (JBDS) AND affectedVersion < "8.0.0.CR1" AND fixVersion in ("8.0.0.CR1") OR project in (JBIDE) AND affectedVersion < "4.2.0.CR1" AND fixVersion in ("4.2.0.CR1")) AND type in (Bug) AND resolution in (Done)
> 01:24 mmalina: mmurray: why have the fixVersion there? any special reason?
> 01:24 mmalina: mmurray: because it's 130 issues vs. 200 without it
> 01:24 maxandersen: don't use the < > comparisons. they unforatunely dont work reliably ;/
> 01:26 mmalina: maxandersen: the problem here is there are many jiras without affectedVersion
> 01:26 mmalina: *the main problem
> 01:26 mmalina: + what you say
> 01:27 maxandersen: mmalina: ah yeah. historically affectedVersion is only rarely used.
> 01:27 maxandersen: mmalina: only when we got very scifci issues where its important.
> 01:30 mmalina: mmurray: my only guess why you have it there is that you wanted to avoid jiras found in CR1 and fixed in CR1 - the thinking being that these would be new in CR1 and not present previously, thus you shouldn't list them in "what's fixed since the previous release". but that reasoning doesn't really work - 90 % bugs found in CR1 were already there before previously ;) any other reason to have it there?
> {quote}
> Michelle wrote:
> {quote}
> The search query is a best effort.
> The affects version is as you said, to avoid picking up internally identified bugs from QE/team testing CR1respinA that were fixed in CR1respinB, say. The customer doesn't need to know or care about these.
> The fixed version is a bit more complicated. The problem is that this query goes into the doc and the search results effectively have to remain static for all time - the doc could be hosted for years to come. This CR1 RNs doc should only list the bugs fixed in the CR1 release. If I leave the fixversion out then when bugs identified in <8.0.0.CR1 get resolved for CR2 or GA or even 9.1.0 they will show up in this query and that screws up the doc. The CR1 RNs doc we get replaced with a GA version so it isn't so important for this one but it is for the GA copy and it's easier to keep basically the same query as I iterate the doc towards GA.
> Regards using < and >, they are working effectively from what I can see. To make the comparisons work it just needs the versions to be listed in chronological order on the JBIDE and JBDS jira project pages.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (TOOLSDOC-521) Review JIRA queries in Release Notes
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-521?page=com.atlassian.jira.plug... ]
Michelle Murray updated TOOLSDOC-521:
-------------------------------------
Sprint: 2014/S18 (29-Sep > 12-Oct)
> Review JIRA queries in Release Notes
> ------------------------------------
>
> Key: TOOLSDOC-521
> URL: https://issues.jboss.org/browse/TOOLSDOC-521
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Task
> Components: Release Notes
> Affects Versions: 4.2.0.CR1
> Reporter: Martin Malina
> Assignee: Michelle Murray
> Fix For: 4.2.0.Final
>
>
> When reviewing RNs for JBDS 8.0.0.CR1, we came to the conclusion that the JIRA queries may need updating.
> For reference, here's is discussion between me and Michelle on the subject:
> {quote}
> 01:23 mmalina: mmurray: I have a question about RN - resolved issues: (project in (JBDS) AND affectedVersion < "8.0.0.CR1" AND fixVersion in ("8.0.0.CR1") OR project in (JBIDE) AND affectedVersion < "4.2.0.CR1" AND fixVersion in ("4.2.0.CR1")) AND type in (Bug) AND resolution in (Done)
> 01:24 mmalina: mmurray: why have the fixVersion there? any special reason?
> 01:24 mmalina: mmurray: because it's 130 issues vs. 200 without it
> 01:24 maxandersen: don't use the < > comparisons. they unforatunely dont work reliably ;/
> 01:26 mmalina: maxandersen: the problem here is there are many jiras without affectedVersion
> 01:26 mmalina: *the main problem
> 01:26 mmalina: + what you say
> 01:27 maxandersen: mmalina: ah yeah. historically affectedVersion is only rarely used.
> 01:27 maxandersen: mmalina: only when we got very scifci issues where its important.
> 01:30 mmalina: mmurray: my only guess why you have it there is that you wanted to avoid jiras found in CR1 and fixed in CR1 - the thinking being that these would be new in CR1 and not present previously, thus you shouldn't list them in "what's fixed since the previous release". but that reasoning doesn't really work - 90 % bugs found in CR1 were already there before previously ;) any other reason to have it there?
> {quote}
> Michelle wrote:
> {quote}
> The search query is a best effort.
> The affects version is as you said, to avoid picking up internally identified bugs from QE/team testing CR1respinA that were fixed in CR1respinB, say. The customer doesn't need to know or care about these.
> The fixed version is a bit more complicated. The problem is that this query goes into the doc and the search results effectively have to remain static for all time - the doc could be hosted for years to come. This CR1 RNs doc should only list the bugs fixed in the CR1 release. If I leave the fixversion out then when bugs identified in <8.0.0.CR1 get resolved for CR2 or GA or even 9.1.0 they will show up in this query and that screws up the doc. The CR1 RNs doc we get replaced with a GA version so it isn't so important for this one but it is for the GA copy and it's easier to keep basically the same query as I iterate the doc towards GA.
> Regards using < and >, they are working effectively from what I can see. To make the comparisons work it just needs the versions to be listed in chronological order on the JBIDE and JBDS jira project pages.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-14001) First restart of JBDS/App Server results in deployed archive being deleted from deploy directory.
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14001?page=com.atlassian.jira.plugi... ]
Martin Malina commented on JBIDE-14001:
---------------------------------------
It looks good to me. Let's wait for Rob to confirm.
> First restart of JBDS/App Server results in deployed archive being deleted from deploy directory.
> -------------------------------------------------------------------------------------------------
>
> Key: JBIDE-14001
> URL: https://issues.jboss.org/browse/JBIDE-14001
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.0.1.Final
> Environment: Windows 7
> Reporter: David Stephan
> Assignee: Rob Stryker
> Fix For: 4.2.0.CR2
>
>
> After Marking a jar as deployable and deploying to EAP server, the jar is deployed correctly.
> Then, after restarting JBDS, then restarting the app server from within JBDS, the deployed jar is deleted.
> After restarting the server again, the jar is deployed, and subsequent restarts don't remove the jar.
> Possibly related, when you first mark the jar as deployable and deploy to a server, the context menu item changes to "Unmark as Deployable." After a restart of JBDS, this context menu item is back to "Mark as Deployable".
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-14001) First restart of JBDS/App Server results in deployed archive being deleted from deploy directory.
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14001?page=com.atlassian.jira.plugi... ]
Michelle Murray commented on JBIDE-14001:
-----------------------------------------
[~mmalina], [~rob.stryker]: please verify the RN text.
> First restart of JBDS/App Server results in deployed archive being deleted from deploy directory.
> -------------------------------------------------------------------------------------------------
>
> Key: JBIDE-14001
> URL: https://issues.jboss.org/browse/JBIDE-14001
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.0.1.Final
> Environment: Windows 7
> Reporter: David Stephan
> Assignee: Rob Stryker
> Fix For: 4.2.0.CR2
>
>
> After Marking a jar as deployable and deploying to EAP server, the jar is deployed correctly.
> Then, after restarting JBDS, then restarting the app server from within JBDS, the deployed jar is deleted.
> After restarting the server again, the jar is deployed, and subsequent restarts don't remove the jar.
> Possibly related, when you first mark the jar as deployable and deploy to a server, the context menu item changes to "Unmark as Deployable." After a restart of JBDS, this context menu item is back to "Mark as Deployable".
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-14001) First restart of JBDS/App Server results in deployed archive being deleted from deploy directory.
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14001?page=com.atlassian.jira.plugi... ]
Michelle Murray updated JBIDE-14001:
------------------------------------
Release Notes Docs Status: Documented as Resolved Issue
Release Notes Text: On the first IDE and server restart or the first workspace and server restart after marking a new file as deployable, the file was no longer deployed. At the session restart, there was no check to ensure the deployed file IDs matched those in the previous session. This issue has been resolved by ensuring that the file is properly found during the next session and now marking a new file as deployable persists from one session to the next.
> First restart of JBDS/App Server results in deployed archive being deleted from deploy directory.
> -------------------------------------------------------------------------------------------------
>
> Key: JBIDE-14001
> URL: https://issues.jboss.org/browse/JBIDE-14001
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: server
> Affects Versions: 4.0.1.Final
> Environment: Windows 7
> Reporter: David Stephan
> Assignee: Rob Stryker
> Fix For: 4.2.0.CR2
>
>
> After Marking a jar as deployable and deploying to EAP server, the jar is deployed correctly.
> Then, after restarting JBDS, then restarting the app server from within JBDS, the deployed jar is deleted.
> After restarting the server again, the jar is deployed, and subsequent restarts don't remove the jar.
> Possibly related, when you first mark the jar as deployable and deploy to a server, the context menu item changes to "Unmark as Deployable." After a restart of JBDS, this context menu item is back to "Mark as Deployable".
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-18454) Cant connect to OpenShift running on RHEL 6.6 (javax.net.ssl.SSLException: Could not generate DH keypair)
by Marián Labuda (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18454?page=com.atlassian.jira.plugi... ]
Marián Labuda commented on JBIDE-18454:
---------------------------------------
It's in Andre's repo of openshift-java-client in branch OSJC-125. Other questions will be answered by Andre.
> Cant connect to OpenShift running on RHEL 6.6 (javax.net.ssl.SSLException: Could not generate DH keypair)
> ---------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-18454
> URL: https://issues.jboss.org/browse/JBIDE-18454
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: openshift
> Affects Versions: 4.2.0.CR1
> Reporter: Andre Dietisheim
> Assignee: Andre Dietisheim
> Priority: Blocker
> Fix For: 4.2.0.CR2
>
> Attachments: ssl-error-on-connect.png
>
>
> In https://bugzilla.redhat.com/show_bug.cgi?id=1145848 openshift-java-client cant connect to OpenShift running on RHEL 6.6 when using jdks (openjdk and sun) < 1.8 on linux. We have to verify that this affects the Eclipse based tooling (that's also using openshift-java-client)
> {code}
> java.io.IOException: com.openshift.client.OpenShiftEndpointException: Could not request https://broker.ose21z-auto.com.cn/broker/rest/api: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
> at hudson.plugins.openshift.OpenShiftCloud.getOpenShiftConnection(OpenShiftCloud.java:186)
> at hudson.plugins.openshift.OpenShiftCloud.getSlaves(OpenShiftCloud.java:877)
> at hudson.plugins.openshift.OpenShiftCloud.provisionSlave(OpenShiftCloud.java:451)
> at hudson.plugins.openshift.OpenShiftCloud.provision(OpenShiftCloud.java:413)
> at hudson.slaves.NodeProvisioner.update(NodeProvisioner.java:281)
> at hudson.slaves.NodeProvisioner.access$000(NodeProvisioner.java:51)
> at hudson.slaves.NodeProvisioner$NodeProvisionerInvoker.doRun(NodeProvisioner.java:368)
> at hudson.triggers.SafeTimerTask.run(SafeTimerTask.java:54)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: com.openshift.client.OpenShiftEndpointException: Could not request https://broker.ose21z-auto.com.cn/broker/rest/api: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (TOOLSDOC-537) IDE How To: Upgrade JBDS
by Michelle Murray (JIRA)
Michelle Murray created TOOLSDOC-537:
----------------------------------------
Summary: IDE How To: Upgrade JBDS
Key: TOOLSDOC-537
URL: https://issues.jboss.org/browse/TOOLSDOC-537
Project: Documentation for JBoss Tools and Developer Studio
Issue Type: Task
Components: Installation Guide
Reporter: Michelle Murray
Assignee: Michelle Murray
Fix For: 4.2.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 6 months
[JBoss JIRA] (JBIDE-18479) For JBIDE 4.2.0.CR2: Prepare for CR2 release [Arquillian]
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18479?page=com.atlassian.jira.plugi... ]
Snjezana Peco closed JBIDE-18479.
---------------------------------
Resolution: Done
> For JBIDE 4.2.0.CR2: Prepare for CR2 release [Arquillian]
> ---------------------------------------------------------
>
> Key: JBIDE-18479
> URL: https://issues.jboss.org/browse/JBIDE-18479
> Project: Tools (JBoss Tools)
> Issue Type: Sub-task
> Components: testing-tools
> Reporter: Nick Boldt
> Assignee: Snjezana Peco
> Priority: Blocker
> Labels: task
> Fix For: 4.2.0.CR2
>
>
> For JBIDE 4.2.0.CR2 [Arquillian]: Please perform the following tasks:
> 0. If nothing has changed in your component since JBT 4.2.0.CR1 or JBDS 8.0.0.CR1 (eg., XulRunner, Freemarker, BIRT), *{color:red}Reject this JIRA{color}*.
> Otherwise, for all other projects:
> 0. Make sure your component has no remaining unresolved JIRAs set for fixVersion = 4.2.0.CR2, 4.2.0.Final, 8.0.0.CR2 or 8.0.0.GA. Unresolved issues should be marked with a *respin-* label, unless they are issues which cannot be completed until closer to GA.
> [Unresolved JIRAs with fixVersion = 4.2.0.CR2, 4.2.0.Final, 8.0.0.CR2, 8.0.0.GA|https://issues.jboss.org/issues/?jql=%28%28project%20%3D%20%22JB...]
> 1. In the *{color:blue}jbosstools-4.2.x{color}* branch, update your root pom to use parent pom version *{color:blue}4.2.0.CR2-SNAPSHOT{color}*
> {code}
> <parent>
> <groupId>org.jboss.tools</groupId>
> <artifactId>parent</artifactId>
> <version>4.2.0.CR2-SNAPSHOT</version>
> </parent>
> {code}
> 3. Ensure you've built & run your plugin tests using the latest target platform versions
> {code}
> mvn clean verify -Dtpc.version=4.40.0.CR2-SNAPSHOT
> mvn clean verify -Dtpc.version=4.41.0.CR2-SNAPSHOT
> {code}
> 5. If you did not already do so, *{color:orange}IN YOUR MASTER BRANCH{color}*:
> {code}
> git checkout master
> git pull origin master
> {code}
> 6. Update your *{color:orange}master branch{color}* parent pom to use the latest version, *{color:orange}4.3.0.Alpha1-SNAPSHOT{color}*:
> {code}
> <parent>
> <groupId>org.jboss.tools</groupId>
> <artifactId>parent</artifactId>
> <version>4.3.0.Alpha1-SNAPSHOT</version>
> </parent>
> {code}
> Now, your root pom will use parent pom version:
> * *{color:blue}4.2.0.CR2-SNAPSHOT{color}* in your *{color:blue}jbosstools-4.2.x{color}* branch, and
> * *{color:orange}4.3.0.Alpha1-SNAPSHOT{color}* in your *{color:orange}master{color}* branch.
> 4. Close (do not resolve) this JIRA when done.
> [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
(v6.3.1#6329)
11 years, 6 months