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
9 years, 12 months
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
10 years
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
10 years
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
10 years
[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
10 years
