November 2015 - jbosstools-issues

[JBoss JIRA] (JBTIS-509) clean up duplicate IS content in JBT EA sites (Luna / 4.2)

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-509?page=com.atlassian.jira.plugin.... ] Paul Leacu resolved JBTIS-509. ------------------------------ Fix Version/s: 4.2.3.Final Resolution: Done Corrected and pushed to server. https://github.com/jbosstools/jbosstools-download.jboss.org/commit/f9b03f... !p2fix.png|thumbnail! > clean up duplicate IS content in JBT EA sites (Luna / 4.2) > ---------------------------------------------------------- > > Key: JBTIS-509 > URL: https://issues.jboss.org/browse/JBTIS-509 > Project: JBoss Tools Integration Stack > Issue Type: Sub-task > Components: distribution > Affects Versions: 4.2.3.Final > Reporter: Nick Boldt > Assignee: Paul Leacu > Fix For: 4.2.3.Final > > Attachments: p2fix.png, why-need-2-copies-of-jbtis-ea-tp.png > > > Using the p2 browser, I looked into the contents of these sites: > http://download.jboss.org/jbosstools/earlyaccess/stable/luna/ > http://download.jboss.org/jbosstools/earlyaccess/development/luna/ > And see that there are two copies of the earlyaccess jbtistarget: 4.2.6.Final and 4.2.7.Final. > Why do you need both? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTIS-509) clean up duplicate IS content in JBT EA sites (Luna / 4.2)

by Paul Leacu (JIRA)

