[JBoss JIRA] (JBDS-4257) rh-eclipse46-devstudio provides packages that are dependencies of rh-eclipse46
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4257?page=com.atlassian.jira.plugin.... ]
Nick Boldt updated JBDS-4257:
-----------------------------
Fix Version/s: 11.0.0.GA
(was: 11.x)
> rh-eclipse46-devstudio provides packages that are dependencies of rh-eclipse46
> ------------------------------------------------------------------------------
>
> Key: JBDS-4257
> URL: https://issues.jboss.org/browse/JBDS-4257
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, rpm
> Affects Versions: 10.3.0.AM2
> Environment: RHEL7
> Reporter: Lukáš Valach
> Assignee: Nick Boldt
> Fix For: 11.0.0.GA
>
> Attachments: rh-eclipse46-devstudio_provides.txt, rh-eclipse46_provides.txt, yum_install_rh-eclipse46.png
>
>
> I noticed rh-eclipse46-devstudio is installed as dependenci when installing rh-eclipse46.
> !yum_install_rh-eclipse46.png|thumbnail!
> [~vkadlcik] said that it is because rh-eclipse46-devstudio offers some package which rh-eclipse46 needs, so yum decides to use devstudio as library.
> He said that the best practice for end-user application like rh-eclipse46-devstudio is to have less amount of stuff in "rpm -q --provides". Rh-eclipse46 provides 4 packages, devstudio provides 539 packages.
> [^rh-eclipse46_provides.txt]
> [^rh-eclipse46-devstudio_provides.txt]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBDS-4257) rh-eclipse46-devstudio provides packages that are dependencies of rh-eclipse46
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBDS-4257?page=com.atlassian.jira.plugin.... ]
Nick Boldt commented on JBDS-4257:
----------------------------------
So you're suggesting that the rh-eclipse47-devstudio rpm should depend on smaller packages than rh-eclipse47-base, such as eclipse-platform, eclipse-pde, eclipse-jdt, felix-scr and osgi?
https://github.com/jbdevstudio/jbdevstudio-product/blob/master/rpm/devstu...
Would that be better? If so, I'm happy to make that change.
> rh-eclipse46-devstudio provides packages that are dependencies of rh-eclipse46
> ------------------------------------------------------------------------------
>
> Key: JBDS-4257
> URL: https://issues.jboss.org/browse/JBDS-4257
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Components: build, rpm
> Affects Versions: 10.3.0.AM2
> Environment: RHEL7
> Reporter: Lukáš Valach
> Assignee: Nick Boldt
> Priority: Minor
> Fix For: 11.x
>
> Attachments: rh-eclipse46-devstudio_provides.txt, rh-eclipse46_provides.txt, yum_install_rh-eclipse46.png
>
>
> I noticed rh-eclipse46-devstudio is installed as dependenci when installing rh-eclipse46.
> !yum_install_rh-eclipse46.png|thumbnail!
> [~vkadlcik] said that it is because rh-eclipse46-devstudio offers some package which rh-eclipse46 needs, so yum decides to use devstudio as library.
> He said that the best practice for end-user application like rh-eclipse46-devstudio is to have less amount of stuff in "rpm -q --provides". Rh-eclipse46 provides 4 packages, devstudio provides 539 packages.
> [^rh-eclipse46_provides.txt]
> [^rh-eclipse46-devstudio_provides.txt]
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-23013) Pull Docker Tooling bits into JBT builds more frequently
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23013?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-23013:
------------------------------------
[~jjohnstn] [~mmalina] is this something you still want? If not I'd like to close this as "no longer a requirement / won't fix".
> Pull Docker Tooling bits into JBT builds more frequently
> --------------------------------------------------------
>
> Key: JBIDE-23013
> URL: https://issues.jboss.org/browse/JBIDE-23013
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build, target-platform
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Jeff Johnston
> Fix For: LATER
>
>
> It would be cool if we could update the Docker Tooling bits in our TP more frequently, i.e. weekly or even nightly. I know that currently it is quite a big effort to update TP. So we would need to simplify this somehow.
> So this is a suggestion, but I don't know how we would do it or if it's doable at all.
> Here's a bit of background:
> Today I spotted this blocking bug in docker tooling:
> https://issues.jboss.org/browse/JBIDE-23011
> It was probably brought into JBT TP in the last update of the TP - this JIRA:
> https://issues.jboss.org/browse/JBIDE-22885 - 4 days ago.
> Jeff Maury suggested, that it's a bad idea to update our TP this close to our release (AM3 in this case). But currently we don't have any other option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-23013) Pull Docker Tooling bits into JBT builds more frequently
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23013?page=com.atlassian.jira.plugi... ]
Nick Boldt reassigned JBIDE-23013:
----------------------------------
Assignee: Jeff Johnston (was: Nick Boldt)
> Pull Docker Tooling bits into JBT builds more frequently
> --------------------------------------------------------
>
> Key: JBIDE-23013
> URL: https://issues.jboss.org/browse/JBIDE-23013
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build, target-platform
> Affects Versions: 4.4.1.AM3
> Reporter: Martin Malina
> Assignee: Jeff Johnston
> Fix For: LATER
>
>
> It would be cool if we could update the Docker Tooling bits in our TP more frequently, i.e. weekly or even nightly. I know that currently it is quite a big effort to update TP. So we would need to simplify this somehow.
> So this is a suggestion, but I don't know how we would do it or if it's doable at all.
> Here's a bit of background:
> Today I spotted this blocking bug in docker tooling:
> https://issues.jboss.org/browse/JBIDE-23011
> It was probably brought into JBT TP in the last update of the TP - this JIRA:
> https://issues.jboss.org/browse/JBIDE-22885 - 4 days ago.
> Jeff Maury suggested, that it's a bad idea to update our TP this close to our release (AM3 in this case). But currently we don't have any other option.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBDS-4476) Undeploy still failing with FUSE -> Karaf -> Camel
by Timo Riikonen (JIRA)
[ https://issues.jboss.org/browse/JBDS-4476?page=com.atlassian.jira.plugin.... ]
Timo Riikonen updated JBDS-4476:
--------------------------------
Workaround Description: osgi:uninstall <my project name>
Workaround: Workaround Exists
Forum Reference: https://issues.jboss.org/browse/FUSETOOLS-1822
> Undeploy still failing with FUSE -> Karaf -> Camel
> --------------------------------------------------
>
> Key: JBDS-4476
> URL: https://issues.jboss.org/browse/JBDS-4476
> Project: Red Hat JBoss Developer Studio (devstudio)
> Issue Type: Bug
> Affects Versions: 10.4.0.GA
> Environment: JBoss Fuse 6.3
> Reporter: Timo Riikonen
>
> 1) I deploy my application to Camel using Servers --> <my server> --> Add and Remove...
> 2) Check it with Camel UI
> 3) I undeploy it using the same Fuse UI
> 4) I see various results, even half of the application installed in Camel.
> 5) I give command osgi:uninstall <my project name>
> This takes long time: 30 - 100 seconds, but finishes eventually
> 6) Project successfully undeployed.
> I haven't found any error logs about this problem.
> I gave Major priority because this can be nasty when you are trying to deploy different version of the same application and you have no idea that the old version was running there still. If you succeed, you have randomly several versions running of the same application. If you fail to deploy the other version, you have the old version running instead. Very random behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBDS-4476) Undeploy still failing with FUSE -> Karaf -> Camel
by Timo Riikonen (JIRA)
Timo Riikonen created JBDS-4476:
-----------------------------------
Summary: Undeploy still failing with FUSE -> Karaf -> Camel
Key: JBDS-4476
URL: https://issues.jboss.org/browse/JBDS-4476
Project: Red Hat JBoss Developer Studio (devstudio)
Issue Type: Bug
Affects Versions: 10.4.0.GA
Environment: JBoss Fuse 6.3
Reporter: Timo Riikonen
1) I deploy my application to Camel using Servers --> <my server> --> Add and Remove...
2) Check it with Camel UI
3) I undeploy it using the same Fuse UI
4) I see various results, even half of the application installed in Camel.
5) I give command osgi:uninstall <my project name>
This takes long time: 30 - 100 seconds, but finishes eventually
6) Project successfully undeployed.
I haven't found any error logs about this problem.
I gave Major priority because this can be nasty when you are trying to deploy different version of the same application and you have no idea that the old version was running there still. If you succeed, you have randomly several versions running of the same application. If you fail to deploy the other version, you have the old version running instead. Very random behavior.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-22436) Intermittent NullPointerException upon opening helloworld, kitchensink cheat sheets in JBDS
by Michal Jurc (JIRA)
[ https://issues.jboss.org/browse/JBIDE-22436?page=com.atlassian.jira.plugi... ]
Michal Jurc commented on JBIDE-22436:
-------------------------------------
[~snjeza]: Still occurring with Fedora 26, JBDS 10.4.GA, Cinnamon, EAP7.1.0.ER2 Quickstarts.
> Intermittent NullPointerException upon opening helloworld, kitchensink cheat sheets in JBDS
> -------------------------------------------------------------------------------------------
>
> Key: JBIDE-22436
> URL: https://issues.jboss.org/browse/JBIDE-22436
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: project-examples, upstream
> Affects Versions: 4.3.1.Final
> Reporter: Michal Jurc
> Assignee: Snjezana Peco
> Fix For: 4.4.x
>
> Attachments: JBIDE-22436-10.0-helloworld.log, JBIDE-22436-9.1-helloworld.log, helloworld-cheatsheet.xml, jbds104-cheat-sheet-npe.log, kitchensink-cheatsheet.xml, org.jboss.tools.cheatsheet.test.zip
>
>
> After finishing the import of {{helloworld}} and {{kitchensink}} quickstarts, the user is prompted whether the cheat sheet for the project should be opened. Upon opening it, JBDS 9.0 and 9.1 produces the following error message:
> {quote}An error has occurred. See error log for more details.
> java.lang.NullPointerException{quote}
> The detailed error log produces the same message.
> The quickstarts and their cheat sheets work even after the prompt with NullPointerException message.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-24749) Rename cdk runtime detector to cdk 2
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24749?page=com.atlassian.jira.plugi... ]
Martin Malina updated JBIDE-24749:
----------------------------------
Attachment: runtime-detectors.png
> Rename cdk runtime detector to cdk 2
> ------------------------------------
>
> Key: JBIDE-24749
> URL: https://issues.jboss.org/browse/JBIDE-24749
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: runtime-detection
> Affects Versions: 4.5.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Attachments: runtime-detectors.png
>
>
> In JBIDE-24584 I requested that cdk server adapter be renamed to cdk 2 which is now done. But today I noticed that we missed the runtime detector:
> Go to Preferences -> JBoss Tools -> JBoss Runtime Detection
> On that page, there is a table called Available runtime detectors which, among others, includes:
> Container Development Environment 3
> Container Development Environment
> So the latter should be renamed to include "2" or "2.x" - probably the latter to be consistent with the server adapter name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-24749) Rename cdk runtime detector to cdk 2
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24749?page=com.atlassian.jira.plugi... ]
Martin Malina updated JBIDE-24749:
----------------------------------
Description:
In JBIDE-24584 I requested that cdk server adapter be renamed to cdk 2 which is now done. But today I noticed that we missed the runtime detector:
Go to Preferences -> JBoss Tools -> JBoss Runtime Detection
On that page, there is a table called Available runtime detectors which, among others, includes:
Container Development Environment 3
Container Development Environment
!runtime-detectors.png!
So the latter should be renamed to include "2" or "2.x" - probably the latter to be consistent with the server adapter name.
was:
In JBIDE-24584 I requested that cdk server adapter be renamed to cdk 2 which is now done. But today I noticed that we missed the runtime detector:
Go to Preferences -> JBoss Tools -> JBoss Runtime Detection
On that page, there is a table called Available runtime detectors which, among others, includes:
Container Development Environment 3
Container Development Environment
So the latter should be renamed to include "2" or "2.x" - probably the latter to be consistent with the server adapter name.
> Rename cdk runtime detector to cdk 2
> ------------------------------------
>
> Key: JBIDE-24749
> URL: https://issues.jboss.org/browse/JBIDE-24749
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: runtime-detection
> Affects Versions: 4.5.0.AM2
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Attachments: runtime-detectors.png
>
>
> In JBIDE-24584 I requested that cdk server adapter be renamed to cdk 2 which is now done. But today I noticed that we missed the runtime detector:
> Go to Preferences -> JBoss Tools -> JBoss Runtime Detection
> On that page, there is a table called Available runtime detectors which, among others, includes:
> Container Development Environment 3
> Container Development Environment
> !runtime-detectors.png!
> So the latter should be renamed to include "2" or "2.x" - probably the latter to be consistent with the server adapter name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-24594) $0 subscription download doesn't work - Read timed out
by Martin Malina (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24594?page=com.atlassian.jira.plugi... ]
Martin Malina resolved JBIDE-24594.
-----------------------------------
Fix Version/s: 4.5.0.AM2
Resolution: Cannot Reproduce Bug
Cannot reproduce any longer. Resolving.
> $0 subscription download doesn't work - Read timed out
> ------------------------------------------------------
>
> Key: JBIDE-24594
> URL: https://issues.jboss.org/browse/JBIDE-24594
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: runtime-detection
> Affects Versions: 4.5.0.AM1
> Reporter: Martin Malina
> Assignee: Rob Stryker
> Fix For: 4.5.0.AM2
>
>
> When I try to download EAP 7.0 using Preferences -> Runtime Detection and Download, I get an error when it validates my redhat.com credentials.
> {code}
> Read timed out
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:973)
> at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:930)
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at sun.net.www.http.HttpClient.parseHTTPHeader(HttpClient.java:735)
> at sun.net.www.http.HttpClient.parseHTTP(HttpClient.java:678)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1569)
> at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1474)
> at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
> at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
> at org.jboss.tools.runtime.ui.internal.wizard.workflow.DownloadManagerWorkflowUtility.headerOnlyStatusCode(DownloadManagerWorkflowUtility.java:65)
> at org.jboss.tools.runtime.ui.internal.wizard.workflow.DownloadManagerWorkflowUtility.getWorkflowStatus(DownloadManagerWorkflowUtility.java:47)
> at org.jboss.tools.runtime.ui.internal.wizard.workflow.DownloadManagerCredentialsFragment.validateCredentials(DownloadManagerCredentialsFragment.java:205)
> at org.jboss.tools.runtime.ui.internal.wizard.workflow.DownloadManagerCredentialsFragment.access$1(DownloadManagerCredentialsFragment.java:203)
> at org.jboss.tools.runtime.ui.internal.wizard.workflow.DownloadManagerCredentialsFragment$3.run(DownloadManagerCredentialsFragment.java:168)
> at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119)
> {code}
> What I did: I was trying to verify JBIDE-24582, so I installed Eclipse Oxygen. Then JBoss Tools abridged (4.5.0.AM1). And then built the PR from that JIRA and installed it. I doubt it could cause this. Then I went to Preferences -> Runtime Detection and Download, selected eap 7.0, then added my account, but selected "always ask for password". Then I entered password and clicked Next. Now it failed with the above error. I tried several times.
> I tried the same in devstudio 11.0.0.AM1 and it works fine for me there, so that's odd - I was suspecting some server-side outage. I tried again in Eclipse and it still fails.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months