Sounds good to me then. Forget I said anything.
----- Original Message -----
> 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
>>