M5 spin status :: no aggregate or JBDS installers available yet; many bot and non-UI test failures, plus one inter-build compilation failure
by Nick Boldt
Since turning on the stable branch jobs, here's what's borked...
https://issues.jboss.org/browse/JBIDE-10349
Still trying to get a clean stable_branch aggregate build (and then JBT
builds too) - last time the aggregate failed due to missing Central,
OTDT, and OpenShift (hadn't spun clean yet).
---
Details:
- hibernate : test failure in org.hibernate.eclipse.console.test
- jbpm : test failure in org.jboss.tools.jbpm.convert.test
- jsf : test failure in org.jboss.tools.jsf.vpe.jsf.test
- maven : 15 bot test failures (same failures in trunk) ... should these
just be turned off and only run locally / manually?
- struts : COMPILE FAILED - upstream bits missing? "The import
org.jboss.tools.jst.web.validation cannot be resolved."
---
There are also a few jobs for which the latest build failed, but at
least we have one good build since branching. This suggests we're having
some stability issues w/ a few Jenkins slaves, but at least we're
getting clean spins when the server is quiet(er).
= archives : aborted build? [Dec 4 ok]
= birt : failed to find usage bits (poor timing between builds) [Dec 4 ok]
= seam : no more locks failure [Dec 4 ok]
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
2 weeks, 1 day
Suggestion needed to improve the JAX-RS change processing and validation
by Xavier Coulon
Hello,
I recently opened https://issues.jboss.org/browse/JBIDE-17290 because I realised that since I added the "as-you-type" validation in the JAX-RS tooling, I have two concurrent updates in the JAX-RS model: a JavaElementChangedListener that updates the JAX-RS elements in the model after the user edited a compilation unit, but the 'as-you-type' validator needs to perform the same updates in order to be sure that the validation occurs after the last changes have been taken into account. Actually, the two processes occur in parallel and I have no idea how to make sure that the JavaElementListener-related task is executed and completes before the validation start. I should point that the JavaElementChangedListener is not related to the JAX-RS Builder which is called when a file is saved - that's another story, since there are also updates at this level.
I don't want to get rid of the JavaElementChangedListener because the notification event provides me with the modified CompilationUnit AST, which is required for later processing (I don't want to parse the compilation unit unless it's absolutely necessary). Furthermore, it feels weird that the updates would only occur during the validation, so I'd rather avoid such updates in the validator.
Do you have any suggestion on how I could simplify and improve this part of the tooling ? Since we're now preparing for CR1, an easy-and-acceptable-by-Max solution would be preferred ;-)
How is the situation handled in the CDI tooling ?
Thanks for reading this mail and thanks for your help !
Best regards,
/Xavier
11 years, 7 months