November 2015 - jbosstools-issues

[JBoss JIRA] (JBIDE-18876) Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18876?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-18876: ---------------------------------------- I don't think we update the TP that often to make such a change that valuable. Also, the suggested approach has risk of making some build working while the new TP would make them fail. In case of TP incompatibility with component build, the effect is mainly that it makes the feedback loop longer; and that is the opposite purpose of continuous integration and agility. Sometimes, trying to make things work is a quality anti-pattern, the goal of CI is more to make things fail ASAP whenever they have to. > Improve TP publishing so changes released to git or deployed to nexus would not break developer local builds > ------------------------------------------------------------------------------------------------------------ > > Key: JBIDE-18876 > URL: https://issues.jboss.org/browse/JBIDE-18876 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Alpha1 > Reporter: Denis Golovin > Assignee: Denis Golovin > Fix For: 4.4.0.Alpha1 > > > Latest Thym update is 'good' example for this problem. I was in the middle of testing some changes in parent/pom.xml and suddenly build start to fail with Thym resolution problem. IMO what happened is TP .target files were published to nexus before actual p2-repos appeared online. Building from latest revision didn't help ether because of the same problem. I had to revert to previous revision to continue my task. > So it would be good if TP builds publish binaries first and then release TP sources to git and deploy to nexus. > Please note, that when sftp/rsync for unified TP binaries is finished it doesn't mean p2-repos are available from download.jboss.org right away. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21012) Why do we deploy JBT components to Nexus snapshots repo?

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-21012: --------------------------------------------- So I must be missing something here. As far as I read the publishing to nexus actually found a valid issue (bad versioning), did not have a big overhead and now we decided to disable it. Is that the right conclusion ? Did we at least ensure we don't loose the feature of detecting bad versioning ? > Why do we deploy JBT components to Nexus snapshots repo? > -------------------------------------------------------- > > Key: JBIDE-21012 > URL: https://issues.jboss.org/browse/JBIDE-21012 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Final, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Currently, we deploy our x.y.z-SNAPSHOT update sites to the JBoss Nexus snapshots repo. > But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just: > * eat disk space in Nexus > * consume time/resources in Jenkins > Since we have the custom profile deploy-to-jboss.org in place for all our artifacts, why don't we set *maven.deploy.skip=true* in the parent pom for all the projects (except of course Locus and Browsersim Standalone, which would use maven.deploy.skip=false) ? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21059) Server Adapter does not connect in debug mode on WF in a Docker container

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21059?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-21059: --------------------------------------------- Yes, the lack of easy debug support for remote servers whether external managed or not is the issue. Externally Managed is the one that are the most critical one at the moment. > Server Adapter does not connect in debug mode on WF in a Docker container > -------------------------------------------------------------------------- > > Key: JBIDE-21059 > URL: https://issues.jboss.org/browse/JBIDE-21059 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: server > Affects Versions: 4.3.0.Final > Reporter: Xavier Coulon > > I have a WF 9.0.2.Final in a Docker container, started with the debug flag in the command line : > {code} > CMD ["/opt/jboss/wildfly/bin/standalone.sh", "-c", "standalone.xml", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0" , "--debug"] > {code} > I can connect to this server from the server adapter in Run mode but not in debug mode: the Debug view remains empty and the breakpoints are not hit. > On the other side, I can connect using the plain Java remote debugger (in the launchers) and the same breakpoints are hit. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20990) Add "CDK Server" for start/stop for the CDK

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20990?page=com.atlassian.jira.plugi... ] Max Rydahl Andersen commented on JBIDE-20990: --------------------------------------------- [~rob.stryker] any ETA on a PR for this so we can get it included into builds ? > Add "CDK Server" for start/stop for the CDK > ------------------------------------------- > > Key: JBIDE-20990 > URL: https://issues.jboss.org/browse/JBIDE-20990 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: server > Reporter: Max Rydahl Andersen > Assignee: Rob Stryker > Fix For: 4.4.0.Alpha1 > > > We want to be able to start/stop CDK easily. > Current suggestion is to use a server entry in server view that can start/stop vagrant by simply knowing its file location would be a good start. > note: the vagrant image might already be running so just need to be able to take care of that. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-267) Performance and memory issues in Switchyard projects using Maven.

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBTIS-267?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBTIS-267: ------------------------------------------- for what it is worth - JBDS 9 contains the updated m2e thus the fix is available to users there. > Performance and memory issues in Switchyard projects using Maven. > ----------------------------------------------------------------- > > Key: JBTIS-267 > URL: https://issues.jboss.org/browse/JBTIS-267 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: switchyard > Affects Versions: 7.0.1.GA > Reporter: Mustafa Musaji > Assignee: Brian Fitzpatrick > Attachments: log > > > Hitting memory issues when opening a workspace with a number of SY projects using Maven. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21120) Why do we deploy TP zips to Nexus snapshots repo?

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21120?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-21120: ---------------------------------------- Right, I believe there is no value in deploying them, so we can skip their deployment (unless it requires strange hacks). We could imagine simply deploying to Nexus using the repositories deployed at Nexus, like we do for Locus. However, the performance of Nexus make it not suitable for delivery compared to Akamai, so let's drop this idea for now. > Why do we deploy TP zips to Nexus snapshots repo? > ------------------------------------------------- > > Key: JBIDE-21120 > URL: https://issues.jboss.org/browse/JBIDE-21120 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build, updatesite > Affects Versions: 4.3.0.Final, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Currently, we deploy our TP update sites to the JBoss Nexus snapshots repo. > {code} > Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... > Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... > Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... > Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... > Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... > Uploading: https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... > ... > {code} > But other than Locus and the Browsersim Standalone zip, we don't ever use these artifacts, so they just: > * eat disk space in Nexus > * consume time/resources in Jenkins > So, why don't we set a custome deployment strategy (eg., akin to *maven.deploy.skip=true*) in the jbosstools-targetplatform & jbosstools-discovery root pom to prevent this waste of time/space? Then we can just deploy the .target files, not the zips. > This would certainly speed up builds, which currently take 30-60 mins per TP build. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21122) Start All button should be disabled if port forwarding is already active