[ https://issues.jboss.org/browse/JBTIS-509?page=com.atlassian.jira.plugin.... ] Paul Leacu updated JBTIS-509: ----------------------------- Attachment: p2fix.png > clean up duplicate IS content in JBT EA sites (Luna / 4.2) > ---------------------------------------------------------- > > Key: JBTIS-509 > URL: https://issues.jboss.org/browse/JBTIS-509 > Project: JBoss Tools Integration Stack > Issue Type: Sub-task > Components: distribution > Affects Versions: 4.2.3.Final > Reporter: Nick Boldt > Assignee: Paul Leacu > Attachments: p2fix.png, why-need-2-copies-of-jbtis-ea-tp.png > > > Using the p2 browser, I looked into the contents of these sites: > http://download.jboss.org/jbosstools/earlyaccess/stable/luna/ > http://download.jboss.org/jbosstools/earlyaccess/development/luna/ > And see that there are two copies of the earlyaccess jbtistarget: 4.2.6.Final and 4.2.7.Final. > Why do you need both? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21038) Software/Update page is not working on Fedora 23 (Beta)

by Snjezana Peco (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21038?page=com.atlassian.jira.plugi... ] Snjezana Peco commented on JBIDE-21038: --------------------------------------- I have tried to reproduce the issue on Fedora 23 Final, but haven't succeeded. > Software/Update page is not working on Fedora 23 (Beta) > ------------------------------------------------------- > > Key: JBIDE-21038 > URL: https://issues.jboss.org/browse/JBIDE-21038 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: central > Affects Versions: 4.3.0.Final > Environment: JBDS 9.0.0.GA > Reporter: Radim Hopp > Assignee: Snjezana Peco > Priority: Critical > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Recently I upgraded my system to Fedora 23 (beta) and second page of Cetnral (Software/Update) is not working. It is rendered with "Refreshing..." text and carousel (which is not spinning as it should). One processor core goes 100%. > java version "1.8.0_65" > gtk3 version 3.18.2 > jstack: http://pastebin.com/a7U02yjt > Everything is fine with GTK2. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

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

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-21012: ------------------------------------ Successfully built and deployed a SNAPSHOT site using -DBUILD_ALIAS_NUM=51 (to synthesize a Beta1): https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... And the exploded update site: https://repository.jboss.org/nexus/content/unzip/unzip/org/jboss/tools/fr... So... this approach might be doable. *{color:red}HOWEVER{color}* ... [~dgolovin] raised a good point here about how aggregation would work for CI builds in master branch while component builds are being replaced by a new build result. Will things break (because the resolved stuff has vanished)? Likely, since there's only one "latest" build available in the /unzip/ URL. So if we do move to this model, it sounds like it might best be used only for building from code freeze branches, NOT from master. > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21052) ensure compare-with-baseline uses latest Mars stable release, not development or luna

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21052?page=com.atlassian.jira.plugi... ] Nick Boldt resolved JBIDE-21052. -------------------------------- Resolution: Done PRs merged. Announced here: http://lists.jboss.org/pipermail/jbosstools-dev/2015-November/010751.html Built here: http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build.pare... >=43 http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-build.pare... >=592 > ensure compare-with-baseline uses latest Mars stable release, not development or luna > ------------------------------------------------------------------------------------- > > Key: JBIDE-21052 > URL: https://issues.jboss.org/browse/JBIDE-21052 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Critical > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Noticed today that the version of org.jboss.tools.central.easymport.feature in JBT 4.3.1.Beta1 CI build is 0.1.0.Beta1 [1], when we released 0.1.0.Final-v20151001-1531-B45 in JBT 4.3.0.Final [2]. > [1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars/ > [2] http://download.jboss.org/jbosstools/static/mars/stable/updates/core/4.3.... > So the baseline check is failing to see that there's a problem, and this is because it's comparing agaisnt the LUNA release, not the 4.3.0.Final Mars release. > PRs to fix: > 4.3.x: https://github.com/jbosstools/jbosstools-build/pull/210 > master: https://github.com/jbosstools/jbosstools-build/pull/211 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21052) ensure compare-with-baseline uses latest Mars stable release, not development or luna

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21052?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-21052: ------------------------------- Description: Noticed today that the version of org.jboss.tools.central.easymport.feature in JBT 4.3.1.Beta1 CI build is 0.1.0.Beta1 [1], when we released 0.1.0.Final-v20151001-1531-B45 in JBT 4.3.0.Final [2]. [1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars/ [2] http://download.jboss.org/jbosstools/static/mars/stable/updates/core/4.3.... So the baseline check is failing to see that there's a problem, and this is because it's comparing agaisnt the LUNA release, not the 4.3.0.Final Mars release. PRs to fix: 4.3.x: https://github.com/jbosstools/jbosstools-build/pull/210 master: https://github.com/jbosstools/jbosstools-build/pull/211 was: Noticed today that the version of easymport in JBT 4.3.1.Beta1 CI build is 0.1.0.Beta1, when we released 0.1.0.Final in 4.3.0.Final. So the baseline check is failing to see that there's a problem, and this is because it's comparing agaisnt the LUNA release, not the 4.3.0.Final Mars release. PRs to fix: 4.3.x: https://github.com/jbosstools/jbosstools-build/pull/210 master: https://github.com/jbosstools/jbosstools-build/pull/211 > ensure compare-with-baseline uses latest Mars stable release, not development or luna > ------------------------------------------------------------------------------------- > > Key: JBIDE-21052 > URL: https://issues.jboss.org/browse/JBIDE-21052 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Critical > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Noticed today that the version of org.jboss.tools.central.easymport.feature in JBT 4.3.1.Beta1 CI build is 0.1.0.Beta1 [1], when we released 0.1.0.Final-v20151001-1531-B45 in JBT 4.3.0.Final [2]. > [1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars/ > [2] http://download.jboss.org/jbosstools/static/mars/stable/updates/core/4.3.... > So the baseline check is failing to see that there's a problem, and this is because it's comparing agaisnt the LUNA release, not the 4.3.0.Final Mars release. > PRs to fix: > 4.3.x: https://github.com/jbosstools/jbosstools-build/pull/210 > master: https://github.com/jbosstools/jbosstools-build/pull/211 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21052) ensure compare-with-baseline uses latest Mars stable release, not development or luna

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21052?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-21052: ---------------------------------------- +1. Marking it as critical as it's the best way to find version issues early. > ensure compare-with-baseline uses latest Mars stable release, not development or luna > ------------------------------------------------------------------------------------- > > Key: JBIDE-21052 > URL: https://issues.jboss.org/browse/JBIDE-21052 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Critical > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Noticed today that the version of easymport in JBT 4.3.1.Beta1 CI build is 0.1.0.Beta1, when we released 0.1.0.Final in 4.3.0.Final. > So the baseline check is failing to see that there's a problem, and this is because it's comparing agaisnt the LUNA release, not the 4.3.0.Final Mars release. > PRs to fix: > 4.3.x: https://github.com/jbosstools/jbosstools-build/pull/210 > master: https://github.com/jbosstools/jbosstools-build/pull/211 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-21052) ensure compare-with-baseline uses latest Mars stable release, not development or luna

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21052?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-21052: ----------------------------------- Priority: Critical (was: Major) > ensure compare-with-baseline uses latest Mars stable release, not development or luna > ------------------------------------------------------------------------------------- > > Key: JBIDE-21052 > URL: https://issues.jboss.org/browse/JBIDE-21052 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.1.Beta1, 4.4.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Critical > Fix For: 4.3.1.Beta1, 4.4.0.Alpha1 > > > Noticed today that the version of easymport in JBT 4.3.1.Beta1 CI build is 0.1.0.Beta1, when we released 0.1.0.Final in 4.3.0.Final. > So the baseline check is failing to see that there's a problem, and this is because it's comparing agaisnt the LUNA release, not the 4.3.0.Final Mars release. > PRs to fix: > 4.3.x: https://github.com/jbosstools/jbosstools-build/pull/210 > master: https://github.com/jbosstools/jbosstools-build/pull/211 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 5 months

1
0
0 / 0

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

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-21012: ------------------------------------ Here's the maven warning: {code} [WARNING] Some problems were encountered while building the effective model for org.jboss.tools.freemarker.features:org.jboss.ide.eclipse.freemarker.feature:eclipse-feature:1.5.100-SNAPSHOT [WARNING] 'version' contains an expression but should be a constant. @ org.jboss.tools:freemarker:1.5.1${BUILD_ALIAS}-SNAPSHOT, /home/nboldt/eclipse/workspace-jboss/jbosstools-github-master/jbosstools-freemarker/pom.xml, line 11, column 11 {code} > 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, 5 months

1
0
0 / 0

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

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-21012?page=com.atlassian.jira.plugi... ] Nick Boldt edited comment on JBIDE-21012 at 11/4/15 11:16 AM: -------------------------------------------------------------- To get value out of deploying JBT components' update sites to Nexus, a) component leads need to upversion their x.y.z+1 (3rd digit) for every milestone release, eg., in a task JIRA like JBIDE-20947 b) component leads need to ensure that every time they upversion and their Nexus URL changes, they submit a PR against jbosstools-build to change the URL in the parent pom. This will ensure all projects downstream use their correct latest bits c) releng & QE need tools to audit when a component lead forgets to do (a) and (b) d) releng & QE need tools to audit contents of JBT/JBDS update sites, since we will no longer be able to just visually inspect the list of features [1] to ensure they all have the same BUILD_ALIAS [1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars... ----- We could adopt a numerical convention that mimics Alpha/Beta/CR/Final nomenclature. For example... instead of having a project versioned with: * 4.3.0.Alpha1 * 4.3.0.Alpha2 * 4.3.0.Beta1 * 4.3.0.Beta2 * 4.3.0.CR1 * 4.3.0.Final/GA we might use * 4.3.011 (1 = Alpha, 11 = Alpha1) * 4.3.012 * 4.3.051 (5 = Beta, 51 = Beta1) * 4.3.052 * 4.3.091 (9 = CR/Final/GA) * 4.3.092 then for 4.3.1 maintenance... * 4.3.151 (51 = Beta1) * 4.3.152 (52 = Beta2) * 4.3.191 (91 = CR1) * 4.3.192 (92 = CR2, if needed) By using fully numeric BUILD_ALIAS values in the third digit instead of alphanumeric strings in the 4th, we could potentially use Nexus more easily. So, what if a component is already on 1.5.100? Well, we'd upversion it to 1.5.151 (Beta1). If it's already on 1.9.3, it'd be moved to 1.9.351. I've added this notion to my PR: https://github.com/jbosstools/jbosstools-freemarker/pull/54 So, we have {code} <version>1.5.1$\{BUILD_ALIAS}</version> with <BUILD_ALIAS>51</BUILD_ALIAS>{code} when I build like this: {code}mvn clean install -DBUILD_ALIAS=51{code} Maven throws some warnings about nesting a variable in the version field, but it builds fine. was (Author: nickboldt): To get value out of deploying JBT components' update sites to Nexus, a) component leads need to upversion their x.y.z+1 (3rd digit) for every milestone release, eg., in a task JIRA like JBIDE-20947 b) component leads need to ensure that every time they upversion and their Nexus URL changes, they submit a PR against jbosstools-build to change the URL in the parent pom. This will ensure all projects downstream use their correct latest bits c) releng & QE need tools to audit when a component lead forgets to do (a) and (b) d) releng & QE need tools to audit contents of JBT/JBDS update sites, since we will no longer be able to just visually inspect the list of features [1] to ensure they all have the same BUILD_ALIAS [1] http://download.jboss.org/jbosstools/mars/snapshots/updates/core/4.3.mars... ----- We could adopt a numerical convention that mimics Alpha/Beta/CR/Final nomenclature. For example... instead of having a project versioned with: * 4.3.0.Alpha1 * 4.3.0.Alpha2 * 4.3.0.Beta1 * 4.3.0.Beta2 * 4.3.0.CR1 * 4.3.0.Final/GA we might use * 4.3.011 (1 = Alpha, 11 = Alpha1) * 4.3.012 * 4.3.051 (5 = Beta, 51 = Beta1) * 4.3.052 * 4.3.091 (9 = CR/Final/GA) * 4.3.092 then for 4.3.1 maintenance... * 4.3.151 (51 = Beta1) * 4.3.152 (52 = Beta2) * 4.3.191 (91 = CR1) * 4.3.192 (92 = CR2, if needed) By using fully numeric BUILD_ALIAS values in the third digit instead of alphanumeric strings in the 4th, we could potentially use Nexus more easily. So, what if a component is already on 1.5.100? Well, we'd upversion it to 1.5.151 (Beta1). If it's already on 1.9.3, it'd be moved to 1.9.351. Only thing I need to verify w.r.t. this plan is if we can set a <version>1.5.1$\{BUILD_ALIAS}</version> with <BUILD_ALIAS>51</BUILD_ALIAS> and have maven not complain about the idea of nesting a variable in the version field. > 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, 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 November 2015