May 2016 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-22355) Build qualifier still say Alpha2

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22355?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22355: ------------------------------------ TL;DR: Let's stop using BUILD_ALIAS entirely for component jobs, and use BUILD_ALIAS as a suffix qualifier for JBT/DS deliverables only. Discussion: +1 for the idea of all local builds having a BUILD_ALIAS = SNAPSHOT, and for Jenkins-based builds, we set BUILD_ALIAS={the actual quality we think we're doing*} where * = Alpha1, Beta1, CR1, Final/GA Since the quality is entirely arbitrary based on our own "feelings" of how well we're doing (much like Early Access vs. Supported), we can change the BUILD_ALIAS across all components as we move from Alpha to Beta to CR to Final phases of development. These phases could be hardcoded dates (like we did for JBDS 9 and 9.1) or they could be on-the-fly declarations a few days before the Thursday night build. But then again, if we're TRULY being agile, we're ALWAYS Final, because each sprint releases something that's stable enough to not break previous. We're always incrementally improving, but never by releasing something that's broken/unsupported. If it's unsupported, it's unreleased (and perhaps in a topic branch until it's ready to merge to master). Thus... if quality statement is moot because We're Agile now, we could eliminate the BUILD_ALIAS entirely, and just move to using timestamps, as we used to Back In The Day and how I used to build all the Modeling projects at Eclipse. {quote}not sure how we then actually keep track of when something is Final vs just intermediate builds.{quote} We will have a buildinfo.json for the build we declare is 10.0.0.GA or 4.4.0.Final. That will be the Final one; everything else is just an intermediate toward that release. Similarly, if we decide the build to be released publicly in June is to be called Alpha3, then that Alpha3 build will contain a buildinfo.json file, which can be used to create all the Alpha3 tags. --- To address the issue of "building locally against the latest local/remote content"... whether we use a BUILD_ALIAS or not, here's the workflow: a) build Openshift locally using `mvn verify`. maven fetches latest Base and Server from remote, caches them in ~/.m2 b) fix a bug in Openshift & rebuild locally using `mvn verify`. If using `-o`, use only offline stuff. If using `-U`, fetch from remote again looking for updated snapshots. If using `-Dtycho.localArtifacts=ignore` ignore ANY local artifacts in your ~/.m2 in favour of re-fetching stuff from remote. (Ref: https://github.com/jbosstools/jbosstools-devdoc/blob/master/building/buil... ) c) realize there's a bug in Server! So, rebuild Server locally using `mvn *install*` instead of `mvn verify` to publish those bits into your local ~/.m2 d) rebuild Openshift locally. This time, your locally installed Server bits will WIN against anything remote. Hooray! You fixed the bug and verified your fix locally. e) submit PR against Server. Wait for review. f) PR is pushed; Server is rebuilt in Jenkins g) rebuild Openshift locally. This time, your locally installed Server bits will LOSE against the new remote bits, because the timestamp is newer on remote than in your local repo. No ~/.m2 cache cleanup needed. If you have locally built bits with BUILD_ALIAS = Alpha1 in them and there's remote BUILD_ALIAS = Alpha2 bits, those remote bits will ALWAYS win because of OSGi qualifier rules. So to create local bits that win against the remote stuff, you need a newer BUILD_ALIAS = Alpha2. For JBDS 9.x, this was achieved by setting your root pom to use the latest Alpha2 parent pom, and the parent pom would hardcode the BUILD_ALIAS = Alpha2. But if we eliminate BUILD_ALIAS entirely, timestamp-based sequencing will still work - that's just how OSGi works. And if we want to continue to use BUILD_ALIAS for the things we actually release (aggregate update sites/zips, standalone browsersim, source zips, installers, etc.), we can totally still do that either in Jenkins or as part of the staging/release process. So when QE and Dev are working together, they would be referencing specific builds (eg., rather than "the B123 Alpha1 CI build of Server", it would just be "the B123 CI build of Server"). When QE and releng are working together, they would be referencing specific builds (eg., "the B234 Alpha1 JBT/devstudio staging builds" or the "Alpha1 JBT/devstudio released builds"). When releng and PgM are working together, they would be referencing specific builds (eg., "the B234 Alpha1 devstudio staging build" or the "Alpha1 devstudio released build"). Since BUILD_ALIAS is now only a cosmetic / productization label, I would suggest if we intend to keep using it for aggregates and products, we use it as a qualifier *SUFFIX* instead of a *PREFIX* so people get used to timestamps as the OSGi sequencer, NOT the BUILD_ALIAS label. And of course once something goes to CSP, we would continue to use ONLY the BUILD_ALIAS, hiding the internal detail of timestamp. > Build qualifier still say Alpha2 > -------------------------------- > > Key: JBIDE-22355 > URL: https://issues.jboss.org/browse/JBIDE-22355 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: build > Reporter: Mickael Istria > Assignee: Nick Boldt > Priority: Critical > Fix For: 4.4.0.Alpha2 > > > Build qualifiers, parent pom version, and version of parent pom referenced by components are still Alpha1. > All those should be moved to Alpha2 (they should be moved just when branching/releasing actually) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22372) Publish CI snapshots to a directory containing BUILD_ALIAS

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22372?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-22372: ---------------------------------------- Yeah, instead of a "stream" we would have a "targetRelease" property that could contain the full version with a version such as 4.4.0.Alpha2 > Publish CI snapshots to a directory containing BUILD_ALIAS > ---------------------------------------------------------- > > Key: JBIDE-22372 > URL: https://issues.jboss.org/browse/JBIDE-22372 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > > To avoid even more "crossing streams", we could consider also adding the BUILD_ALIAS to the URL of snapshots sites produced by CI. An advantage is that building a new version wouldn't require to cleanup the /4.4.neon branch for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22372) Publish CI snapshots to a directory containing BUILD_ALIAS

