October 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBDS-3191) Improve the way we switch between development and GA

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3191?page=com.atlassian.jira.plugin.... ] Nick Boldt closed JBDS-3191. ---------------------------- Resolution: Out of Date Closing out of date > Improve the way we switch between development and GA > ---------------------------------------------------- > > Key: JBDS-3191 > URL: https://issues.jboss.org/browse/JBDS-3191 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > Assignee: Nick Boldt > Fix For: 10.1.0.GA > > > JBDS-3190 has shown that there are too many changes to perform when willing to create a GA candidate, and it's almost certain that we'll forever forget to change one or some of them when switching between GA and development stream. > We need to improve that. > Changes are necessary in: > * features/com.jboss.devstudio.core/feature/p2.inf > * site/associate.properties > * results/pom.xml > As an alternative, I suggest that the final site be ALWAYS added to the referenced site, even if it's empty. This has no cost for build nor user, and this would simplify a few things here and there. > Also, instead of a p2.inf, we could think a a "startup" extension that would add reference to development site in case qualifier for the feature doesn't contain GA. > The property to the "current site" (GA or development) could be factorized in JBDS parent pom. so that both results/pom.xml and site/pom.xml could use it (instead of associateSites.properties). > CC [~nickboldt] [~maxandersen] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3510) Consider including Buildship in JBT/JBDS - add new connector to Central

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3510?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3510: ----------------------------- Fix Version/s: LATER (was: 10.x) > Consider including Buildship in JBT/JBDS - add new connector to Central > ----------------------------------------------------------------------- > > Key: JBDS-3510 > URL: https://issues.jboss.org/browse/JBDS-3510 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Feature Request > Components: 3rd-party-certification, 3rd-party-dependencies, central, central-update > Affects Versions: 9.0.0.CR1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: LATER > > > {quote} > support for Gradle via BuildShip project is set to be included in Eclipse Mars SR1. > Something we probably need to at least test/coexist with in near future. > /max{quote} > Info: > * https://gradle.org/eclipse/ > * https://projects.eclipse.org/projects/tools.buildship > Update sites: > * http://download.eclipse.org/buildship/updates/e45/releases > * http://download.eclipse.org/buildship/updates/e45/milestones/1.0 > * http://download.eclipse.org/buildship/updates/e45/snapshots/1.0 > (also should be in Mars.1 release [1] coming out in a few weeks) > [1] https://wiki.eclipse.org/Mars/Simultaneous_Release_Plan#Mars.1 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[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 updated JBIDE-23013: ------------------------------- Fix Version/s: LATER (was: 4.4.x) > 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: Nick Boldt > 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 (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-17608) improve p2diff's URI handling to support relative path folder and zips

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17608?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-17608: ------------------------------- Fix Version/s: LATER (was: 4.3.x) > improve p2diff's URI handling to support relative path folder and zips > ---------------------------------------------------------------------- > > Key: JBIDE-17608 > URL: https://issues.jboss.org/browse/JBIDE-17608 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build, upstream > Affects Versions: 4.2.0.Beta2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Optional > Fix For: LATER > > > Instead of having to type: > {code} > p2diff file:///home/nboldt/tru/disco/jbtearlyaccesstarget/multiple/target/jbtearlyaccess-multiple.target.repo/ file:///home/nboldt/tru/disco/jbtearlyaccesstarget/multiple/target_FULL/jbtearlyaccess-multiple.target.repo/ > {code} > I'd like to see it work for > {code} > p2diff target target2 > or > p2diff site.zip site2.zip > {code} > So we need a few things: > a) find the nested repo in the specified folder (if not in `pwd` look in child folders for a p2 repo or repo zip) > b) better error reporting if the specified folders aren't repos or don't contain repos (right now p2diff does NOTHING if it doesn't like the URIs stated > c) if a local path exists, prepend file:// onto the file path so it behaves like a p2 URI > d) if a local repo zip found then prepend jar:file:// and append !/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3893) Refactor target platforms from jbdevstudio to devstudio

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3893?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3893: ----------------------------- Fix Version/s: LATER (was: 10.x) > Refactor target platforms from jbdevstudio to devstudio > ------------------------------------------------------- > > Key: JBDS-3893 > URL: https://issues.jboss.org/browse/JBDS-3893 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Task > Components: target-platform, updatesite > Affects Versions: 10.0.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: LATER > > > In https://github.com/jbosstools/jbosstools-target-platforms/commits/4.60.x we should finally adopt consistent naming/branding for the devstudio target platforms, using devstudio instead of jbdevstudio. > Affected: publishing/staging/release scripts, jenkins jobs, etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3894) Refactor discovery plugins/TPs from jbds/jbdevstudio to devstudio

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBDS-3894?page=com.atlassian.jira.plugin.... ] Nick Boldt updated JBDS-3894: ----------------------------- Fix Version/s: LATER (was: 10.x) > Refactor discovery plugins/TPs from jbds/jbdevstudio to devstudio > ----------------------------------------------------------------- > > Key: JBDS-3894 > URL: https://issues.jboss.org/browse/JBDS-3894 > Project: Red Hat JBoss Developer Studio (devstudio) > Issue Type: Task > Components: central-update, target-platform, updatesite > Affects Versions: 10.0.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: LATER > > > In https://github.com/jbosstools/jbosstools-discovery/ we should finally adopt consistent naming/branding for the devstudio target platforms, using devstudio instead of jbdevstudio and jbds. > Affected: publishing/staging/release scripts, discovery sites, jenkins jobs, etc. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22819) wrap staging build process with a jenkins job

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22819?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-22819: ------------------------------- Sprint: devex #118 July 2016, devex #119 August 2016, devex #121 September 2016 (was: devex #118 July 2016, devex #119 August 2016, devex #122 October 2016) > wrap staging build process with a jenkins job > --------------------------------------------- > > Key: JBIDE-22819 > URL: https://issues.jboss.org/browse/JBIDE-22819 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.AM2 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM3 > > > Job requires about 13 params: > {code} > version (JBT and JBDS) > versionWithRespin (JBT and JBDS) > versionWithRespin_PREV (JBT and JBDS) > target platforms (min, max, central) > respin # (- or a, b, c) > devsuite installerExe url > stream_JBT=master # or 4.4.neon > stream_DS=master # or 10.0.neon > {code} > See https://github.com/jbdevstudio/jbdevstudio-devdoc/tree/master/release_gui... for the steps to convert into a job -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23017) use sshfs to speed up publishing process

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23017?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23017: ------------------------------- Sprint: devex #119 August 2016, devex #120 September 2016, devex #121 September 2016 (was: devex #119 August 2016, devex #120 September 2016) > use sshfs to speed up publishing process > ----------------------------------------- > > Key: JBIDE-23017 > URL: https://issues.jboss.org/browse/JBIDE-23017 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.4.1.AM3 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM2 > > > Currently, publishing from /snapshots to /staging and from /staging to /development requires that we fetch several GBs of data from filemgmt.jboss.org to a temp folder, then push those bits to a new folder on filemgmt.jboss.org. > If we could simply copy bits over sshfs, the process might be a lot faster than these times: > {code} > JBT coretests 1.1G: 59m20 > JBT core 1.2G: 64m23 > devstudio (copy from filemgmt to filemgmt) 2.4G: 2h13 > devstudio (copy from local to www.qa) 3.1G: 6mins(?) > {code} > To make this work, however, we need more slaves to have sshfs installed. Currently, it appears that only dev01 [1] is so equipped. And that slave, currently, has a build queue more than 170 jobs long, making it impractical to even TEST publishing over sshfs. > [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/computer/dev01-rhel5-x86/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20904) automate publishing latest CI build to staging, then from staging to development (or stable)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20904?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-20904: ------------------------------- Sprint: devex #115 May 2016, devex #116 June 2016, devex #118 July 2016, devex #119 August 2016, devex #121 September 2016 (was: devex #115 May 2016, devex #116 June 2016, devex #118 July 2016, devex #119 August 2016, devex #122 October 2016) > automate publishing latest CI build to staging, then from staging to development (or stable) > -------------------------------------------------------------------------------------------- > > Key: JBIDE-20904 > URL: https://issues.jboss.org/browse/JBIDE-20904 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM3 > > > Suggestion: > rather than opening 10 bash terminals to perform the copy-from-one-place-on-disk-to-local, copy-from-local-to-another-place steps required to clone CI bits to Stage or from Stage to release, [~mickael_istria] and I discovered today that we could use `wait` or `parallel` to orchestrate these steps via a bash script so they run in parallel (as quickly as possible), but still return feedback when all parallel steps are completed. > So, where today we run these steps sorta-by-hand (copy script into a console and wait until it's done) [1], in future we could simply kick a job and wait for the job to notify its completion. > [1] https://github.com/jbdevstudio/jbdevstudio-devdoc/tree/master/release_gui... > Examples of using a series of commands in parallel w/ a wait at the end: > http://stackoverflow.com/questions/19543139/bash-script-processing-comman... > {code:title=spawns the 3 parallel steps, waits until #3 is done (2 seconds later) and returns the PID of the last one + its return code} > echo "1" & echo 2 & (sleep 2;echo 3) & wait && echo $! $# > {code} > More discussion: > {quote} > [12:44:46 PM] Mickael Istria: I believe some parts would have to be turned into functions > [12:54:41 PM] Mickael Istria: so, to hack the script, it could be just: > * add && after the 1st rsync in each loop > * add & after the last one > * put a wait after the last loop > * give the big piece of code to procede directly to bash > {quote} > After this job is done, releng would still have to "wire up" the new bits by updating composite*.xml and index.html pages, but that's considerably easier to do locally in a terminal, or even to script too. Rather than updating these files w/ sed, we could generate them from a template. > And if we don't care about committing those changes back to github, we could even push them to the dl.jb.o and ds.jb.c servers directly as part of the above job. > Scary, but much faster! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20904) automate publishing latest CI build to staging, then from staging to development (or stable)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20904?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-20904: ------------------------------- Sprint: devex #115 May 2016, devex #116 June 2016, devex #118 July 2016, devex #119 August 2016, devex #122 October 2016 (was: devex #115 May 2016, devex #116 June 2016, devex #118 July 2016, devex #119 August 2016) > automate publishing latest CI build to staging, then from staging to development (or stable) > -------------------------------------------------------------------------------------------- > > Key: JBIDE-20904 > URL: https://issues.jboss.org/browse/JBIDE-20904 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Affects Versions: 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.2.AM3 > > > Suggestion: > rather than opening 10 bash terminals to perform the copy-from-one-place-on-disk-to-local, copy-from-local-to-another-place steps required to clone CI bits to Stage or from Stage to release, [~mickael_istria] and I discovered today that we could use `wait` or `parallel` to orchestrate these steps via a bash script so they run in parallel (as quickly as possible), but still return feedback when all parallel steps are completed. > So, where today we run these steps sorta-by-hand (copy script into a console and wait until it's done) [1], in future we could simply kick a job and wait for the job to notify its completion. > [1] https://github.com/jbdevstudio/jbdevstudio-devdoc/tree/master/release_gui... > Examples of using a series of commands in parallel w/ a wait at the end: > http://stackoverflow.com/questions/19543139/bash-script-processing-comman... > {code:title=spawns the 3 parallel steps, waits until #3 is done (2 seconds later) and returns the PID of the last one + its return code} > echo "1" & echo 2 & (sleep 2;echo 3) & wait && echo $! $# > {code} > More discussion: > {quote} > [12:44:46 PM] Mickael Istria: I believe some parts would have to be turned into functions > [12:54:41 PM] Mickael Istria: so, to hack the script, it could be just: > * add && after the 1st rsync in each loop > * add & after the last one > * put a wait after the last loop > * give the big piece of code to procede directly to bash > {quote} > After this job is done, releng would still have to "wire up" the new bits by updating composite*.xml and index.html pages, but that's considerably easier to do locally in a terminal, or even to script too. Rather than updating these files w/ sed, we could generate them from a template. > And if we don't care about committing those changes back to github, we could even push them to the dl.jb.o and ds.jb.c servers directly as part of the above job. > Scary, but much faster! -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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