Fwd: Build failed in Jenkins: jbosstools-arquillian_master #282
by Max Rydahl Andersen
Anyone with info on why vncserver is failing to run on jenkins for
arquillian now ?
/max
http://about.me/maxandersen
Forwarded message:
> From: ci-builds(a)redhat.com
> To: manderse(a)redhat.com
> Subject: Build failed in Jenkins: jbosstools-arquillian_master #282
> Date: Sun, 10 May 2015 07:14:20 -0400 (EDT)
>
> See
> <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian...>
>
> ------------------------------------------
> Started by build flow jbosstools-buildflow_master#162
> [EnvInject] - Loading node environment variables.
> Building remotely on dev218-virt1 in workspace
> <http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian...>
> Fetching changes from the remote Git repository
> Fetching upstream changes from
> git://github.com/jbosstools/jbosstools-arquillian.git
> Checking out Revision 85c91abfefba2f39607e73e6912f4f7cfc1beddf
> (origin/master)
> Starting xvnc
> [jbosstools-arquillian_master] $ vncserver :89 -geometry 1920x1080
> FATAL: Cannot run program "vncserver" (in directory
> "<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian...")>:
> java.io.IOException: error=2, No such file or directory
> java.io.IOException: Cannot run program "vncserver" (in directory
> "<http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-arquillian...")>:
> java.io.IOException: error=2, No such file or directory
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:470)
> at hudson.Proc$LocalProc.<init>(Proc.java:244)
> at hudson.Proc$LocalProc.<init>(Proc.java:216)
> at hudson.Launcher$LocalLauncher.launch(Launcher.java:773)
> at hudson.Launcher$ProcStarter.start(Launcher.java:353)
> at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:998)
> at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:965)
> at hudson.remoting.UserRequest.perform(UserRequest.java:118)
> at hudson.remoting.UserRequest.perform(UserRequest.java:48)
> at hudson.remoting.Request$2.run(Request.java:328)
> at
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
> at hudson.remoting.Engine$1$1.run(Engine.java:63)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: java.io.IOException: error=2, No such
> file or directory
> at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
> at java.lang.ProcessImpl.start(ProcessImpl.java:65)
> at java.lang.ProcessBuilder.start(ProcessBuilder.java:452)
> ... 16 more
7 years, 10 months
Advice on use of apache.directory.browser plugins
by phantomjinx
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
Wanted to get a handle on the way forward for use of bundles from update sites outside of JBT and
JBT-IS.
Teiid Designer has the ability to model connections to LDAP servers. Up until this point, we have
created the modelling UI from scratch but I have found that
org.apache.directory.studio.ldapbrowser has a superior set of UI widgets that Designer could make
use of. While experimenting I have appended the directory update site [1] to our eclipse TP but
long term, if everything works okay, I would prefer a most resiliant strategy to avoid just
situations as their update site suddenly disappearing.
Can I get some advice on how to proceed with this, in that should the update site be appended to
the JBT TP? Should their update site be mirrored? Is this a non-starter?
Cheers
PGR
[1] http://directory.apache.org/studio/update/2.x/
- --
Paul Richardson
* p.g.richardson(a)phantomjinx.co.uk
* p.g.richardson(a)redhat.com
* pgrichardson(a)linux.com
"I know exactly who reads the papers ...
* The Daily Mirror is read by people who think they run the country.
* The Guardian is read by people who think they ought to run the country.
* The Times is read by people who do actually run the country.
* The Daily Mail is read by the wives of the people who run the country.
* The Financial Times is read by the people who own the country.
* The Morning Star is read by the people who think the country ought to be run by another country.
* The Daily Telegraph is read by the people who think it is."
Jim Hacker, Yes Minister
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iEYEARECAAYFAlVQ85UACgkQcthLMIwdEb0d6gCfSvOiTlcXnYFGwnzTW4VNiNx7
3JAAoK4I2Xb5YT4CnIvF70guReALtOnN
=LLn9
-----END PGP SIGNATURE-----
7 years, 10 months
New location of the source files for earlyaccess.properties
by Nick Boldt
If you are a developer who is producing content which is tagged as Early
Access in JBoss Central, this email applies to you. Or, if you're
involved in releasing new discovery plugins to JBoss Central (Paul,
Mickael, myself), this email applies to you.
For everyone else, it's just an FYI.
---
In order to avoid confusion concerning which version is the latest for a
given stream of builds (master vs. stable branch), and to streamline the
release process to handle both JBT/JBDS releases and their associated
(but later) JBTIS/JBDSIS releases, I've moved stuff around so it's more
obvious where the latest versions come from.
Note: this applies to the Mars releases only.
Thus, here are the source files to update if/when things are added to
the list of things we include in Central which are Early Access:
*
http://download.jboss.org/jbosstools/mars/snapshots/updates/earlyaccess.p...
{stream}/jbosstools-earlyaccess.properties
*
https://devstudio.redhat.com/9.0/snapshots/updates/earlyaccess.properties/
{stream}/devstudio-earlyaccess.properties
When those are updated in github, they will cascade into the Central
plugins when rebuilt (such that when in offline mode there's still a
backup/default list), and also into the creation of the Central and
Early Access *Discovery* sites.
For changes related to new versions of IS features, this may require a
rebuild of jbosstools-discovery project or will simply require copying
the new properties on top of those released versions elsewhere on
devstudio.redhat.com or download.jboss.org.
Which version of the properties file should be used for a given version
of JBT/JBDS is still controlled here:
http://download.jboss.org/jbosstools/configuration/ide-config.properties
Any questions about this reorg, see these JIRA or ask in this thread:
* https://issues.jboss.org/browse/JBIDE-19346
* https://issues.jboss.org/browse/JBDS-3208
Thanks,
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
7 years, 10 months
Microservices
by Mickael Istria
Hi all,
As I'm following some discussions about microservices (which are more or
less regular Jax-RS services in many cases), I'm wondering whether JBoss
Tools could embrace the word "Microservices" in some ways, for example
in wizards or archetypes.
Would a "Microservices" category in the Import wizard, that would repeat
most Jax-RS wizards be a good idea ?
Or just prefixing all occurence of the "service" word with "(micro)" ?
WDYT?
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools>
My blog <http://mickaelistria.wordpress.com> - My Tweets
<http://twitter.com/mickaelistria>
7 years, 10 months
mass tagging..
by Max Rydahl Andersen
Hey,
Just FYI, I went ahead and made tags for the releases that were missing
but we had an approximate branch for.
That will explain why you see tags coming in when doing a pull or fetch.
Thanks,
/max
http://about.me/maxandersen
7 years, 10 months