by Nick Boldt (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22372?page=com.atlassian.jira.plugi... ] Nick Boldt commented on JBIDE-22372: ------------------------------------ Other than the problem with bootstrapping the first time (eg., someone fires the Server build before the Base one is done), which will create a whole bunch of false-failures (easily solved by ignoring them and kicking a buildflow job to orchestrate the jobs in the correct sequence)... +100. This would get away from having a "stream" value of "4.4.neon" or "10.0.neon", and instead we could combine version (4.4/10.0) w/ BUILD_ALIAS when doing staging/publishing/promoting. Would need some reworking of the various publish scripts but I like this idea because we could publish to /staging/4.4.0.Alpha2 even if the parent pom was still at Alpha1. > Publish CI snapshots to a directory containing BUILD_ALIAS > ---------------------------------------------------------- > > Key: JBIDE-22372 > URL: https://issues.jboss.org/browse/JBIDE-22372 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > > To avoid even more "crossing streams", we could consider also adding the BUILD_ALIAS to the URL of snapshots sites produced by CI. An advantage is that building a new version wouldn't require to cleanup the /4.4.neon branch for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22372) Publish CI snapshots to a directory containing BUILD_ALIAS

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22372?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-22372: ---------------------------------------- [~nickboldt] For your consideration. I believe too much separation is better that not enough ;) > Publish CI snapshots to a directory containing BUILD_ALIAS > ---------------------------------------------------------- > > Key: JBIDE-22372 > URL: https://issues.jboss.org/browse/JBIDE-22372 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > > To avoid even more "crossing streams", we could consider also adding the BUILD_ALIAS to the URL of snapshots sites produced by CI. An advantage is that building a new version wouldn't require to cleanup the /4.4.neon branch for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22372) Publish CI snapshots to a directory containing BUILD_ALIAS

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22372?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-22372: ----------------------------------- Story Points: 3 > Publish CI snapshots to a directory containing BUILD_ALIAS > ---------------------------------------------------------- > > Key: JBIDE-22372 > URL: https://issues.jboss.org/browse/JBIDE-22372 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > > To avoid even more "crossing streams", we could consider also adding the BUILD_ALIAS to the URL of snapshots sites produced by CI. An advantage is that building a new version wouldn't require to cleanup the /4.4.neon branch for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22372) Publish CI snapshots to a directory containing BUILD_ALIAS

by Mickael Istria (JIRA)

Mickael Istria created JBIDE-22372: -------------------------------------- Summary: Publish CI snapshots to a directory containing BUILD_ALIAS Key: JBIDE-22372 URL: https://issues.jboss.org/browse/JBIDE-22372 Project: Tools (JBoss Tools) Issue Type: Enhancement Components: build Reporter: Mickael Istria To avoid even more "crossing streams", we could consider also adding the BUILD_ALIAS to the URL of snapshots sites produced by CI. An advantage is that building a new version wouldn't require to cleanup the /4.4.neon branch for example. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-20737) On Linux, non-root user is not able to use auto-detect to access running Docker instance

by Martin Malina (JIRA)

