May 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBDS-3881) Pass user password to devstudio as system property for first launch from platform installer

by Denis Golovin (JIRA)

[ https://issues.jboss.org/browse/JBDS-3881?page=com.atlassian.jira.plugin.... ] Denis Golovin updated JBDS-3881: -------------------------------- Description: To avoid re-prompting password during vagrant-up configure system property rhel.subscription.password with user password when launching DevStudio form installer (was: To avoid re-prompting password during vagrant-up configure system property with user password when launching DevStudio form installer) > Pass user password to devstudio as system property for first launch from platform installer > ------------------------------------------------------------------------------------------- > > Key: JBDS-3881 > URL: https://issues.jboss.org/browse/JBDS-3881 > Project: Red Hat Developer Studio (DevStudio) > Issue Type: Feature Request > Components: platform-installer > Affects Versions: 10.0.0.Alpha2 > Reporter: Denis Golovin > Assignee: Denis Golovin > > To avoid re-prompting password during vagrant-up configure system property rhel.subscription.password with user password when launching DevStudio form installer -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22302) Outdated project examples in Help menu

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22302?page=com.atlassian.jira.plugi... ] Fred Bricon resolved JBIDE-22302. --------------------------------- Resolution: Done Fixed with https://github.com/jbdevstudio/jbdevstudio-product/commit/312c807865ce7ce... and the changes in ide-config.properties for JBIDE-13287 > Outdated project examples in Help menu > -------------------------------------- > > Key: JBIDE-22302 > URL: https://issues.jboss.org/browse/JBIDE-22302 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: project-examples > Affects Versions: 4.3.1.Final > Reporter: Josef Kopriva > Assignee: Fred Bricon > Fix For: 4.4.0.Alpha2 > > Attachments: JBDS_8.0_Examples.png > > > Project examples are probably outdated in menu: *Help* >> *Project Examples...* > Repository[1] from configuration file[2] contains outdated files. > In *JBDS 9.1.0.GA* are also old sites - *8.0* - screenshot attached. > [1] http://download.jboss.org/jbosstools/examples/ > [2] http://download.jboss.org/jbosstools/configuration/ide-config.properties -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13287) examples URLs should use major/minor/service/milestone convention

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13287?page=com.atlassian.jira.plugi... ] Fred Bricon edited comment on JBIDE-13287 at 5/5/16 1:10 PM: ------------------------------------------------------------- Example URLs are now pointing to 4/4/project-examples*.xml in download.jboss.org/jbosstools/configuration/ide-config.properties, for jbt 4.4 and devstudio 10.0. micro/milestone urls will be added if necessary in the future was (Author: fbricon): Example URLs are now pointing to 4/4/project-examples*.xml in download.jboss.org/jbosstools/configuration/ide-config.properties, for jbt 4.4 and devstudio 10.0. > examples URLs should use major/minor/service/milestone convention > ------------------------------------------------------------------ > > Key: JBIDE-13287 > URL: https://issues.jboss.org/browse/JBIDE-13287 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: project-examples > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Fred Bricon > Fix For: 4.4.0.Alpha2 > > > Instead of > {code:title=http://download.jboss.org/jbosstools/examples/} > project-examples-community-4.0.GA.xml > project-examples-jbds60.xml > project-examples-maven-4.0.GA.xml > project-examples-shared-4.0.GA.xml > ... > {code} > We should consider using something like 6/1/0/Alpha1/project-examples*.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13287) examples URLs should use major/minor/service/milestone convention

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13287?page=com.atlassian.jira.plugi... ] Fred Bricon resolved JBIDE-13287. --------------------------------- Fix Version/s: 4.4.0.Alpha2 (was: 4.4.x) Resolution: Done Example URLs are now pointing to 4/4/project-examples*.xml in download.jboss.org/jbosstools/configuration/ide-config.properties, for jbt 4.4 and devstudio 10.0. > examples URLs should use major/minor/service/milestone convention > ------------------------------------------------------------------ > > Key: JBIDE-13287 > URL: https://issues.jboss.org/browse/JBIDE-13287 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: project-examples > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Fred Bricon > Fix For: 4.4.0.Alpha2 > > > Instead of > {code:title=http://download.jboss.org/jbosstools/examples/} > project-examples-community-4.0.GA.xml > project-examples-jbds60.xml > project-examples-maven-4.0.GA.xml > project-examples-shared-4.0.GA.xml > ... > {code} > We should consider using something like 6/1/0/Alpha1/project-examples*.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13287) examples URLs should use major/minor/service/milestone convention

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13287?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-13287: -------------------------------- Issue Type: Task (was: Bug) > examples URLs should use major/minor/service/milestone convention > ------------------------------------------------------------------ > > Key: JBIDE-13287 > URL: https://issues.jboss.org/browse/JBIDE-13287 > Project: Tools (JBoss Tools) > Issue Type: Task > Components: project-examples > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Fred Bricon > Fix For: 4.4.0.Alpha2 > > > Instead of > {code:title=http://download.jboss.org/jbosstools/examples/} > project-examples-community-4.0.GA.xml > project-examples-jbds60.xml > project-examples-maven-4.0.GA.xml > project-examples-shared-4.0.GA.xml > ... > {code} > We should consider using something like 6/1/0/Alpha1/project-examples*.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13287) examples URLs should use major/minor/service/milestone convention

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13287?page=com.atlassian.jira.plugi... ] Fred Bricon reassigned JBIDE-13287: ----------------------------------- Assignee: Fred Bricon (was: Max Rydahl Andersen) > examples URLs should use major/minor/service/milestone convention > ------------------------------------------------------------------ > > Key: JBIDE-13287 > URL: https://issues.jboss.org/browse/JBIDE-13287 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: project-examples > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Fred Bricon > Fix For: 4.4.x > > > Instead of > {code:title=http://download.jboss.org/jbosstools/examples/} > project-examples-community-4.0.GA.xml > project-examples-jbds60.xml > project-examples-maven-4.0.GA.xml > project-examples-shared-4.0.GA.xml > ... > {code} > We should consider using something like 6/1/0/Alpha1/project-examples*.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13287) examples URLs should use major/minor/service/milestone convention

