May 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-22295) VariablesHelperTest failing under Windows

by Jeff MAURY (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22295?page=com.atlassian.jira.plugi... ] Jeff MAURY reassigned JBIDE-22295: ---------------------------------- Assignee: Jeff MAURY > VariablesHelperTest failing under Windows > ----------------------------------------- > > Key: JBIDE-22295 > URL: https://issues.jboss.org/browse/JBIDE-22295 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: openshift > Affects Versions: 4.4.0.Alpha1 > Reporter: Jeff MAURY > Assignee: Jeff MAURY > Fix For: 4.4.0.Alpha2 > > > Test testReplaceVariables is failing under Windows because of mismatch between platform path separators -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21861) Include Docker tooling 2.0.0 in JBT 4.4.x TP

by Alexey Kazakov (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21861?page=com.atlassian.jira.plugi... ] Alexey Kazakov commented on JBIDE-21861: ---------------------------------------- I would include vagrant tools in JBoss Tools TP. And I created a trello card regarding including vagrant tools in devstudio installation - https://trello.com/c/a661NfOB/135-devstudio-include-vagrant-tolling-to-de... [~tmancini] still waiting for your comment in trello or here :) > Include Docker tooling 2.0.0 in JBT 4.4.x TP > -------------------------------------------- > > Key: JBIDE-21861 > URL: https://issues.jboss.org/browse/JBIDE-21861 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: target-platform > Affects Versions: 4.3.1.Beta2 > Reporter: Xavier Coulon > Assignee: Nick Boldt > Fix For: 4.4.0.Alpha2 > > > Include Docker tooling 2.0.0 in Target Platform 4.60.x, targeting JBoss Tools 4.4.x -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21716) Don't re-prompt for password

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21716?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-21716: ------------------------------------- I pushed the change to read from env var instead. > Don't re-prompt for password > ---------------------------- > > Key: JBIDE-21716 > URL: https://issues.jboss.org/browse/JBIDE-21716 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: cdk > Reporter: Pete Muir > Assignee: Rob Stryker > Fix For: 4.4.0.Alpha2 > > > Having installed JBDS and CDK from the installer, and entered your password there, you get re-prompted for your password for the customer portal. This is a poor user experience. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20337) Add unit tests for exploded utility projects

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20337?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-20337: ------------------------------------- In case anyone's spying: * * ce964c7 - (HEAD, origin/master, origin/HEAD, mine/JBIDE-22157, master, JBIDE-22157) JBIDE-22157 - per-module zip settings (23 hours ago, Rob Stryker) > Add unit tests for exploded utility projects > -------------------------------------------- > > Key: JBIDE-20337 > URL: https://issues.jboss.org/browse/JBIDE-20337 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: server > Affects Versions: 4.3.0.CR1 > Reporter: Rob Stryker > Assignee: Rob Stryker > Priority: Critical > Fix For: 4.4.0.Alpha2 > > > Add unit tests for the logic change in JBIDE-15250 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20337) Add unit tests for exploded utility projects

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20337?page=com.atlassian.jira.plugi... ] Rob Stryker resolved JBIDE-20337. --------------------------------- Resolution: Done this was pushed yesterday. > Add unit tests for exploded utility projects > -------------------------------------------- > > Key: JBIDE-20337 > URL: https://issues.jboss.org/browse/JBIDE-20337 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: server > Affects Versions: 4.3.0.CR1 > Reporter: Rob Stryker > Assignee: Rob Stryker > Priority: Critical > Fix For: 4.4.0.Alpha2 > > > Add unit tests for the logic change in JBIDE-15250 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21716) Don't re-prompt for password

