[jbosstools-dev] New git repository for soa tests

[Andrej Podhradsky]

Hi Max

----- Original Message -----
> From: "Max Rydahl Andersen" <max.andersen at redhat.com>
> To: "Andrej Podhradsky" <apodhrad at redhat.com>
> Cc: "jbosstools-dev jbosstools-dev" <jbosstools-dev at lists.jboss.org>
> Sent: Thursday, January 31, 2013 6:31:52 PM
> Subject: Re: [jbosstools-dev] New git repository for soa tests
> 
> > 
> > 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.

I agree if there is a new git repo it should be related to jbosstools-integration-stack tests.
So we can wait when the JBTIS comes into play and then we decide If the new repo is really needed.

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