by Fred Bricon (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13287?page=com.atlassian.jira.plugi... ] Fred Bricon updated JBIDE-13287: -------------------------------- Sprint: devex #114 May 2017 > examples URLs should use major/minor/service/milestone convention > ------------------------------------------------------------------ > > Key: JBIDE-13287 > URL: https://issues.jboss.org/browse/JBIDE-13287 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: project-examples > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Max Rydahl Andersen > Fix For: 4.4.x > > > Instead of > {code:title=http://download.jboss.org/jbosstools/examples/} > project-examples-community-4.0.GA.xml > project-examples-jbds60.xml > project-examples-maven-4.0.GA.xml > project-examples-shared-4.0.GA.xml > ... > {code} > We should consider using something like 6/1/0/Alpha1/project-examples*.xml -- 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 jbosstools-requirements job to perform the mirror * curl syntax to invoke the job 2. when job child completes, it updates the .target files in the workspace w/ the new URL that has been mirrored * sed 3. when all children are done, a second downstream job runs TP update & validation against new .target files * 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 in jbosstools-target-platforms, with email template attached so easier to send mail to list announcing new change 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 jbosstools-requirements job to perform the mirror * curl syntax to invoke the job 2. when job child completes, it updates the .target files in the workspace w/ the new URL that has been mirrored * sed 3. when all children are done, a second downstream job runs TP update & validation against new .target files * 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 in jbosstools-target-platforms, with email template attached so easier to send mail to list announcing new change > 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 jbosstools-requirements job to perform the mirror > * curl syntax to invoke the job > 2. when job child completes, it updates the .target files in the workspace w/ the new URL that has been mirrored > * sed > 3. when all children are done, a second downstream job runs TP update & validation against new .target files > * 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 in jbosstools-target-platforms, with email template attached so easier to send mail to list announcing new change -- 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 jbosstools-requirements job to perform the mirror * curl syntax to invoke the job 2. when job child completes, it updates the .target files in the workspace w/ the new URL that has been mirrored * sed 3. when all children are done, a second downstream job runs TP update & validation against new .target files * 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 in jbosstools-target-platforms, with email template attached so easier to send mail to list announcing new change 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 > 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 jbosstools-requirements job to perform the mirror > * curl syntax to invoke the job > 2. when job child completes, it updates the .target files in the workspace w/ the new URL that has been mirrored > * sed > 3. when all children are done, a second downstream job runs TP update & validation against new .target files > * 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 in jbosstools-target-platforms, with email template attached so easier to send mail to list announcing new change -- 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 reassigned JBIDE-22305: ---------------------------------- Story Points: 21 Sprint: devex #115 May 2017 Assignee: Nick Boldt > 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 -- 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