[jbosstools-dev] New git repository for soa tests

[Rob Cernich]

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