[ https://issues.jboss.org/browse/JBIDE-20737?page=com.atlassian.jira.plugi... ] Martin Malina commented on JBIDE-20737: --------------------------------------- [~maxandersen], I think the request was to offer some clear guidance for the user. You're right that if you don't have access in CLI, then Eclipse won't be able to connect either. But it's good to show a reasonable message - the docker daemon will be detected and the fields filled for you (at least I think that's the case), but it won't work. > On Linux, non-root user is not able to use auto-detect to access running Docker instance > ----------------------------------------------------------------------------------------- > > Key: JBIDE-20737 > URL: https://issues.jboss.org/browse/JBIDE-20737 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: docker > Affects Versions: 4.3.0.CR1 > Environment: RHEL 7 > OpenJDK 1.8 > Version: 9.0.0.CR1 > Build id: CR1-v20150912-1100-B100 > Build date: 20150912-1100 > CR1 includes: > com.spotify.docker.client_3.1.1.jar > org.eclipse.linuxtools.docker.core_1.1.0.201509082008.jar > org.eclipse.linuxtools.docker.docs_1.1.0.201509082008.jar > org.eclipse.linuxtools.docker.ui_1.1.0.201509082008.jar > Reporter: Len DiMaggio > Assignee: Xavier Coulon > Fix For: 4.4.x > > Attachments: nonroot_1.png, nonroot_2.png, nonroot_3.png, root.png > > > On linux, a root user is able to rely on autoconnect to automatically connect to a running Docker instance (at unix:///var/run/docker.sock) > A non-root user is not able to connect. No warning or error is written to the UI/dialog. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3787) Installer - Installation of each component should be optional

by Josephine Qian (JIRA)

[ https://issues.jboss.org/browse/JBDS-3787?page=com.atlassian.jira.plugin.... ] Josephine Qian commented on JBDS-3787: -------------------------------------- [~dgolovin] Please take a look at the attachment and let me know what you think about this solution. I added some explanations for different conditions, hope that will help you understand the wireframes. Let me know if you have any questions about the design. > Installer - Installation of each component should be optional > ------------------------------------------------------------- > > Key: JBDS-3787 > URL: https://issues.jboss.org/browse/JBDS-3787 > Project: Red Hat Developer Studio (DevStudio) > Issue Type: Feature Request > Components: platform-installer > Affects Versions: 9.1.0.GA > Reporter: Len DiMaggio > Assignee: Denis Golovin > Labels: havoc > Fix For: 10.0.0.Alpha3 > > Attachments: components are optional v1.png > > > Feature request - It would be ideal of the installer allowed to the user to select to install/not install any of the installer's components (JDK, CDK, etc.) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBDS-3787) Installer - Installation of each component should be optional

by Josephine Qian (JIRA)

[ https://issues.jboss.org/browse/JBDS-3787?page=com.atlassian.jira.plugin.... ] Josephine Qian updated JBDS-3787: --------------------------------- Attachment: components are optional v1.png > Installer - Installation of each component should be optional > ------------------------------------------------------------- > > Key: JBDS-3787 > URL: https://issues.jboss.org/browse/JBDS-3787 > Project: Red Hat Developer Studio (DevStudio) > Issue Type: Feature Request > Components: platform-installer > Affects Versions: 9.1.0.GA > Reporter: Len DiMaggio > Assignee: Denis Golovin > Labels: havoc > Fix For: 10.0.0.Alpha3 > > Attachments: components are optional v1.png > > > Feature request - It would be ideal of the installer allowed to the user to select to install/not install any of the installer's components (JDK, CDK, etc.) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBIDE-22354) Remediation page showing up because of Mylyn Wikitext

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-22354?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-22354: ---------------------------------------- It's not really a bug in mylyn-asciidoc, it's a choice made by Mylyn to immediatly bump version of dependencies from mylyn-extras to mylyn and to not provide a Neon compatible release of mylyn-extras. It's not "just" a bug fix, it requires some agreement with the mylyn team. > Remediation page showing up because of Mylyn Wikitext > ----------------------------------------------------- > > Key: JBIDE-22354 > URL: https://issues.jboss.org/browse/JBIDE-22354 > Project: Tools (JBoss Tools) > Issue Type: Bug > Components: updatesite > Affects Versions: 4.4.0.Alpha2 > Reporter: Mickael Istria > Priority: Blocker > Fix For: 4.4.0.Alpha2 > > > Take an Eclipse JavaScript M7, and try to install all JBoss Tools from http://download.jboss.org/jbosstools/neon/snapshots/updates/ > It shows a remediation page because JBoss Tools ships an asciidoc feature which is in different version that the one upstream. -- 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