Re: [jbosstools-dev] Integration tests on coretests update site?
by Max Rydahl Andersen
cc'ing jbosstools-dev:
> Probably I missed discussion about this I'm sorry.
nope - it haven't really been discussed.
> What do you think about adding JBT integration tests (SWTBot tests) to JBT coretest ( http://download.jboss.org/jbosstools/updates/nightly/coretests) update site?
If the integration-tests will work on the core target platform then sure.
But afaik you still use a mix of reddeer and soa dependencies so not sure it makes sense to add them to coretests at this point ?
The tests that uses the core target platform and are plain core tests could go there afaics, but depend on the usecase and when these plugins will be considered "released"
> For QE it would be useful for running tests on Jenkins without building integration tests locally. Of course we can also solve this problem by creating separate update site for integration tests. I can't say what is easier.
Having a site for integration-tests might make sense if its dependencies keeps being a mix of things and never really released/tagged similar to the other plugins.
Is this *just* for running tests on jboss jenkins or your internal mchydra jenkins tests ?
/max
13 years, 1 month
JBDS 6.0.0.Beta2 on Early Access
by Nick Boldt
JBDS 6.0.0.Beta2 Early Access installers are now available!
https://devstudio.jboss.com/earlyaccess/
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
http://nick.divbyzero.com
13 years, 1 month
Next-generation VPE - Visual Page Viewer (VPV)
by Yahor Radtsevich
Hi All!
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
JavaScript and HTML5 and the support of 64-bit JVM on all OS. And get rid
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 does not support JavaScript.
- 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
workstations.
- 64-bit JVM is not supported on Windows and OSX.
- No HTML5 support (yes, we simulate HTML5 tags, but it is not
enough).
- 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
VPE.
*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.
- We cannot enable JavaScript. We store Java objects for every XULRunner
node. If the visual tree is modified by JavaScript, we will get errors.
- JUnits are slow, we cannot run JUnits to test templates without
rendering them in XULRunner.
*VPV architecrture*
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
browser nodes.
- 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
on request.
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
work with JavaScript, where you can load resources as you want, e.g.
link.href = ‘style’ + ‘.’ + ‘css’ - what poor VPE can do? Interpret
JavaScipt? No.
- 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:
browser.setUrl(“/temp/dir/converted.html”).
- 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
like Jetty?*
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
response codes.
--
Best Regards,
Yahor Radtsevich
13 years, 1 month
Eclipse & Windows users - what is your ssh keys directory?
by André Dietisheim
Hi
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:
* C:\Users\<userid>\ssh\
OR
* C:\Users\<userid>\.ssh\
Thanks a lot for your replies!
Cheers
André
13 years, 1 month
Special profile for java 1.7 on mac - how to do it
by Martin Malina
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:
<profiles>
<profile>
<id>mac17</id>
<activation>
<os>
<family>mac</family>
</os>
<jdk>1.7</jdk>
</activation>
<properties>
<systemProperties>-Dawt.toolkit=sun.lwawt.macosx.LWCToolkit</systemProperties>
</properties>
</profile>
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?
Thanks,
Martin
--
Martin Malina
JBoss QA Engineer
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno, Czech Republic
Tel.: +420 532 294 265
13 years, 1 month
Beta2 / CR1 status :: Branched for 4.0.x, code frozen, test failures need your attention!
by Nick Boldt
Beta2 is nearly ready for release, though I haven't heard a thumbs up
from QE yet, so I didn't release it to jboss.org or devstudio.jboss.com.
I expect we'll put it out Mon or Tues.
---
JBoss Tools is branched for CR1, which means all the projects in Github
have a new "jbosstools-4.0.x" branch, eg.,
https://github.com/jbosstools/jbosstools-base/tree/jbosstools-4.0.x
https://github.com/jbosstools/jbosstools-central/tree/jbosstools-4.0.x
...
Note that we are *code frozen*, which means only urgent fixes should be
done in the branch, AFTER BEING APPROVED via +1s in JIRA.
---
Builds are underway, despite blocking test failures:
* AS: https://issues.jboss.org/browse/JBIDE-13098
* Archives: https://issues.jboss.org/browse/JBIDE-13099
* Common: https://issues.jboss.org/browse/JBIDE-13097
* Hibernate: https://issues.jboss.org/browse/JBIDE-12849 (broken since
Beta1)
* Seam (JavaEE): https://issues.jboss.org/browse/JBIDE-13101
* VPE: https://issues.jboss.org/browse/JBIDE-13100
* Portlet: respinning now, was waiting on a JavaEE build
* Central/Maven/Examples: waiting on a clean Portlet build
Remember, Operation Blue Balls begins with you! :)
---
Github master branches are now set to be 4.1.0.Alpha1. This is for the
moment a placeholder, as we don't for sure know if the next release will
be a 4.0.1 or a 4.1.0.
We have NOT yet moved the trunk/master to a Kepler Target Platform -
that will probably wait until December. For now, consider the github
master branches and the devstudio SVN trunk FROZEN.
If you have new work you need to do, be it for a JBT4.0.1/JunoSR2
build or a JBT4.x/Kepler build, do so in a private topic branch.
Thanks!
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
13 years, 1 month
