July 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBDS-3961) CDK installation failed with progress bar stuck in 99%

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3961?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3961: ----------------------------- Fix Version/s: 10.0.1.AM2 > CDK installation failed with progress bar stuck in 99% > ------------------------------------------------------ > > Key: JBDS-3961 > URL: https://issues.jboss.org/browse/JBDS-3961 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Bug > Components: platform-installer > Environment: h3. Operating System: > Windows 10 Pro 64 Bit > h3. Devstudio version > Devstudio 1.0 GA > Reporter: Budh Ram Gurung > Labels: cdk > Fix For: 10.0.1.AM2 > > Attachments: dev_studio_installation.PNG > > > I was trying the "devstudio 1.0 GA build" ("development-suite-1.0.0-GA-bundle-installer.exe") and unable to get CDK installation after gone through the steps of authentication, vagrant, cygwin, jboss dev studio installations. > Observations: > CDK installation stuck in 99% with "failed" mark. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3961) CDK installation failed with progress bar stuck in 99%

by Budh Ram Gurung (JIRA)

Budh Ram Gurung created JBDS-3961: ------------------------------------- Summary: CDK installation failed with progress bar stuck in 99% Key: JBDS-3961 URL: https://issues.jboss.org/browse/JBDS-3961 Project: Red Hat JBoss Developer Studio (devstudio) Issue Type: Bug Components: platform-installer Environment: h3. Operating System: Windows 10 Pro 64 Bit h3. Devstudio version Devstudio 1.0 GA Reporter: Budh Ram Gurung Attachments: dev_studio_installation.PNG I was trying the "devstudio 1.0 GA build" ("development-suite-1.0.0-GA-bundle-installer.exe") and unable to get CDK installation after gone through the steps of authentication, vagrant, cygwin, jboss dev studio installations. Observations: CDK installation stuck in 99% with "failed" mark. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22689) enable baselineRepositories check to ensure timestamps increment for meta-changes too

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22689?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22689: ------------------------------------ The latest Neon-based staging build update site for JBT aggregate: http://download.jboss.org/jbosstools/neon/staging/updates/ for JBDS: https://devstudio.redhat.com/10.0/staging/updates/ OTOH, we could set a default URL for the components based on the project's github project name, if that can be computed within Maven, eg., for jbosstools-server, use ${jbosstools-server-site} ( https://github.com/jbosstools/jbosstools-build/blob/master/parent/pom.xml... ) Then we'd be comparing against the latest CI build, rather than the latest STAGING build. Would also need support for a fallback (skip test & pass the check) when there's no baseline URL to check, as this introduces a circular dependency in that we can't build the snapshot until the staging site exists, and we need to aggregate the snapshots to produce the staging site. > enable baselineRepositories check to ensure timestamps increment for meta-changes too > ------------------------------------------------------------------------------------- > > Key: JBIDE-22689 > URL: https://issues.jboss.org/browse/JBIDE-22689 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.1.AM1 > Reporter: Nick Boldt > Assignee: Mickael Istria > Fix For: 4.4.1.AM2 > > > To make sure to report a problem if we need to upversion for a meta-change (eg., build configuration) and there's no accompanying new commit to force the timestamp to increment: > From https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers > {code:xml} > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-p2-plugin</artifactId> > <version>${tycho.version}</version> > <configuration> > <baselineRepositories> > <repository> > <url>[some url]</url> > </repository> > </baselineRepositories> > </configuration> > </plugin> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22689) enable baselineRepositories check to ensure timestamps increment for meta-changes too

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22689?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-22689: ---------------------------------------- Ok, let's use that staging repo then as default value. What is its URL? Then individual components can decide to compare with their snapshot builds if it's better for them. > enable baselineRepositories check to ensure timestamps increment for meta-changes too > ------------------------------------------------------------------------------------- > > Key: JBIDE-22689 > URL: https://issues.jboss.org/browse/JBIDE-22689 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.1.AM1 > Reporter: Nick Boldt > Assignee: Mickael Istria > Fix For: 4.4.1.AM2 > > > To make sure to report a problem if we need to upversion for a meta-change (eg., build configuration) and there's no accompanying new commit to force the timestamp to increment: > From https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers > {code:xml} > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-p2-plugin</artifactId> > <version>${tycho.version}</version> > <configuration> > <baselineRepositories> > <repository> > <url>[some url]</url> > </repository> > </baselineRepositories> > </configuration> > </plugin> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22689) enable baselineRepositories check to ensure timestamps increment for meta-changes too

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22689?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22689: ------------------------------------ We've been doing weekly staging builds for the last whole sprint. :D We didn't do one this past week because Friday was Canada Day. And no one from PgM or PM or PL actually asked for one. > enable baselineRepositories check to ensure timestamps increment for meta-changes too > ------------------------------------------------------------------------------------- > > Key: JBIDE-22689 > URL: https://issues.jboss.org/browse/JBIDE-22689 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.1.AM1 > Reporter: Nick Boldt > Assignee: Mickael Istria > Fix For: 4.4.1.AM2 > > > To make sure to report a problem if we need to upversion for a meta-change (eg., build configuration) and there's no accompanying new commit to force the timestamp to increment: > From https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers > {code:xml} > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-p2-plugin</artifactId> > <version>${tycho.version}</version> > <configuration> > <baselineRepositories> > <repository> > <url>[some url]</url> > </repository> > </baselineRepositories> > </configuration> > </plugin> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-795) JBDSIS 9.0.0 beta1 / Early Access is giving an Id to Camel routes by default

