> > 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

> 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 >>

A new repository for bot tests? Why not https://github.com/jbosstools/jbosstools-integration-tests/ ? On 01/31/2013 12:31 PM, Max Rydahl Andersen wrote: >> >> 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 > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev