codefreeze is up but filter=ds_next_master_unresolved still shows 90+
I'm going through picking off the obvious ones but please do not forget
to clear out jira for the alpha1 release.
I'm posting on behalf of Andre that we are need to add new openshift v3
feature to JBoss Tools and eventually devstudio.
This new feature (called: org.jboss.tools.openshift.feature) is what
will provide OpenShift v3 features.
The old v2 feature called org.jboss.tools.openshift.express.feature
will continue to exist and be relevant to support v2.
One tricky matter is that openshift v3 is still actively moving thus for
now we are making the V3 and V2 install separately available features in
case v3 will end up not being fully supported/completed when we go
Thus I suggest that for Alpha1:
Add org.jboss.tools.openshift.feature to JBoss Tools and its openshift
*after* Alpha1 after some feedback and stability add it to devstudio.
Central Jira for this is at
If you haven't tried Eclipse Mars M5 yet you probably haven't heard or
tried oomph yet.
oomph does a bunch of things regarding making eclipse easier to install
One of them is managing preferences between multiple workspaces - i'm
not super fan of the UI oomph have so far, but the idea behind it is
good enough. It listens to preference changes and ask the user if a
certain preference should be applied to all your other workspaces. If
yes - it will apply them on your next workspace start.
That is all fine and well, but some of the properties just don't make
sense for users to be notified about - for example our usage tracking is
stored in preferences; not something that makes sense for oomph to care
That is now fixed in M6
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=459455) after I raised
But do please keep an eye on oomph and check if it asks for properties
you think are irrelevant or bad that we should get fixed on oomph side.
And of course - if you see other issues with oomph do open bugs on
bugs.eclipse.org so Eclipse Mars will get something better not worse ;)
It probably should have happened ages ago  but now its there via
Mockito is now available in master of jboss tools core target platform.
Meaning you can now use mocks in your tests without custom
We do have other mocking frameworks in play, but please consider using
instead of something custom going forward.
Mind you that we are using a fork of Mockito to work around limit of
what happens when
you have multiple versions of a binary loaded in the IDE - but if you
don't have that
you shouldn't care ;)
You can read more about mockito at http://mockito.org/ or google
"eclipse mockito" to have fun with
the subtleties osgi gives you ;)
 I'll explain why mockito with osgi sucks over a beer :)
Here is a proposal for a change to the JBoss Tools4.50.0.Alpha1-SNAPSHOT target platform, for JBoss Tools 4.3.0.Alpha1:
It consists in the following changes:
* JBIDE-19174: Mars M5
p2diff reports are attached to the related JIRA(s).
Please review the above PR(s), as it will be applied ASAP.
You can use the following to build & test the target-platform locally against your component(s).
$ cd jbosstools-target-platforms
$ git fetch origin pull/125/head
$ git checkout FETCH_HEAD
$ cd jbosstools/multiple
$ mvn clean install
Try with just built target-platform:
$ cd /path/to/your/component
$ mvn clean verify -Dtpc.version=4.50.0.Alpha1-SNAPSHOT -Pmultiple.target
In https://issues.jboss.org/browse/JBDS-3261 a new 'websocket's
component was created to categorize for now two jiras.
We do not plan or have intent on making a specific 'websockets' feature
(yet) and if we did it would probably end up in the webservices
component + more components = more manual updating of scripts relying on
component names :)
Thus I talked with Xavier and agreed on just continue using labels to
mark what kind of webservices a jira refer to.
Thus I deleted the 'websockets' component and added 'websockets' label
If we actually start doing/planning websocket feature work we can
I've made a comment over on https://issues.jboss.org/browse/JBIDE-18709
investigating the issue of anonymous downloads as it pertains to alpha
releases, stacks, and JBT as a group.
It'd be good if those addressed directly above (david, rafael) had a
look just so that everyone's aware of the issues of adding any Alpha
release to JBoss Stacks.
The tl;dr of it is: if we do add alpha releases to stacks, we must
still use the jdf URL, and we must still set requiresCredentials=true,
even though it's not accurate. Otherwise we risk breaking older releases
Any questions or comments are welcome and encouraged on the jira issue
Thanks in advance.
- Rob Stryker