On 14. 3. 2013, at 9:27, Max Rydahl Andersen <max.andersen@redhat.com> wrote:

https://github.com/jbosstools/jbosstools-integration-tests/pull/188


The problem is (was) that:
* The ESB tests require the ESB UI which requires Zest - tests build fails on master for 7.0
* Zest is not in the JBT test package, but it is in the JBTIS test package

we probably need Zest for other reasons anyway so that probably makes sense to add to core TP anyway.

ok, so one problem will be solved. but spliting the repos make sense anyway imo.

* Adding JBTIS TP repo to our root pom in integration-tests would affect all our tests:

-> The tests would run slower

Hopefully not...did you see a big effect ?

It's more of a theoretical possibility - I think it was you who raised this concern in the past - that each new repo that is searched in a build introduces more complexity for resolving of the dependencies

-> The JBTIS test package might affect our tests - we might miss issues of plugins not being in the JBT test package

not following what you mean here ? if JBTIS test package does affect your test we want to know about it ;)

The core integration tests should be able to resolve all dependencies from the JBT core TP and update site - we're trying to emulate the usual use case when somebody installs JBT core - they won't have JBTIS update site available.
So if we add JBTIS update site for all tests we might miss some problem - a missing dependency on the core update site. Sure, this would probably be picked up by a failing build of a component, but even so, I think it's cleaner if we just use the intended update sites (core TP and core update site for core tests).

That said you should be using JBTIS since that is where the esb plugins are. Can't just use jbosstools core as base for this.

Sure, that's why it would be good for JBTIS integration tests to be separate - they need to use JBTIS TP and update site.

So - what are the solutions?

Split out the github repository and move the integration-platform tests to a separate repo.

+1

Second, long-term
* We had talked about this in the past - creating a new SOA test repo

integration-test repo - its no longer just SOA.

We tend to say "soa integration tests" because integration stack integration tests is even more confusing. Do you have a better suggestion here? :)

-> The SOA 6 tests will be affected (remember that the ESB examples are still not configured here with JBTIS)

jira ?

Not sure exactly what Len meant here. I think they will be mainly affected by the move to a new repo itself.

-> This will mean that existing 4.0.x work would move to the new repo

you'll need to migrate the history very carefully yes.

Yeah, another exercise for filter-branch/fast-filter I guess.

-Martin

-> Everyone using the SOA tests will have to adapt
-> What else can go wrong?
Need to tell Drools tests - BRMS team - Lukas Petroviky
- the BRMS team has no one to do the testing at the moment.

/max

_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev

--
Martin Malina
JBoss QA Engineer
Red Hat Czech s.r.o.
Purkynova 99
612 45 Brno, Czech Republic

Tel.: +420 532 294 265