[jbosstools-dev] New git repository for soa tests

Martin Malina mmalina at redhat.com
Wed Feb 6 03:32:37 EST 2013


We're talking a new repo for integration stack bot tests - to separate it from the jbt core bot tests in jbosstools-integration-tests. So, yes, this new repo would be jbosstools integration stack integration tests :) But probably called something simpler, e.g. jbosstools-integration-stack-tests as suggested.

-Martin

On 31. 1. 2013, at 21:35, Nick Boldt <nboldt at redhat.com> wrote:

> 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 at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev

--
Martin Malina
JBoss QA Engineer
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno, Czech Republic

Tel.: +420 532 294 265




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20130206/5fc6b8df/attachment.html 


More information about the jbosstools-dev mailing list