April 2015 - jbosstools-issues - Jboss List Archives

[JBoss JIRA] (JBIDE-19178) Explorer: Add "Pipeline" view to OpenShift v3 explorer

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19178?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-19178: ------------------------------------- Fix Version/s: 4.3.0.Beta1 (was: 4.3.0.Alpha2) > Explorer: Add "Pipeline" view to OpenShift v3 explorer > ------------------------------------------------------ > > Key: JBIDE-19178 > URL: https://issues.jboss.org/browse/JBIDE-19178 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift > Affects Versions: 4.3.0.Alpha1 > Reporter: Jeff Cantrill > Labels: explorer > Fix For: 4.3.0.Beta1 > > > Add an alternate view in the openshift v3 explorer to try to 'link' resources in a similiar fashion to the web console -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-19371) Allow OpenShiftRedirectionStrategy to determine the auth scheme

by Andre Dietisheim (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19371?page=com.atlassian.jira.plugi... ] Andre Dietisheim updated JBIDE-19371: ------------------------------------- Fix Version/s: 4.3.0.Beta1 (was: 4.3.0.Alpha2) > Allow OpenShiftRedirectionStrategy to determine the auth scheme > --------------------------------------------------------------- > > Key: JBIDE-19371 > URL: https://issues.jboss.org/browse/JBIDE-19371 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: openshift > Affects Versions: 4.3.0.Alpha2 > Reporter: Jeff Cantrill > Fix For: 4.3.0.Beta1 > > > Introducing an authorization client which is able to determine how to authenticate when it gets a 401 and includes the following headers: > (org.apache.http.Header[]) [Www-Authenticate: Basic realm="openshift", Date: Wed, 25 Feb 2015 20:11:49 GMT, Content-Length: 0, Content-Type: text/plain; charset=utf-8] > Add method to identify the auth scheme and return the realm. Update the 'canconnect' endpoint to use this function. > This was achieved by trying to auth with empty username and password -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-17686) get TCF and RSE terminals to coexist without bad UX of multiple terminals

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-17686?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-17686: ---------------------------------------- Isn't it automatically resolved since we now consume newer RSE in our target-platform? > get TCF and RSE terminals to coexist without bad UX of multiple terminals > ------------------------------------------------------------------------- > > Key: JBIDE-17686 > URL: https://issues.jboss.org/browse/JBIDE-17686 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: upstream > Affects Versions: 4.2.0.Beta2 > Reporter: Max Rydahl Andersen > Assignee: Nick Boldt > Priority: Minor > Fix For: 4.3.x > > Attachments: eclipse-can-has-many-consoles.png > > > luna has new Eclipse TCF terminal that brings better Terminal support. > I would assume it is in there but I couldn't find a way to actually open it. Maybe we havent included the full set of plugins. > http://marketplace.eclipse.org/content/tcf-terminals#.U6sJ92Vp7wV > http://eclipsesource.com/blogs/2014/06/17/tcf-terminal-top-eclipse-luna-f... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-18742) Only rely on rsync to publish new aggregate (remove other comparators)

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi... ] Mickael Istria commented on JBIDE-18742: ---------------------------------------- I'm taking this one and put it in my TODO-list for ASAP after Alpha2. > Only rely on rsync to publish new aggregate (remove other comparators) > ---------------------------------------------------------------------- > > Key: JBIDE-18742 > URL: https://issues.jboss.org/browse/JBIDE-18742 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.3.0.Beta1 > > > Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not. > It's more or less just a matter of scripting > {code:none} > p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot > if [[ -s p2diff_snapshot ]]; then > ./publish.sh > fi > {code} > Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-18742) Only rely on rsync to publish new aggregate (remove other comparators)

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi... ] Mickael Istria updated JBIDE-18742: ----------------------------------- Fix Version/s: 4.3.0.Beta1 (was: 4.3.0.Alpha2) > Only rely on rsync to publish new aggregate (remove other comparators) > ---------------------------------------------------------------------- > > Key: JBIDE-18742 > URL: https://issues.jboss.org/browse/JBIDE-18742 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.3.0.Beta1 > > > Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not. > It's more or less just a matter of scripting > {code:none} > p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot > if [[ -s p2diff_snapshot ]]; then > ./publish.sh > fi > {code} > Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-18742) Only rely on rsync to publish new aggregate (remove other comparators)

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBIDE-18742?page=com.atlassian.jira.plugi... ] Mickael Istria reassigned JBIDE-18742: -------------------------------------- Assignee: Mickael Istria (was: Nick Boldt) > Only rely on rsync to publish new aggregate (remove other comparators) > ---------------------------------------------------------------------- > > Key: JBIDE-18742 > URL: https://issues.jboss.org/browse/JBIDE-18742 > Project: Tools (JBoss Tools) > Issue Type: Enhancement > Components: build > Reporter: Mickael Istria > Assignee: Mickael Istria > Fix For: 4.3.0.Alpha2 > > > Instead of the composite-install test to decide whether we aggregate or not, it would be simpler to build aggregation in any case and then use p2diff (or other smart mechanism) to decide whether we want to publish the new composite or not. > It's more or less just a matter of scripting > {code:none} > p2diff file:${WORKSPACE}/results/${JOB_NAME}/all/repo/ http://download.jboss.org/jbosstools/builds/staging/${JOB_NAME}/all/repo/ | grep -e ^\< -e ^\> > p2diff_snapshot > if [[ -s p2diff_snapshot ]]; then > ./publish.sh > fi > {code} > Another benefit is that it allows us to get rid of the composite (1 less couple of files to maintain) -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBDS-3208) reorg/refactor directories for consistency across JBT/JBDS