by Marián Labuda (JIRA)

Marián Labuda created JBIDE-21122: ------------------------------------- Summary: Start All button should be disabled if port forwarding is already active Key: JBIDE-21122 URL: https://issues.jboss.org/browse/JBIDE-21122 Project: Tools (JBoss Tools) Issue Type: Bug Components: openshift Affects Versions: 4.3.1.Beta1 Reporter: Marián Labuda In Port Forwarding wizard is a button "Start All" which starts port forwarding for all services listed in a table. If user triggers the button and port forwarding is already active, Start All is still enabled and user can click on it again and again but nothing happens. Accessibility of this button should be similar as Stop All, which works as expected - if port forwarding is not active, it is disabled, otherwise it is enabled. There is also a checkbox to find free ports for port forwarding. Once port forwarding is active, checking and unchecking this checkbox do nothing. It should have same accessibility as Start All button - if there is active port forwarding, the checkbox should be disabled, otherwise it should be enabled. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3276) JBDS-IS Installer support

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3276?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-3276: ------------------------------------------- 1) if users overall feedback it does not change much I would say it is not worth the extra hassle. And i'm happy to see their main issue is about quickstarts and general getting started experience which is exactly what I find problematic too - easy install does not help much if the overall getting started experience is not cleaned up/smooth. I would suggest work on that instead of adding more overhead to test. 2) installer = no early access installed by default - not unless IS are okey with same happening when using eclipse marketplace and our udpatesite in general...which in short would mean notion of earlyaccess would need to dissapear. note - this is really no different than from how eclipse marketplace is restricted to contain non-earlyaccess by default. > JBDS-IS Installer support > ------------------------- > > Key: JBDS-3276 > URL: https://issues.jboss.org/browse/JBDS-3276 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Feature Request > Components: installer, integration-platform, requirements > Affects Versions: 8.0.0.GA > Reporter: Burr Sutter > Assignee: Paul Leacu > Fix For: 9.1.0.Beta1 > > Attachments: Red Hat JBoss Developer Studio 9.0.0.Alpha2_105.png, EA.png, jbds-is-about.png, JBDSIS_installer_9.png, JBDSIS_installer_space.png, mirroringlog.txt, sai1.png > > > As a Fuse, integration-focused developer, I need a downloadable installer that will allow me to quickly and easily install JBDS with Fuse capabilities. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3562) Prepare for 9.0.1 / 9.1.0

by Max Rydahl Andersen (JIRA)

[ https://issues.jboss.org/browse/JBDS-3562?page=com.atlassian.jira.plugin.... ] Max Rydahl Andersen commented on JBDS-3562: ------------------------------------------- afaik requirement for 9.0.1 is primarily to include updated EAP, eclipse plugins aren't known to be vulnerable and if we need a release it won't be enough to just update our TP. Eclipse.org plugins need released too. > Prepare for 9.0.1 / 9.1.0 > -------------------------- > > Key: JBDS-3562 > URL: https://issues.jboss.org/browse/JBDS-3562 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 9.0.1.GA > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 9.0.1.GA > > > Tracker JIRA to house things to do to prepare for 9.0.1 / 9.1.0 branches & builds. > Because JBDS 9.0.0 includes the compromised version of > apache.commons.collections (JBDS-3560, JBDS-3561), we need to at some point respin it, which > will include: > a) updated JBT/JBDS target platforms 4.50.1.* and 4.51.1.* > b) repin of JBDS update sites and installer jars > To that end, I've created the following new branches: > https://github.com/jbosstools/jbosstools-target-platforms/commits/4.50.1.x > https://github.com/jbosstools/jbosstools-target-platforms/commits/4.51.1.x > And I've bumped the version of the target platforms in the 4.50.x and > 4.51.x branches to 4.50.2.Beta1-SNAPSHOT and 4.51.2.Beta1-SNAPSHOT, > respectively. > JBDS is now at version 9.1.0 in the 4.3.x branch and 9.0.1 in the > 4.3.1.x branch. > https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3... > (new, 9.0.1) > https://github.com/jbdevstudio/jbdevstudio-product/commits/jbosstools-4.3.x > (updated to 9.1.0) > So, now we just need to ensure that the correct BUILD_ALIAS (CR1 for > 9.0.1, Beta1 for 9.1.0) and target platforms are used. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21121) Warning/error dialog should pop up if there is no oc binary when opening Port forwarding dialog

by Marián Labuda (JIRA)

Marián Labuda created JBIDE-21121: ------------------------------------- Summary: Warning/error dialog should pop up if there is no oc binary when opening Port forwarding dialog Key: JBIDE-21121 URL: https://issues.jboss.org/browse/JBIDE-21121 Project: Tools (JBoss Tools) Issue Type: Enhancement Components: openshift Affects Versions: 4.3.1.Beta1 Reporter: Marián Labuda Priority: Minor OpenShift 3 port forwarding features requires 'oc' binary to be set up in tooling. It's done in Workbench preference dialog on page OpenShift 3. If there is no 'oc' binary set and user invokes a port forwarding dialog, it is opened and even Start All button is enabled. User finds out that it is not possible to perform only when he gets an error message upon clicking on Start All button describing the problem. There could be some warning/error dialog popped up before opening a port forwarding dialog if there is no 'oc' location set in preferences. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 2015