June 2016 - jbosstools-dev - Jboss List Archives

Refactoring openshift-restclient-java to depend upon OkHttp client

by Jeff Cantrill

The current release of the openshift-restclient-java, for not so obvious reasons, depends on no less then 3 libraries to provide the underlying communication to the cluster server. The following PR https://github.com/openshift/openshift-restclient-java/pull/179 unifies this dependency to a single client which is based on OkHttp. We are looking to make this change to: * Provide a common way to make REST calls * Simplify the authorization semantics to an openshift cluster * Simplify the pattern of making REST calls over what is done today * In future, take advantage of its SPDY support to move away from the oc binary dependency * Put us in a better position to move to the Fabric8 client (if that ever happens) Any comments or objects are welcome -- -- Jeff Cantrill Senior Software Engineer, Red Hat Engineering OpenShift Integration Services Red Hat, Inc. *Office*: 703-748-4420 | 866-546-8970 ext. 8162420 jcantril(a)redhat.com http://www.redhat.com

7 years, 9 months

4
6
0 / 0

[aeri] Weekly JBoss Tools Error Reports Digest

by Automated Error Reporting Bot

7 years, 9 months

1
0
0 / 0

Intention to remove "Server Log View"

by Robert Stryker

Hey all: https://issues.jboss.org/browse/JBIDE-22635 The Server Log View had a pretty complicated API, meant to look like the Error Log View, but with some additional mechanisms for sorting the events or providing icons for the various events. In all honesty, it was poorly-conceived from the beginning. Anything that should be logged there should really be logged in the error-log view anyway, so other than that, it's only useful feature was more of a tracing / logging mechanism that would be less annoying to the user. In fact, it's been found to have been used less often than it should be, and used inconsistantly. As far as I can tell, no other plugins other than AS Tools are using it, and some other server adapters have requested the action be removed (since they're not using the API to log events, it's basically useless to them). Anyway, I think it'd make the most sense to remove it. I don't think it's saveable really ;) Any thoughts or objections? - Rob

7 years, 9 months

5
4
0 / 0

ACTION REQUIRED: Migration to jgit timestamps and sprint-based fixversions

by Nick Boldt

In the next week, we'll be making some changes to the way the parent pom and JIRA work for you. -- a) jgit timestamps Instead of a BUILD_ALIAS like Alpha1 or Beta1, which forces users to download a whole JBT or devstudio install each time we release a new milestone, plugins and features will soon use the timestamp of their last change in github. Note that two plugins will continue to have a BUILD_ALIAS applied: foundation.core & devstudio.central, which define the version of JBoss Tools / devstudio used by ide-config.properties to assign the correct URLs for Central and quickstarts. But as you'll see below, we will start using Sprint numbers here instead of quality labels like Alpha or Beta. This change will roll out next week once we're done with the Jun 27 release. ACTION REQUIRED: Now, when you're building locally, you will need to *check in your changes* (to your local github clone, not to origin!) in order to ensure that your local changes are seen as "newer" than the stuff available on download.jboss.org, or in your ~/.m2/repo. Ref: https://issues.jboss.org/browse/JBIDE-13671 -- b) sprint-based fixversions Because we no longer need to do the waterfall method of Alpha -> Beta -> CR -> Final, we will now start defining fixversions in JIRA using the sprint numbers, S116, S117, S118, etc. I've for the moment left the .Final and .GA fixversions in place for two reasons: * because we need .GA in order to allocate issues to Target Releases in the JBDS JIRA * because this lets you differentiate between things completed for the Final/GA release vs. things simply completed in a sprint. This change has already been done, in order to see the impact on downstream processes like jiralint. I've also renamed the sprints so that they include their start/end dates, rather than just "June 2016" because I figured that was more meaningful. Dates format is yyyy/mm/dd - mm/dd. You can see this on a board such as https://issues.jboss.org/secure/RapidBoard.jspa?rapidView=3410&view=plann... ACTION REQUIRED: Nothing. Ref: https://issues.jboss.org/browse/JBIDE-22619 -- If you have any concerns about these changes, please post them on the associated JIRAs: -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

