October 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-23212) move to tycho 0.27.0 (mvn clean verify checks old features versions against baseline)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23212?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23212: ------------------------------- Fix Version/s: (was: 4.4.x) > move to tycho 0.27.0 (mvn clean verify checks old features versions against baseline) > ------------------------------------------------------------------------------------- > > Key: JBIDE-23212 > URL: https://issues.jboss.org/browse/JBIDE-23212 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.Final > Reporter: Jeff MAURY > Assignee: Nick Boldt > Labels: build, tycho > Fix For: 4.4.3.AM1, 4.5.0.AM1 > > > The check with baseline seems broken to me as it does not seem to work with features. When feature.source is checked, the baseline artifact (feature.source.jar) is compared to the wrong artifact (feature.jar). > I reproduced the problem by updating jbosstool-central root POM (only the parent POM version has been changed) and the mvn verify build failed on org.jboss.tools.maven.feature. The output can be seen in one of the PR check -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-23212) move to tycho 0.27.0 (mvn clean verify checks old features versions against baseline)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-23212?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-23212: ------------------------------- Fix Version/s: 4.4.3.AM1 > move to tycho 0.27.0 (mvn clean verify checks old features versions against baseline) > ------------------------------------------------------------------------------------- > > Key: JBIDE-23212 > URL: https://issues.jboss.org/browse/JBIDE-23212 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.4.1.Final > Reporter: Jeff MAURY > Assignee: Nick Boldt > Labels: build, tycho > Fix For: 4.4.3.AM1, 4.5.0.AM1 > > > The check with baseline seems broken to me as it does not seem to work with features. When feature.source is checked, the baseline artifact (feature.source.jar) is compared to the wrong artifact (feature.jar). > I reproduced the problem by updating jbosstool-central root POM (only the parent POM version has been changed) and the mvn verify build failed on org.jboss.tools.maven.feature. The output can be seen in one of the PR check -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20034) Should repository-utils:generate-repository-facade generate files and then use additionalFileSets configuration?

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20034?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-20034: ------------------------------------ [~dgolovin] can you explain what making this change would fix, or improve? Tempted to close this as won't fix since it's been sitting idle for over a year. > Should repository-utils:generate-repository-facade generate files and then use additionalFileSets configuration? > ---------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-20034 > URL: https://issues.jboss.org/browse/JBIDE-20034 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Denis Golovin > Assignee: Nick Boldt > Priority: Minor > Fix For: 4.4.x > > > Explanation how to use is here https://bugs.eclipse.org/bugs/show_bug.cgi?id=424691. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18985) provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18985?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-18985. ------------------------------ Resolution: Won't Fix Won't fix, because we use jgit timestamps now, so there are no more BUILD_ALIAS occurrences left (except in a few select places). > provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated > ----------------------------------------------------------------------- > > Key: JBIDE-18985 > URL: https://issues.jboss.org/browse/JBIDE-18985 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build, updatesite > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.Final > > > Based on discussion {quote}Do you have a test for "expected BUILD_ALIAS value in feature qualifiers" ?{quote} > Some tests we can run (forgive this pseudocode): > {code} > // for builds up to a x.y.0 release > if ((BUILD_ALIAS in (Alpha*, Beta*, CR*) and jbosstools.version endsWith(".0")) { > // make sure all features end in the same BUILD_ALIAS, or Final > // if anything doesn't match WARN (want a build to be yellow, not red) > } > {code} > {code} > // for GA builds and followup maintenance > if ((BUILD_ALIAS in (Final, GA)) { > // make sure all com.* features end in GA, and all others end in Final > // if anything doesn't match FAIL (want a build to be red) > } > {code} > Once we have that coded, perhaps into a maven enforcer plugin?, we can fine tune it for cases like where Freemarker does an update in Alpha and then does nothing for 4 months, waiting for CR/GA. > Should they have to keep updating their root pom just so the BUILD_ALIAS matches and they're building against the correct target platform? > Or, should their code remain dormant, but their job's config.xml be updated to override the BUILD_ALIAS & TARGET_PLATFORM values to the correct versions? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-18985) provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18985?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-18985: ------------------------------- Fix Version/s: 4.4.1.Final (was: 4.3.x) > provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated > ----------------------------------------------------------------------- > > Key: JBIDE-18985 > URL: https://issues.jboss.org/browse/JBIDE-18985 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build, updatesite > Affects Versions: 4.3.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.1.Final > > > Based on discussion {quote}Do you have a test for "expected BUILD_ALIAS value in feature qualifiers" ?{quote} > Some tests we can run (forgive this pseudocode): > {code} > // for builds up to a x.y.0 release > if ((BUILD_ALIAS in (Alpha*, Beta*, CR*) and jbosstools.version endsWith(".0")) { > // make sure all features end in the same BUILD_ALIAS, or Final > // if anything doesn't match WARN (want a build to be yellow, not red) > } > {code} > {code} > // for GA builds and followup maintenance > if ((BUILD_ALIAS in (Final, GA)) { > // make sure all com.* features end in GA, and all others end in Final > // if anything doesn't match FAIL (want a build to be red) > } > {code} > Once we have that coded, perhaps into a maven enforcer plugin?, we can fine tune it for cases like where Freemarker does an update in Alpha and then does nothing for 4 months, waiting for CR/GA. > Should they have to keep updating their root pom just so the BUILD_ALIAS matches and they're building against the correct target platform? > Or, should their code remain dormant, but their job's config.xml be updated to override the BUILD_ALIAS & TARGET_PLATFORM values to the correct versions? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-15481) setup of vwatch for jboss tools installations

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-15481?page=com.atlassian.jira.plugi... ] Nick Boldt closed JBIDE-15481. ------------------------------ Fix Version/s: 4.4.1.Final (was: 4.3.x) Resolution: Out of Date CLosing as out of date. we have baseline mojo checks and devstudio versionwatch, so no need to run versionwatch for JBT as well. > setup of vwatch for jboss tools installations > --------------------------------------------- > > Key: JBIDE-15481 > URL: https://issues.jboss.org/browse/JBIDE-15481 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Reporter: Max Rydahl Andersen > Assignee: Nick Boldt > Fix For: 4.4.1.Final > > Attachments: jbide15481.png > > > 1. use the install robot and then run versionwatch aginst JBoss Tools install with all of central content installed. > usecases: > * find missing/weird versions > * duplicate components > * get list of potential unnecessary plugins in TP > 2. document how to do installs for Eclipse, JBT or JBDS BYOE via commandline for setting up the footprint of installs against which to do baseline version watches – pre-existing doc here: > http://download.jboss.org/jbosstools/updates/scripted-installation/ > https://devstudio.redhat.com/download/scripted-install/ > 3. test #2 to ensure it works, and that a mix of "studio" and "eclipse" folders can be used in a vwatch report > 4. create new jobs (or extend existing ones) to provide reports about JBT, JBT+Central, JBT+Central+EA; repeat for JBDS combinations. Maybe migrate jobs to matrixes? > Additionally, now that jbdevstudio-qa/vwatch has moved to jbosstools-versionwatch, we should also do these two things: > 5. remove all refs to QA Jenkins file paths to make *.sh scripts more generic > 6. migrate those internal file paths into jenkins config.xml files so they're not stored in public repos -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-13286) jobs should generate comment in JIRA recording job URL, BUILD#, and more detailed commit info (committer + comments)

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-13286?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-13286: ------------------------------- Fix Version/s: LATER (was: 4.3.x) > jobs should generate comment in JIRA recording job URL, BUILD#, and more detailed commit info (committer + comments) > -------------------------------------------------------------------------------------------------------------------- > > Key: JBIDE-13286 > URL: https://issues.jboss.org/browse/JBIDE-13286 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.1.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Priority: Optional > Fix For: LATER > > > Is it possible to pull the git hash value used for a given build, look into github for the matching JIRA #, and drop a comment into the JIRA to the tune of: > "Spinning in <buildURL> >= BUILD_NUMBER" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20046) create jiralint-like notifier that can alert if changes in a branch have not been built after X days

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20046?page=com.atlassian.jira.plugi... ] Nick Boldt updated JBIDE-20046: ------------------------------- Fix Version/s: 4.4.x (was: 4.3.x) > create jiralint-like notifier that can alert if changes in a branch have not been built after X days > ---------------------------------------------------------------------------------------------------- > > Key: JBIDE-20046 > URL: https://issues.jboss.org/browse/JBIDE-20046 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.4.x > > > Suggested by [~rob.stryker] to avoid having situations where jobs are disabled because no one is maintaining the code & we end up with something like JBIDE-20041, where last year's Freemarker is included in JBT 4.3.0.Beta1 instead of the latest stuff. > {quote} > [10:36:50 AM] Rob Stryker: would it be possible to make a script that runs once a week checking for commits and firing emails indicating the jobs should be re-enabled? > [10:37:50 AM] Rob Stryker: if job is enabled, dont even bother to check/notify > [10:37:57 AM] Rob Stryker: if job is disabled, then check for new commits > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20046) create jiralint-like notifier that can alert if changes in a branch have not been built after X days

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20046?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-20046: ------------------------------------ one part of this was done as part of https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u... the rest is in https://github.com/jbosstools/jbosstools-build-ci/blob/jbosstools-4.4.x/u... But as to jiralint-like spam to warn when changes haven't been built or commits were not pushed to all appropriate branches, that's not in place yet. Perhaps [~rob.stryker] has time to work on this? > create jiralint-like notifier that can alert if changes in a branch have not been built after X days > ---------------------------------------------------------------------------------------------------- > > Key: JBIDE-20046 > URL: https://issues.jboss.org/browse/JBIDE-20046 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: build > Affects Versions: 4.3.0.Beta1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 4.3.x > > > Suggested by [~rob.stryker] to avoid having situations where jobs are disabled because no one is maintaining the code & we end up with something like JBIDE-20041, where last year's Freemarker is included in JBT 4.3.0.Beta1 instead of the latest stuff. > {quote} > [10:36:50 AM] Rob Stryker: would it be possible to make a script that runs once a week checking for commits and firing emails indicating the jobs should be re-enabled? > [10:37:50 AM] Rob Stryker: if job is enabled, dont even bother to check/notify > [10:37:57 AM] Rob Stryker: if job is disabled, then check for new commits > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 5 months

1
0
0 / 0

[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 updated JBDS-3191: ----------------------------- Fix Version/s: 10.1.0.GA (was: 9.x) > 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

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