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