[jbosstools-dev] New git repository for soa tests

[Rob Cernich]

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