We currently have two plugins containing client jars for the various
wildfly / as7 versions. One plugin is named
org.jboss.ide.eclipse.as.management.as71, the other
As currently implemented, org.jboss.ide.eclipse.as.management.as71 holds
client jars that are used with as70, 71, eap6x, etc.
org.jboss.ide.eclipse.as.management.wildfly8 is used to hold jars for
all wildflys, or, expectedly, eap7x.
A bug in deploying large projects has led me to investigate whether the
wildfly 9 jars work for all servers or not. It turns out, they work for
all except AS 7.0.x. With as71, though, a higher timeout is needed.
My PR to fix the issue creates a 71x service inside the
org.jboss.ide.eclipse.as.management.wildfly8 to live along side the wf8
service. Unfortunately, it seems strange now to have a plugin named
org.jboss.ide.eclipse.as.management.as71 which holds a service with
version=7.1.0.Beta1 which only works for AS 7.0.x =P Seems a bit
So I was planning on harmonizing these constants, plugin names,
versions, etc, in beta2, and was wondering if anyone else is using these
service names and constants directly, and how they're being used? I
expect to change them and clean them up, and need to know if this will
- Rob Stryker
the m2e-android team found a serious issue with the way project
configurators are ordered with the new runsAfter/runsBefore directives
in m2e 1.6.0. This would lead to configurators being completely ignored and
generate Plugins Execution Not Covered errors.
Hence, I staged m2e 1.6.1, fixing that issue, available in the milestones
update site. We'd appreciate if developers of 3rd party configurators
could check it works for them.
If no regressions are found, I'll release m2e 1.6.1 on Monday 26/06/2015.
m2e 1.6.1 will be added to the next Eclipse Mars SR1 release, in September.
"Have you tried turning it off and on again" - The IT Crowd
And if that fails, then http://goo.gl/tnBgH5
just a fyi that https://github.com/jbosstools/jbosstools-build-ci now
defaults to jbosstools-4.3.x instead of master.
The `master` branch is by now deprecated for this repository but we
cannot change it since old builds unfortunately rely directly on the
thus changing it to be default jbosstools-4.3.x so merges/PR's/browsing
stop defaulting to master which should not be changing anyways ;)
Let me know if it gives problems.
Component leads, please tag your repositories!
$ git fetch jbosstools jbosstools-4.3.0.Beta1x #assuming remote is
called jbosstools, also often called origin
$ git tag jbosstools-4.3.0.Beta1 FETCH_HEAD
$ git push jbosstools jbosstools-4.3.0.Beta1
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
FYI, Tycho 0.23 is released.
We should move up to using this in master branch.
-------- Forwarded Message --------
Subject: [tycho-user] Tycho milestone 0.23.0 released
Date: Mon, 8 Jun 2015 07:34:48 +0000
From: Sievers, Jan <jan.sievers(a)sap.com>
Reply-To: Tycho user list <tycho-user(a)eclipse.org>
To: Tycho user list (tycho-user(a)eclipse.org) <tycho-user(a)eclipse.org>,
Tycho developers list (tycho-dev(a)eclipse.org) <tycho-dev(a)eclipse.org>
Tycho milestone 0.23.0 has been released and is available from maven
See the release notes  for details of enhancements and bug fixes in
Enrico De Fent
who contributed patches for this release.
And thanks and to everyone who helped us with testing the staged version.
tycho-user mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
Just a heads up that when you add a blog to jbosstools-website you no
 need to put the date of its release into the filename, but simply
put it in the header
This has three advantages:
* no need to rename the file when publishing does not happen on that
* no date in the urls makes the urls "timeless" (more likely to be
viewed/clicked according to
* shorter urls
I'm not changing the old blog posts urls, but going forward we should
just use plain text urls.
I've updated the blog templates etc. so as long as you follow the docs
everything will be fine ;)