7 years, 10 months

4
7
0 / 0

Docker Tooling for Eclipse Neon Webinar - June 23 9AM EST

by Xavier Coulon

Hello, Today at 9am EST I'll present the Docker tooling that ships in Eclipse Neon. If you're interested in discovering what kind of tooling we built for Docker and how to use it, feel free to join by registering on https://www.eclipse.org/community/webinars/ <https://www.eclipse.org/community/webinars/> Best regards, Xavier

7 years, 10 months

1
0
0 / 0

Upcoming change in test lookups during Maven builds

by Fred Bricon

Team, we're about to modify the default pattern that determines which tests are running in tycho builds [1]. It currently searches for these patterns: <includes> <include>**/AllTests.class</include> <include>**/*AllTests*.class</include> <include>**/*AllBotTests*.class</include> <include>**/*TestSuite*.class</include> </includes> Instead, we'll move back to using surefire's default patterns (**/Test*.java, **/*Test.java, **/*TestCase.java) The main driver for this change is we currently have tests not referenced in test suites, that are not run during CLI builds [2], which is bad. So, to all component leaders, please verify, once this changes is applied, whether: - new tests are run and fail the build, in which case you need to fix them - tests are gone missing from the CI build, in which case, their classes need to be renamed following surefire's syntax. If you find regressions requiring significant changes in your component, you can apply the original pattern to the tycho-surefire-plugin configuration of your component pom.xml [1] https://issues.jboss.org/browse/JBIDE-19081 [2] https://issues.jboss.org/browse/JBIDE-22449 Fred

7 years, 10 months

1
0
0 / 0

[aeri] Adding two new resolutions for "Invalid / Won't Do"

by Marcel Bruch

Hi, we recently added two new problem resolutions to allow expressing that a problem report (i) is actually not a bug but rather a log message, and (ii) is not caused by JBoss Tools and cannot be fixed within JBoss Tools code (e.g., when the bug is located the Eclipse code base): "Log Message” and "Not JBoss”. Please consider using those resolutions instead of “Invalid” or “Won’t do” in future and were appropriate. Thank you. Marcel

7 years, 10 months

2
1
0 / 0

[aeri] Weekly JBoss Tools Error Reports Digest

by Automated Error Reporting Bot

7 years, 10 months

1
0
0 / 0

[aeri] Weekly JBoss Tools Error Reports Digest

by Automated Error Reporting Bot

7 years, 10 months

1
0
0 / 0

Re: [jbosstools-dev] 4.60.0.Final TP issue - two different versions of org.eclipse.egit.ui.smartimport

by Nick Boldt

Forwarding to larger audience. Since generally no one tries to install the whole TP concurrently, and since p2 remediation will allow users to install just the latest egit.ui.smartimport, I don't think this is a blocker. But it speaks to a problem with our new automated approach to TP verification via Jenkins jobs and p2diff files. Evidently they're not working. Or perhaps everyone is assuming everyone else is checking them, and in reality, no one is. I've opened https://issues.jboss.org/browse/JBIDE-22611 to track this issue, linked to the JIRA for our Neon.1 TP updates. Nick On Thu, Jun 16, 2016 at 2:05 PM, Paul Leacu <pleacu(a)redhat.com> wrote: > > Hey Nick - > Just stumbled across this: > > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/... > https://repository.jboss.org/nexus/content/groups/public/org/jboss/tools/... > > org.eclipse.egit.ui.smartimport is defined twice with two different versions: > > [ERROR] Resolution failed: > [ERROR] Software being installed: org.eclipse.egit.ui.smartimport 4.4.0.201606011500-rc2 > [ERROR] Software being installed: org.eclipse.egit.ui.smartimport 4.4.0.201606070830-r > [ERROR] Only one of the following can be installed at once: [org.eclipse.egit.ui.smartimport 4.4.0.201606070830-r, org.eclipse.egit.ui.smartimport 4.4.0.201606011500-rc2] > > --paull -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

7 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jbosstools-dev June 2016