by Brian Fitzpatrick (JIRA)

[ https://issues.jboss.org/browse/JBTIS-795?page=com.atlassian.jira.plugin.... ] Brian Fitzpatrick updated JBTIS-795: ------------------------------------ Comment: was deleted (was: I can create one.) > JBDSIS 9.0.0 beta1 / Early Access is giving an Id to Camel routes by default > ---------------------------------------------------------------------------- > > Key: JBTIS-795 > URL: https://issues.jboss.org/browse/JBTIS-795 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: Fuse IDE > Affects Versions: 9.0.0.Beta1 > Environment: JBDS 9.1 with devstudio-integration-stack-9.0.0.Beta1-earlyaccess.zip > Reporter: Rick Wagner > Assignee: Brian Fitzpatrick > > A user has noted that Camel routes used in SwitchYard are now being given an Id without user input. This is a changed behavior. > The same user complains of very slow loading of SwitchYard/Camel component routes, but this is still under investigation in the cited support ticket. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-795) JBDSIS 9.0.0 beta1 / Early Access is giving an Id to Camel routes by default

by Brian Fitzpatrick (JIRA)

[ https://issues.jboss.org/browse/JBTIS-795?page=com.atlassian.jira.plugin.... ] Brian Fitzpatrick commented on JBTIS-795: ----------------------------------------- [~rick_wagner] Any chance we can get a project example from the customer for the performance issue? > JBDSIS 9.0.0 beta1 / Early Access is giving an Id to Camel routes by default > ---------------------------------------------------------------------------- > > Key: JBTIS-795 > URL: https://issues.jboss.org/browse/JBTIS-795 > Project: JBoss Tools Integration Stack > Issue Type: Bug > Components: Fuse IDE > Affects Versions: 9.0.0.Beta1 > Environment: JBDS 9.1 with devstudio-integration-stack-9.0.0.Beta1-earlyaccess.zip > Reporter: Rick Wagner > Assignee: Brian Fitzpatrick > > A user has noted that Camel routes used in SwitchYard are now being given an Id without user input. This is a changed behavior. > The same user complains of very slow loading of SwitchYard/Camel component routes, but this is still under investigation in the cited support ticket. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22689) enable baselineRepositories check to ensure timestamps increment for meta-changes too

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22689?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-22689: ---------------------------------------- Is this weekly staging going to happen soon? I have the intuition that comparing to component nightly is the best choice but it requires to set a property in pom.xml for each component... > enable baselineRepositories check to ensure timestamps increment for meta-changes too > ------------------------------------------------------------------------------------- > > Key: JBIDE-22689 > URL: https://issues.jboss.org/browse/JBIDE-22689 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.1.AM1 > Reporter: Nick Boldt > Assignee: Mickael Istria > Fix For: 4.4.1.AM2 > > > To make sure to report a problem if we need to upversion for a meta-change (eg., build configuration) and there's no accompanying new commit to force the timestamp to increment: > From https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers > {code:xml} > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-p2-plugin</artifactId> > <version>${tycho.version}</version> > <configuration> > <baselineRepositories> > <repository> > <url>[some url]</url> > </repository> > </baselineRepositories> > </configuration> > </plugin> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22689) enable baselineRepositories check to ensure timestamps increment for meta-changes too

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22689?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22689: ------------------------------------ if we start publishing an I-build (/staging/) every week for JBT/JBDS, we can compare to that repo. > enable baselineRepositories check to ensure timestamps increment for meta-changes too > ------------------------------------------------------------------------------------- > > Key: JBIDE-22689 > URL: https://issues.jboss.org/browse/JBIDE-22689 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.1.AM1 > Reporter: Nick Boldt > Assignee: Mickael Istria > Fix For: 4.4.1.AM2 > > > To make sure to report a problem if we need to upversion for a meta-change (eg., build configuration) and there's no accompanying new commit to force the timestamp to increment: > From https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers > {code:xml} > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-p2-plugin</artifactId> > <version>${tycho.version}</version> > <configuration> > <baselineRepositories> > <repository> > <url>[some url]</url> > </repository> > </baselineRepositories> > </configuration> > </plugin> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22689) enable baselineRepositories check to ensure timestamps increment for meta-changes too

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22689?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-22689: ---------------------------------------- Eclipse platform uses its I-Builds (weekly or so). > enable baselineRepositories check to ensure timestamps increment for meta-changes too > ------------------------------------------------------------------------------------- > > Key: JBIDE-22689 > URL: https://issues.jboss.org/browse/JBIDE-22689 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.1.AM1 > Reporter: Nick Boldt > Assignee: Mickael Istria > Fix For: 4.4.1.AM2 > > > To make sure to report a problem if we need to upversion for a meta-change (eg., build configuration) and there's no accompanying new commit to force the timestamp to increment: > From https://wiki.eclipse.org/Tycho/Reproducible_Version_Qualifiers > {code:xml} > <plugin> > <groupId>org.eclipse.tycho</groupId> > <artifactId>tycho-p2-plugin</artifactId> > <version>${tycho.version}</version> > <configuration> > <baselineRepositories> > <repository> > <url>[some url]</url> > </repository> > </baselineRepositories> > </configuration> > </plugin> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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