Some of you already met Gorkem, but for those who haven't he is working on tooling for Aerogear, currently specifically on Hybrid mobile applications using Apache Cordova.
I've added a aerogear-hybrid component into https://jira.jboss.org/jira/browse/JBIDE at https://issues.jboss.org/browse/JBIDE/component/12317246
It's utterly empty right now but i'm sure Gorkem and Aerogear will start feeding it issues ;)
We'll create a jbosstools-aerogear repository in jbosstools github org once Gorkem is ready for it.
Soom we'll have API Tools part of the reports produced by build.
However, it seems to me that most (all?) JBoss Tools projects don't use
API Tools. But it's not too late to start using them in your IDE, in a
long-term view, it's very useful and can prevent from some serious bugs
and will help you to choose the best version to put for your
dependencies in your MANIFEST. Here is a reminder of how to set them up:
http://eclipsesource.com/blogs/2013/02/21/api-tools-revisited/ . In our
case, the "baseline" is the latest release of JBoss Tools or JBoss
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
I was checking if there are components that requires version update in
4.0.x branch and
It looks like some components should have version updated (see attached
txt file for component changes):
esb ( 1.5.0 - 1.5.1 )
forge ( 1.1.0 - 1.1.1 )
jbpm ( 4.5.0 - 4.5.1 )
openshift ( 2.4.0 - 2.4.1 )
vpe ( 3.4.0 - 3.4.1 )
server/archives ( 3.4.0 - 3.4.1 )
version is already updated in:
bpel ( 1.2.0 -> 1.2.1 )
server/as ( 2.4.0 - 2.4.1 )
not sure if it is really required:
runtime-soa - nick suggested it can be deleted, because all runtime
detection plugins moved to corresponding modules
Could component leads confirm if version update above is really required?
m2e 1.3(.1) is available from the m2e release repository. See  for the
usual installation instructions.
m2e 1.3 focuses on bringing new APIs to be consumed by 3rd party adopters :
* New APIs to better control the project conversion to Maven experience
- Added new <conversionParticipantConfiguration> extension point to
explicitely request ProjectConversionParticipant invocation per packaging
type (For Jan and Tobias ;-))
- Added a new ConversionEnabler, providing the ability to preselect the
packaging type during project conversion
- exclude project conversion participants for certain projects
- Added new attributes to order project conversion participants execution
* Added new API for Runtime classpath resolution of dependencies referenced
with classifiers (fixes some ejb-client resolution issues in m2e-wtp)
* Introduced a new ResolverConfiguration#lifecycleMappingId attribute, if
specified, the corresponding ILifecycleMapping will be used regardless of
any other lifecycle mapping metadata
* Introduced a new flavor of AbstractProjectConfigurator#addNature that
accepts updateFlags parameter that allows finer control over new nature
* Added new AbstractJavaProjectConfigurator#getOutputLocation method to
provide better extensibility
The following behaviors changed in m2e 1.3
* The behavior for <execute/> mapping of maven plugins has been changed to
runOnIncremental=false by default, to prevent random build loops
* The JDT conversion participant is now restricted to the “jar” packaging
by default. 3rd party adopters need to explicitely request the
maven-compiler-plugin to be configured, via an extension point
Regular m2e users will probably appreciate :
* some slight improvements made on the archetype selection page
* import wizard now allows the (de)selection of individual projects
See the changelog for everything fixed in the 1.3 version.
Since a number of new APIs were introduced in m2e 1.3, we decided to use a
separate discovery catalog, to prevent users from installing incompatible
m2e extensions in previous 1.1 & 1.2 versions. Unfortunately, some build
issues prevented us from getting that catalog ready before the Juno SR2
aggregator build picked m2e 1.3.0 up. For that reason the Juno SR2
distributions and canonical juno p2 repository embed version 1.3.0. m2e
1.3.0 points at the "old" 1.1 discovery catalog.
The m2e 1.3.1 version that is available today points at a new 1.3 discovery
The discovery catalog used in m2e can be manually changed by editing your
eclipse.ini and adding the -Dm2e.discovery.url parameter
You'll probably notice the new 1.3 catalog contains significantly less
entries than the previous version. m2e extensions owner need to make sure
their plugins are compatible with m2e 1.3 and request a catalog update in
BZ. This time I should be able to take some time to work on the catalog
As usual please report any bugs to bugzilla
Finally I'd like to give some kudos to Marcos and Roberto from IBM who
contributed a number of patches for this release, keep it up guys ;-)
"Have you tried turning it off and on again" - The IT Crowd
As you know we are working on wizards for our new jQuery Mobile palette:
The wizards have a visual preview. We use the SWT Browser for that. But
there is a problem. It actually uses our bundled xulrunner from VPE
which has a limit support of HTML5.
This browser works ok with jQuery Mobile 1.2 but doesn't work at all
If you don't have VPE installed in your Eclipse than this preview will
work with 1.3 but if you do then the xulrunner from VPE will be used.
We found a workaround for this problem. Our wizards generate code for
the latest jQuery Mobile 1.3 but we use 1.2 for visual preview. In some
cases 1.2 and 1.3 behaves differently and we have to *simulate* jQuery
1.3 widgets using 1.2 code for preview.
But I believe it's going to be a much bigger problem for future versions
of jQuery Mobile.
It's not only about jQuery wizards actually. It's about all eclipse
widgets which use swt browser.