Re: [jbosstools-dev] New git repository for soa tests

> Sounds good to me. My only concern would be whether or not the > tests are aligned with specific component versions. If that's the > case, we could have all kinds of crazy branches if everything is > in the same repo (e.g. branches: switchyard 1.0, brms 5.4, brms > 5.5, switchyard 1.2, teiid 8, etc.). > > It would be nice if we could publish update sites for specific > component test suites that could then be executed as part of the > integration stack aggregation build. WDYT? That is where we had these tests before but because these are integration tests (yeah, sorry - overloaded word) and it turned out to be tests that yes are "rooted" at testing ESB, Drools, etc. they actually test more broadly in many cases - i.e. jboss central examples etc. and mostly driven by QE needs/dev/test cycles they are more targeting a "stack-release" than individual ones. The "input" to these tests would probably be early and release candidate builds of integration-stack + related core site. /max > > ----- Original Message ----- >>> >>> what do you think about having new git repository for SOA related >>> bot tests? >> >> We should be using integration-stack now instead of just SOA :) >> >>> 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. >> >> Yes, you merge them down. >> >>> What happens when there is another eclipse release? It seams that >>> I >>> will be still behind the master branch :( >> >> That is/will hopefully change. >> >>> 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 ;-) >> >> Well, technically it is fine/ok for this but I can see the >> advantage >> of creating a jbosstools-integration-stack-test repo (or similar >> named) as >> these tests would be related to jbosstools-integration-stack >> releases. >> >> It also maps to the notion of having coretests and >> integrationstacktests updatesites for dev/build testing. >> >> So I'm +1 on doing a split - but still need to solve the >> reddeer/botext scenario and you would still have similar job of >> working in different branches in this stack >> since both 4.0.x and 4.1 stuff will be active. >> >> /max >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >>