JBDS 6.0.0.Beta2 Early Access installers are now available!
Note that bits may take a while to replicate from our staging server to
publication. Please allow at least an hour before attempting to download
them - if the page above still shows the previous milestone instead of
6.0.0.Beta2, try again later.
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
There are some thoughts on the future development of VPE. Would be great to
hear any feedback/comments.
The idea is to add to VPE the must have features, like the support of
of all less important features and the features that do not work very well
(i.e. editing - that is why we call it 'viewer').
*Why VPE needs significant changes/rewriting?*
Because of three things (at least):
- Currently VPE is based on XULRunner 1.9 and XPCOM, which means that:
- This is not a default browser engine for Eclipse. This is the
reason of many incompatibility issues such as JVM crashes on some
- 64-bit JVM is not supported on Windows and OSX.
- No HTML5 support (yes, we simulate HTML5 tags, but it is not
- We have to ship XULRunner with JBoss Tools/JBDS
- There are a lot of features in VPE which are working not very well,
and still make the code to be complicated and bug-prone (i.e. visual
editing or D&D). These features are spread on all code, it is not easy to
isolate them and get rid of them without rewriting a significant part of
*How does VPE work now?*
VPE has a visual DOM builder and a lot of templates. For every XML/HTML
file opened in an editor, WTP automatically creates a W3C DOM tree (source
tree). Using templates, the visual DOM builder converts all nodes from the
source tree directly into XULRunner DOM tree (visual tree).
*So, what is wrong here:*
- We cannot use any browser other than XULRunner, because VPE templates
and the whole VPE code is tight coupled with XULRunner interfaces.
- JUnits are slow, we cannot run JUnits to test templates without
rendering them in XULRunner.
My vision is that the main process of the source to visual conversion
should looks like this:
*W3C source DOM--(by W3C DOM based templates)-->W3C visual DOM->HTTP
server->SWT browser widget*
The explanation follows.
*Why W3C visual DOM by W3C DOM based templates?*
Under W3C DOM based templates I mean that these templates will use
org.w3c.dom.* interfaces to produce visual DOM. To create W3C templates we
should rewrite all our existing VPE XPCOM based templates (~150 Java
classes) and many core classes. It is a lot of work, but as a bonus I
expect them to simplify significantly.
There are two not so good alternatives:
- Leave XULRunner DOM based templates as is and create wrappers for W3C
DOM nodes. So the templates will ‘think’ that they are creating XULRunner
DOM, but actually W3C DOM will be created.
- It is a simple to implement approach, but potentially it produces a
lot of runtime errors. E.g. if a template uses getStyle method, which does
not exist in W3C DOM, we will get a not implemented exception.
- Leave XULRunner DOM based templates as is and create wrappers for
- Simpler than the previous approach, but slower and requires to build
visual DOM in the UI thread.
*Why HTTP server?*
It is a simple way to know what resources our browser needs and send them
There are two not so good alternatives too:
- Use browser.setText(htmlText)
- In this case the browser do not have a base URL, so we should replace
all relative links to resources in the htmlText to absolute links, like
“style.css”->“file:///foo/barproject/style.css”. And this is not enough -if
linked resources have relative links, we should replace them too. But how
we can replace these links in linked resources if we cannot change them?
The answer is we should embed these resources in htmlText, like “<link
href=style.css>”->“<style>style.css content here</styles>”. This approach
is implemented in VPE. It is very complicated. What is worse, it does not
link.href = ‘style’ + ‘.’ + ‘css’ - what poor VPE can do? Interpret
- Create a temporary directory, copy converted .html file and ALL
resources there (because we do not know which resources are needed
exactly). Then point our browser to it:
- Synchronization problems: have to manage tons of files, delete them if
not needed etc. Speed problems: all resources should be deployed to the
temporary folder before viewing the converted html in browser.
*We are going to open a TCP port, what about security?*
No problem here. Java allows to restrict connections to localhost only:
new ServerSocket(8383, 0, InetAddress.getByName("localhost"))
At least the standard Windows firewall does not worry and does not show the
“Security alert” pop-up.
*How hard to write our own HTTP server? Is not it easier to reuse something
We do not need a complicated server. Just a server which supports GET
requests would be enough. Writing of a custom server is the simplest task
ever :) Here is an
example<http://cs.au.dk/~amoeller/WWW/javaweb/server.html>of a 150
lines HTTP server with support of GET requests, MIME types and
We (QE) are not able to build cdi tests on jenkins (QE jenkins instance)
slave with MS Windows because path to source file exceeded limit of 256
Is there a way how to fix it in general not refactoring paths within
repository or renaming Jenkins jobs to shorten paths?
Please add you comments to Jira https://issues.jboss.org/browse/JBIDE-13112
I'm investigating some issue in JBoss Tools for OpenShift which is
related to ssh keys. The issue is only occurring for windows users. I'd
love if the Windows users among you guys could report me in what folder
your ssh keys are:
Thanks a lot for your replies!
there is a bug in forge runtime
https://issues.jboss.org/browse/FORGEPLUGINS-41 and because of that
issue you cannot deploy from CLI/Forge console in JBT.
Can we somehow take care that it will be fixed in time before JBT
QA Engineer, JBDS
Phone: +420 532 294 352
Red Hat Czech
Purkynova 99, 612 00 Brno, Czech Republic
Hi Mickael and Nick,
We've been having a problem with running our bot tests on OS X with java 1.7. This is what we get:
java.awt.AWTException: headless environment
To overcome this, we need to add this property to the tycho surefire argLine: -Dawt.toolkit=sun.lwawt.macosx.LWCToolkit
The question is how to do it?
We tried this:
But the problem is that maven uses OR with multiple conditions instead of AND (there has been an open bug report for this for a couple of years).
Do you have any idea how to overcome this? Of course you can always manually enable such profile, but that's not really an option if you want to run a matrix job in Jenkins.
Also, if we find a solution for this, could we add it to the parent pom?
JBoss QA Engineer
Red Hat Czech s.r.o.
612 45 Brno, Czech Republic
Tel.: +420 532 294 265
I'm not sure when it was introduced but it started to drive me crazy..
We got this in our parent pom (and a few other plugins):
<!--This plugin's configuration is used to store Eclipse m2e settings only.
It has no influence on the Maven build itself.-->
<!-- Workaround for https://bugs.eclipse.org/bugs/show_bug.cgi?id=350414 -->
Which seem to cause our build to spit out a warning for *every* damn component:
[INFO] Building gwt.all 1.1.0-SNAPSHOT
[WARNING] The POM for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0 is missing, no dependency information available
[WARNING] Failed to retrieve plugin descriptor for org.eclipse.m2e:lifecycle-mapping:1.0.0: Plugin org.eclipse.m2e:lifecycle-mapping:1.0.0 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.eclipse.m2e:lifecycle-mapping:jar:1.0.0
Can we not avoid this ? didn't m2e actually get fixed to not require these kind of changes....or at least have a way to dump this [warning] on every build ? (i.e. shouldn't this not only be present in a specific m2e profile ?!