by Rob Stryker (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21716?page=com.atlassian.jira.plugi... ] Rob Stryker commented on JBIDE-21716: ------------------------------------- [~dgolovin] should be fine. Go ahead and make the change for env var instead. Use same key. > Don't re-prompt for password > ---------------------------- > > Key: JBIDE-21716 > URL: https://issues.jboss.org/browse/JBIDE-21716 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: cdk > Reporter: Pete Muir > Assignee: Rob Stryker > Fix For: 4.4.0.Alpha2 > > > Having installed JBDS and CDK from the installer, and entered your password there, you get re-prompted for your password for the customer portal. This is a poor user experience. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21716) Don't re-prompt for password

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21716?page=com.atlassian.jira.plugi... ] Denis Golovin commented on JBIDE-21716: --------------------------------------- [~rob.stryker] there is a little problem with java system properties, it is not easy to pass to eclipse and merge with other ones configured in jbdevstudio.ini file. If I use {noformat}jbdevstudio.exe -vmargs -Dprop=value{noformat} It overrides -vmargs arguments form jbdevstudio.ini. if I use {noformat}--launcher.appendVmargs -Dprop=value{noformat} It doesn't work. Could we use env variable instead? it is mush easier to configure for devstudio start form platform installer and easy to get value from Runtime at java side. > Don't re-prompt for password > ---------------------------- > > Key: JBIDE-21716 > URL: https://issues.jboss.org/browse/JBIDE-21716 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: cdk > Reporter: Pete Muir > Assignee: Rob Stryker > Fix For: 4.4.0.Alpha2 > > > Having installed JBDS and CDK from the installer, and entered your password there, you get re-prompted for your password for the customer portal. This is a poor user experience. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21066) update tm.terminal in JBT/JBDS target platforms (was Extra step in opening terminal in git perspective?)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21066?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-21066: ------------------------------------ Mirror: http://download.jboss.org/jbosstools/updates/requirements/tm/4.1.0.201603... > update tm.terminal in JBT/JBDS target platforms (was Extra step in opening terminal in git perspective?) > -------------------------------------------------------------------------------------------------------- > > Key: JBIDE-21066 > URL: https://issues.jboss.org/browse/JBIDE-21066 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: target-platform, upstream > Affects Versions: 4.3.0.Final > Reporter: Len DiMaggio > Assignee: Nick Boldt > Fix For: 4.4.0.Alpha2 > > Attachments: terminal.png, Terminal.webm, tm.term.view.png > > > If a user opens a terminal view from the git perspective - for example, by performing "show in" for a local repo, an empty terminal view is displayed. The user must then click on the terminal icon to actually open the terminal. This seems like an extra step - why wouldn't we open a terminal when we open the terminal view? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21861) Include Docker tooling 2.0.0 in JBT 4.4.x TP

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21861?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-21861: ------------------------------------ Mirror: http://download.jboss.org/jbosstools/updates/requirements/docker/2.0.0.20... > Include Docker tooling 2.0.0 in JBT 4.4.x TP > -------------------------------------------- > > Key: JBIDE-21861 > URL: https://issues.jboss.org/browse/JBIDE-21861 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: target-platform > Affects Versions: 4.3.1.Beta2 > Reporter: Xavier Coulon > Assignee: Nick Boldt > Fix For: 4.4.0.Alpha2 > > > Include Docker tooling 2.0.0 in Target Platform 4.60.x, targeting JBoss Tools 4.4.x -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22305) automate process for fetching latest target platform mirrors

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22305?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22305: ------------------------------- Description: Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names. Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace. Thus for webtools we might simply define: webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do... and we'd end up with: http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8.... * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p... 2. when all children are done, a downstream job can runs TP update & validation against new .target files * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf... * parse that into a list of URLs * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files * run p2diff between old/new URLs in .target to generate list of changes and verify new site contains all the same IUs * resulting edited .target files will remain in the workspace, and we can then run * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u... * when done if success: * ideally, generate a PR and attach link in email to jbosstools-dev@ * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR * email should includes boilerplate text to send mail to list announcing new change for review was: Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names. Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace. Thus for webtools we might simply define: webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do... and we'd end up with: http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8.... * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p... 2. when all children are done, a downstream job can runs TP update & validation against new .target files * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf... * parse that into a list of URLs * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files * resulting edited .target files will remain in the workspace, and we can then run * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u... * when done if success: * ideally, generate a PR and attach link in email to jbosstools-dev@ * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR * email should includes boilerplate text to send mail to list announcing new change for review > automate process for fetching latest target platform mirrors > ------------------------------------------------------------ > > Key: JBIDE-22305 > URL: https://issues.jboss.org/browse/JBIDE-22305 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: target-platform, updatesite, upstream > Affects Versions: 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.0.Alpha3 > > > Rather than manually pulling requirements, it would be hella sweet if there was a job config into which we could just list all the URLs to mirror and their matching project names. > Then this job would scrape the *.target files for the current list of URLs used, grep out the /requirements/<reqname>/<version>, fetch a new mirror for each new version*, and dump an updated copy of the .target file into the job's workspace. > Thus for webtools we might simply define: > webtools,S-3.8.0M7-20160503010110,http://download.eclipse.org/webtools/do... > and we'd end up with: > http://download.jboss.org/jbosstools/updates/requirements/webtools/S-3.8.... > * Since we already have a http://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevSt... job we can just pass parameters to that to invoke the mirroring steps. Would be even better if we could run multiple calls in parallel as neon and wtp can take >2hr > 1. matrix job. each config is a trio of reqname/version/URL which is passed to a process akin to that of the jbosstools-requirements job to perform the mirror; process is now scripted here: https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/p... > 2. when all children are done, a downstream job can runs TP update & validation against new .target files > * fetch http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstoolstargetplatf... > * parse that into a list of URLs > * each URL contains REQ_NAME/VERSION, which can then be matched up with similar lines in .target files > * run p2diff between old/new URLs in .target to generate list of changes and verify new site contains all the same IUs > * resulting edited .target files will remain in the workspace, and we can then run > * https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u... > * when done if success: > * ideally, generate a PR and attach link in email to jbosstools-dev@ > * if can't generate PR, then attach patch in email to nickboldt & mistria to apply locally in jbosstools-target-platforms to create a PR > * email should includes boilerplate text to send mail to list announcing new change for review -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 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 May 2016