by Mickael Istria (JIRA)

[ https://issues.jboss.org/browse/JBDS-3208?page=com.atlassian.jira.plugin.... ] Mickael Istria commented on JBDS-3208: -------------------------------------- What kind of sanity check does the composite provide? Are they really useful? IMO, it would be easier to always run aggregator than to keep this level of indirection that does not save time nor spot actual errors AFAIK. > reorg/refactor directories for consistency across JBT/JBDS > ---------------------------------------------------------- > > Key: JBDS-3208 > URL: https://issues.jboss.org/browse/JBDS-3208 > Project: Developer Studio (JBoss Developer Studio) > Issue Type: Bug > Components: build > Affects Versions: 9.0.0.Alpha1 > Reporter: Nick Boldt > Assignee: Nick Boldt > Fix For: 9.0.0.Alpha2 > > > Be it resolved - we should reorg directories for consistency across JBT/JBDS: > Latest suggestion: > * /\{mars,9.0}/ > ** /\{{color:red}snapshots{color},{color:orange}staging{color},{color:blue}development{color},{color:green}stable{color}\}/ > *** /*updates*/ > **** /\{requirements, jbosstoolstarget,jbdevstudiotarget, core,coretests,webtools,hibernatetools, discovery, central,earlyaccess, integration-stack,integration-stack-earlyaccess}/ > ***** /<build-version = 4.3.0.Alpha1, 4.3.0.Final, 4.41.\*, 4.50.\*...>/ > *** /*builds*/ > **** /<job-name>/ > ***** /{<pull-request-version = PR123, PR124, PR125...>, <build-version = B123, B124, B125...>}/ > --- > Older idea: > {code} > <download.jboss.org,devstudio.redhat.com> > <earlyaccess,updates,discovery>/<mars,9.0> > /snapshots [replace nightly] > /staging [rename content for QE, moves to development when approved] > /development > /stable (updates/<mars,9.0>/stable is a pointer back into parent folder so published URL can be simpler > drop /integration (not used) > builds/<jobname>/<buildid> > builds/<jobname>/composite*.xml for last N builds > targetplatforms/<type>/<version> > {code} > Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112 > This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970. > [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2.... > [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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: 4.3.x (was: 4.2.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: 4.3.x > > > 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.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-19345) allow NN to be filtered/redefined for NN

by Marián Labuda (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19345?page=com.atlassian.jira.plugi... ] Marián Labuda closed JBIDE-19345. --------------------------------- Verified. > allow NN to be filtered/redefined for NN > ---------------------------------------- > > Key: JBIDE-19345 > URL: https://issues.jboss.org/browse/JBIDE-19345 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: website > Reporter: Max Rydahl Andersen > Assignee: Xavier Coulon > Priority: Critical > Fix For: 4.2.3.Final > > > there been examples of auto aggregation of NN be a hit or miss for how much it makes sense in the release. > For example: > Beta1: Added a few components to the Ionic Palette: <c1> <c2> <c3> > Beta2: Added a few components to the Ionic: <c4> <c5> > Alexey Kazakov: But in the final verision I would like to have: Added new components: <c1>,...<c5>. > One suggestion been to have ability to rewrite the full NN version at final but I just know that will kill us becase it is going to be a pain to copy/paste right. > Alternative suggestion is: > A) during rendering of the "final" aggregation set a asciidoc variable (i.e. "finalnn") allowing us to use asciidoc conditionals like > {code} > ifndef::finalnn[] > This piece of news was only relevant for Beta1 > endif::finalnn[] > {code} > See: http://mrhaki.blogspot.ch/2014/08/awesome-asciidoc-using-conditional.html > B) allow to add a .Final newnoteworthy adoc to use as place to write the aggregated news ..note, these should still be merged with the former NN's. so you only need to write the sections that are actually different. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBIDE-19345) allow NN to be filtered/redefined for NN

by Marián Labuda (JIRA)

[ https://issues.jboss.org/browse/JBIDE-19345?page=com.atlassian.jira.plugi... ] Marián Labuda updated JBIDE-19345: ---------------------------------- Fix Version/s: (was: 4.3.0.CR1) > allow NN to be filtered/redefined for NN > ---------------------------------------- > > Key: JBIDE-19345 > URL: https://issues.jboss.org/browse/JBIDE-19345 > Project: Tools (JBoss Tools) > Issue Type: Feature Request > Components: website > Reporter: Max Rydahl Andersen > Assignee: Xavier Coulon > Priority: Critical > Fix For: 4.2.3.Final > > > there been examples of auto aggregation of NN be a hit or miss for how much it makes sense in the release. > For example: > Beta1: Added a few components to the Ionic Palette: <c1> <c2> <c3> > Beta2: Added a few components to the Ionic: <c4> <c5> > Alexey Kazakov: But in the final verision I would like to have: Added new components: <c1>,...<c5>. > One suggestion been to have ability to rewrite the full NN version at final but I just know that will kill us becase it is going to be a pain to copy/paste right. > Alternative suggestion is: > A) during rendering of the "final" aggregation set a asciidoc variable (i.e. "finalnn") allowing us to use asciidoc conditionals like > {code} > ifndef::finalnn[] > This piece of news was only relevant for Beta1 > endif::finalnn[] > {code} > See: http://mrhaki.blogspot.ch/2014/08/awesome-asciidoc-using-conditional.html > B) allow to add a .Final newnoteworthy adoc to use as place to write the aggregated news ..note, these should still be merged with the former NN's. so you only need to write the sections that are actually different. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years, 1 month

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 April 2015