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
4 weeks, 1 day
JBoss Tools 4.1 Alpha based on Kepler - ready for branch for build ETA next week?
by Max Rydahl Andersen
Hey,
If we branched for JBT 4.1 Alpha next week would you be ok ?
Koen and Denis did an awesome job of at least getting Hibernate JPA/Dali integration compiling this week.
And as Nick announced our simplest plan moving forward is to compile JBT 4.1 which will be basis for JBDS 7 against Kepler (theoretically we could have something working
on both but it would be a massive QE effort).
Eclipse Kepler M5 is coming out Friday so we might still have some issues but Nick/Mistria will be setting up a M5 based target platform as soon as possible.
It would be great if we could get out an early Alpha to get some traction and figure out what issues we got to fight when it all comes together.
Could you let me know ASAP if you have any issues/concerns with doing a branch next week for an Alpha build ? Would you be ready ?
Being ready for this means:
1) tested your component works on M5
2) no remaining jiras on 4.1.Alpha1 (triage your component! if questions ping/raise it)
3) issues marked with N&N so you can get them documented
4) Verified your component .y. version number have been bumped i.e. 3.2.1 -> 3.3.0 (we still have to do this "too high jump" in our current setup -hopefully can fix before next big version)
5) Branched your component with jbosstools-4.1.Alpha1x
Please let me know if you are ready for that or have questions/concerns.
Thanks,
Max
13 years, 1 month
New git repository for soa tests
by Andrej Podhradsky
Hi folks,
what do you think about having new git repository for SOA related bot tests?
SOA tests include bpel, jbpm, modeshape, teiid designer etc. And these components are independently released.
Now, the soa tests are in jbosstools-integration-tests together with jbt core tests.
The problem is that the next soa release will be for juno, so I'm developing tests under Juno.
It means committing to jbosstools-4.0.x branch while people for JBT core commit to the master branch (Kepler).
But what happens when I start developing soa tests for Kepler? Possibly commit my juno changes to kepler branch.
What happens when there is another eclipse release? It seams that I will be still behind the master branch :(
Another reason is that soa tests have nothing in common with core tests. Everyone is still dividing the tools into core and soa.
So, lets start discussing about pros and cons ;-)
Have a nice day!
--
Andrej Podhradsky
Quality Assurance Associate
JBoss SOA Platform
IRC: apodhrad at #jbossqa #jbosssoa #jbosssoaqa #devstudio-qa #brno
13 years, 1 month
Re: [jbosstools-dev] New git repository for soa tests
by Andrej Podhradsky
Hi Len!
this new repository will contain all soa tests which means also brms.
I don't know what is EPP :(
Andrej
----- Original Message -----
From: "Len DiMaggio" <ldimaggi(a)redhat.com>
To: "Andrej Podhradsky" <apodhrad(a)redhat.com>
Cc: "jboss-jbds-qe" <jboss-jbds-qe(a)redhat.com>, "Max Rydahl Andersen" <max.andersen(a)redhat.com>
Sent: Thursday, January 31, 2013 4:57:04 PM
Subject: Re: New git repository for soa tests
YES - this sounds like the right approach!
Hmm - should we also do the same thing for the other Platform JBDS tests (BRMS, EPP, etc.)
-- Len
----- Original Message -----
From: "Andrej Podhradsky" <apodhrad(a)redhat.com>
To: "Max Rydahl Andersen" <max.andersen(a)redhat.com>
Cc: "jboss-jbds-qe" <jboss-jbds-qe(a)redhat.com>
Sent: Thursday, January 31, 2013 5:57:23 AM
Subject: New git repository for soa tests
Hi Max,
what do you think about having new git repository for SOA related bot tests?
SOA tests include bpel, jbpm, modeshape, teiid designer etc. And these components are independently released.
Now, the soa tests are in jbosstools-integration-tests together with jbt core tests.
The problem is that the next soa release will be for juno, so I'm developing tests under Juno.
It means committing to jbosstools-4.0.x branch while people for JBT core commit to the master branch (Kepler).
But what happens when I start developing soa tests for Kepler? Possibly commit my juno changes to kepler branch.
What happens when there is another eclipse release? It seams that I will be still behind the master branch :(
Another reason is that soa tests have nothing in common with core tests. Everyone is still dividing the tools into core and soa.
So, lets start discussing about pros and cons ;-)
Have a nice day!
--
Andrej Podhradsky
Quality Assurance Associate
JBoss SOA Platform
IRC: apodhrad at #jbossqa #jbosssoa #jbosssoaqa #devstudio-qa #brno
--
Len DiMaggio (ldimaggi(a)redhat.com)
JBoss by Red Hat
314 Littleton Road
Westford, MA 01886 USA
tel: 978.392.3179
cell: 781.472.9912
http://www.redhat.com
http://community.jboss.org/people/ldimaggio
13 years, 1 month
Parent pom updated! Minimum/default target platform used in master branch (4.1/7.0) now points at Kepler M4 bits, with M5 coming next week; Juno&Kepler TPs will remove unneeded IUs next week
by Nick Boldt
1.
It was decided today that because we can't build ALL of JBoss Tools
using Juno, we should build everything with Kepler instead. (Hibernate
Tools depends on Dali, which broke API again. Since JavaEE project
depends on Hibernate Tools, this affects a large chunk of our stack.)
This is in keeping with past years, where each release is not
backwards-compatible w/ its previous due to changes at Eclipse
preventing it. (eg., in JBT 4.0, we tried to build on both Indigo and
Juno, and ultimately decided we should be building on Juno. Again,
Hibernate Tools / Dali caused this.)
If you want to build locally against Juno instead of Kepler for your own
tests/sanity checks, use this:
mvn verify -DTARGET_PLATFORM_VERSION=4.20.5.Final-SNAPSHOT #JunoSR0
mvn verify -DTARGET_PLATFORM_VERSION=4.21.3.Final-SNAPSHOT #JunoSR1
This is now the default behaviour (-D flag not needed):
mvn verify -DTARGET_PLATFORM_VERSION=4.30.0.Alpha1-SNAPSHOT #KeplerM4
--
2.
Next week, I will be moving TARGET_PLATFORM_VERSION to
4.30.1.Alpha1-SNAPSHOT, which will include updated Kepler M5 bits
(including m2e/m2e-wtp updates).
--
3.
In addition to moving to Kepler M5, I will also be removing UML2,
Graphiti & Zest, which will hereinafter be included on the new JBTIS
(Integration Stack, formerly SOA Tooling) target platform. This will be
done for *BOTH JUNO and KEPLER TARGET PLATFORMS.*
If you are in charge of a JBoss Tools 4.1 or 4.0 (Core) project and need
UML2, Graphiti, or Zest, let me know BEFORE next week, and we can
discuss keeping those reqs in the target platform for your use.
Otherwise I'll assume no one needs them, and they're safe to purge.
--
Once the cruft has been cleaned, new TPs will be released & linked into
the usual places [1], [2]:
4.20.6.Final-SNAPSHOT #JunoSR0 (6th respin)
4.21.4.Final-SNAPSHOT #JunoSR1 (4th respin)
4.30.1.Alpha1-SNAPSHOT #KeplerSR0, 1rst respin
[1] http://download.jboss.org/jbosstools/updates/juno/
[2] http://download.jboss.org/jbosstools/updates/kepler/
By the way, if you're looking to pull a target platform site zip and use
it locally, we've relocated them here:
http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/
Question, comments, fear & loathing, or any other feedback... send it here.
Cheers,
--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
13 years, 1 month
Browsersim: new features branches / how to try
by Ilya Buziuk
To run BrowserSim from eclipse you need:
1. import org.jboss.tools.vpe.browsersim and
org.jboss.tools.vpe.browsersim.browser plugins into workspace.
2. Run BrowserSim.java as java application (with -XstartOnFirstThread and
-d32)
FireBug Lite demo
fork: yradtsevich/jbosstools-vpe branch:firebug-lite
Weinre demo
fork: kmarmaliykov/jbosstools-vpe branch: JBIDE-13338
Ripple demo
How to setup ripple:
1. fork: ibuziuk/jbosstools-vpe branch:Ripple-demo
2. install tomcat 7
3. download Ripple-UI project:
https://dl.dropbox.com/u/19656504/Ripple-UI.zip
4. unzip this archive to Tomcat's webapps ->
(apache-tomcat-7.0.x/webapps/Ripple-UI/www/index.htm)
5. start tomcat
6. run browsersim -> right click -> Ripple emulator (bug
under mac os and windows: 2 instances of browsersim will be opened - close
them) -> choose Apache Cordova 2.0.0 (the same bug) -> Ripple emulator will
be opened
7. input
"http://localhost:8080/Ripple-UI/www/accelerometer.html" or
"http://localhost:8080/Ripple-UI/www/geolocation.html" into the address bar
P.S These versions are rather buggy but most features work under windows,
mac os x, linux
13 years, 1 month
