[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