How to modify remote download-runtimes xml?
by Rob Stryker
Hey all: JBT currently checks a remote URL for possible runtime types
to download which are not declared via extension point as runtimes
available for download. This is to ensure that even mid-devcycle, we can
add new runtimes to the list.
The file is located here:
http://download.jboss.org/jbosstools/examples/download_runtimes.xml
I recently added new features to runtimes, which allows for a license
url. Unfortunately this remote file does not have hte license url
attribute, so I need to add it.
Anyone here know how to modify that remote file? Where to gain access?
- Rob
13 years
Question about Common Validation
by Xavier Coulon
Hello Alexey,
I have another question common-validation that I use for the JAX-RS tooling. This is in relation with https://issues.jboss.org/browse/JBIDE-12595 ("Disabling JAX-RS validator doesn't affect resources validation"). As Jaroslav reported, when a user disables the JAX-RS validation, the problem markers (which are now persistent) are not removed, which is not the expected behavior. The only way to remove them is to delete them from the "Problems" view.
When validation is disabled, is there any call to a method that I could override to remove the JAX-RS problem markers on all the resources of the project ?
Or, how do you handle that case in the CDI tooling ?
Thanks
Best regards,
/Xavier
13 years
Juno + JBT 4.0 Alpha2 Crash in Native Code on F17 64bit
by Peter Palaga
Ladies and Gentlemen,
I experience crashes like this several times a day since I have started
with JBT 4.0 about a month ago. I am not able to determine any
particular order of actions to reproduce it. However, disabling JBoss
Central and selecting "Use external Web browser" in the preferences
seems to reduce the frequency of the crashes.
Is this a known issue?
I would like to file it as a bug but I am not sure at all which tracker
I should use: JBT or Eclipse?
Full log: http://pastebin.com/BhsrH820
Console:
$ eclipse
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
further details.
org.eclipse.jst.j2ee.internal.deployables.JEEFlattenParticipantProvider
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
[debug] execute contextualize
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x000000307e6094eb, pid=6973, tid=140487050090240
#
# JRE version: 6.0_32-b05
# Java VM: Java HotSpot(TM) 64-Bit Server VM (20.7-b02 mixed mode
linux-amd64 compressed oops)
# Problematic frame:
# C [ld-linux-x86-64.so.2+0x94eb]
#
# An error report file with more information is saved as:
# /home/my_user/hs_err_pid6973.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Thanks,
Peter
13 years
Re: [jbosstools-dev] SWTBot ModeShape Tools Plugin
by Max Rydahl Andersen
> I wanted to get with you to talk about the SWTBot project you work on in ModeShape Tools. As you know from previous emails, ModeShape Tools has moved to GitHub and all "trunk" development should be done there. *I apologize for not getting with you sooner.*
>
> Today I updated my local copy of the SVN trunk of "org.jboss.tools.modeshape.rest.ui.bot.test" project and merged any differences into my *local* git repository. However after merging the latest code, I started having build errors. I was hoping you could help me with that. The build fails quickly (see attached log).
Daniel, on jbosstools-dev (now in cc) we've been discussing moving these bot tests which tend to be full cross-cutting integreation tests rather than specific to one plugin to a jbosstools-integration-test project.
would it make sense for these tests to move there too or are these bot test "local" and stable enough to be part of modeshape main dev tree?
(another reason to move them out is that QE changes these *after* the module itself have been released meaning they aren't really part of the release anyway.)
> Max: Is the SVN trunk of ModeShape Tools still closed for business?
You tell me ;) I haven't done the svn delete yet (fighting with git migration scripts still), but it sounds like the bot tests are still receiving updates.
If need be we can nuke modeshape tools - just need to get clearance from doug and nick,QE(Pavol?) to ensure no builds are dependent on it ?
/max
13 years
Why so many "jenkins build is failing" emails?
by Nick Boldt
When a build fails, Jenkins attempts to find the cause of the failure by
looking at the commits that went into a build since the last time it was
blue (successful).
HOWEVER, *there's a bug in Jenkins right now is making this lookup
process search in git instead of svn* for the commit history (and
therefore the list of committers to email).
Because *we commit into svn*, not git, that lookup *ALWAYS fails* and
the search for "committers who broke the build" returns a
NullPointerException.
NPE = red (failed) build. But sometimes the failure is simply a bad
test, which should make the build yellow, and we want to reflect the
correct status.
Worse... if the problem's fixed and Jenkins is trying to send a "build
is back to normal" email, it will report RED (due to the mail recipient
lookup NPE) when it's in fact BLUE.
---
So, to work around this, instead of using the "send mail to individual
committers who broke the build" option, I switched notification to
everyone subscribed to this list for ALL the JBT 4.0 & JBDS 6.0 jobs --
not just the aggregate ones like we had in the past, but all the
components too.
---
When the bug is fixed in Jenkins (or as we move jobs to use git instead
of svn), I'll revert the configuration so that ONLY committers who broke
the build will be notified, not the whole list.
---
In the mean time... you might want to set up a filter on your mailing
list reader to suppress notifications of failing jobs for which you're
not a committer.
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
13 years
New promote script & Jenkins view for use with JBT SOA Tooling components (and later, JBT Core components in github, too)
by Nick Boldt
Everyone:
I've generalized the script I gave SwitchYard for promoting their
nightlies to development (or stable) so it's much easier to "release"
code to the community. Now with a handful of job parameters, you can
publish your latest nightly on demand as a new build type.
(Aside: you may find I use the terms "promote" or "publish"
interchangeably. That's because the act of "publishing" may include the
act of renaming or "promoting" a build from a lower status
(nightly/snapshot) to a higher status (milestone/release). Similarly,
"promoting" may include the act of "publishing" bits from within Jenkins
(lower state, internal only) to download.jboss.org (higher state,
publicly available). Apologies in advance for the confusion this may cause.)
Anyhoo... the new script is here [0].
To use this in your own job, simply copy one of the jobs [1], [2]
mentioned below, and you can publish your bits into the standard JBoss
Tools directory structure.
---
Rob,
Your SwitchYard-Tools-publish job [1] has been updated and should work
but I haven't run it because I don't want to actually release one of
your nightlies as a dev milestone. Note too that the order of the
options for which Eclipse platform to use in the published path has been
reversed as I assume you're now building on Juno, not Indigo (with
possible backward support for Indigo). If that's an incorrect assumption
it's easy to revert the options' order in the job config.
---
Dan & Randall,
I've tested this new script with ModeShape-Tools, and published [2] your
latest nightly [3] as 3.0.0.Beta5, since that's what Dan was trying to
do earlier today before he contacted me. Here are the jobs [2], [3].
Here's the build promoted by the -publish job [4]. If you weren't ready
to call it a milestone we can delete it and respin as needed -- or just
republish on top!
Note too that I moved your older Beta1 release from its old place under
/modeshape/tools/updates/develop/ to here for consistency [5]. You might
want to delete it entirely as it uses the old x.y.z.vTIMESTAMP
versioning scheme which can't be updated to the new
x.y.z.Beta5-TIMESTAMP features due to OSGi's versioning rules (users
must uninstall it first).
Oh, and I noticed that your Beta1 was targetted at Indigo, but I assume
your Beta5 is targetted at Juno. Is that correct?
---
SOA/BRMS project leads,
I've also created a new view in Jenkins to collate all the
trunk/JBT4/JBDS6 jobs into a single place:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt...
If your job(s) aren't listed, please edit the view and add them.
Once it's complete I can spawn a duplicate view (excluding the JBDS
job(s)) which we can push to the public-facing Jenkins server, similar
to http://hudson.jboss.org/hudson/view/SOA-Team/view/SOA_Tooling/
Why? Because community!
---
Still to do:
a) generate composite site metadata for all the contributed projects in
a given folder so that end users can simply look to one URL instead of
several (JBIDE-12662) - eg.,
http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooling/
or
http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling/
b) generate index.html pages for the sites in place of a bare directory
listing - requires adding an option to feed in a different header
graphic (JBIDE-12660), as the various SOA/BRMS Tooling projects have
their own branding already - see [5]). Then it's a simple matter of
adapting what's already done for Central [6].
---
Refs:
[0] http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/promote.sh
[1]
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt...
[2]
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt...
[3]
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt...
(publishes to builds/staging/${JOB_NAME})
[4]
http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling...
[5]
http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli...
[6] http://anonsvn.jboss.org/repos/jbosstools/trunk/central/site/pom.xml
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
13 years
What about a dedicated list for CI builds results?
by Mickael Istria
Hi all,
I feel having build results on jbosstools-dev introduce a lot of noise
and consume a significant amount of time in filering manually. Jenkins
already sends mails to interested people for a job (those who committed
code when build status changed, and those who directly add there mail
address in the Jenkins notification plugin configuration).
So I think havng all those mails adds low added-value compared to
default Jenkins mailing. I'm fine with the idea of having some
notifications of build results, but I'd rather see them in a less
critical media that this jbosstools-dev mailing-list which is a good
place for discussions.
What would you think about setting up a jbosstools-builds mailing list
to receive notifications? Or what about a jbosstools-notifications list
that would contain commits, CI results, and all other automatic stuff
that is useful to monitor project activity and health?
Cheers,
--
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>
13 years
