From: "Nick Boldt" <nboldt@redhat.com>
To: "Max Rydahl Andersen" <max.andersen@redhat.com>
Cc: "jbosstools-dev jbosstools-dev" <jbosstools-dev@lists.jboss.org>
Sent: Thursday, March 14, 2013 9:02:55 AM
Subject: Re: [jbosstools-dev] Time for a new SOA test repo?

So after much discussion, I'm hearing that:

1) individual projects' non-integration tests (that is, relatively fast
UNIT tests) will run as part of those projects' builds, and their
features & plugins will be published to the staging composite site, then
aggregated into two aggregate sites, as we did in JBT 4.0.0 and before:

* http://download.jboss.org/jbosstools/updates/nightly/coretests/
* http://download.jboss.org/jbosstools/updates/nightly/soatests/

2) jbosstools-integration-tests repo will be split into:

* jbosstools-itests and
* jbosstools-integration-stack-itests

which will publish 2 SEPARATE update sites. Name choice is based on
Maven "itests" convention:

http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing

3) jbosstools-itests site will build using the JBT target platform
(Kepler). We should also ensure we are building a Juno version so that
this site can exist and the jbosstools-integration-stack-itests build
can depend on it. This is where UI testing framework code such as
org.jboss.tools.ui.bot.ext should go.

4) jbosstools-integration-stack-itests site will build using the JBTIS
target platform (Juno) and will depend on the jbosstools-itests update
site from 4.0.x, as well as the upstream coretests and/or soatests
sites, if necessary.

---

As to the Zest question, it will only be added to the JBT 4.1 target
platform for *Kepler*, since it is only that version of Central which is
planned to be updated w/ SpringIDE 3.2. Should we decide we want to
include SpringIDE 3.2 in Central for JBT 4.0.1 / JBDS 6.0.1 as well, we
would need to add Zest to the Juno target platform too.

If that is something that PM and QE would like to happen, please provide
input in https://issues.jboss.org/browse/JBDS-2395 so I can set that up
ASAP.

Thanks!

Nick

On 03/14/2013 08:29 AM, Max Rydahl Andersen wrote:
>>>> 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.
>
> Yes, totally agree - remember I was the one objecting when you put all tests into the integration test repo :)
>
>>>> * 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
>
> Okey, yes - I misunderstood the statement as if the tests would run slower which would be wrong, but the *builds* would for sure get an impact - question is just how much.
>
> But even ignoring that the core tests should not depend on any JBTIS target platform since it might not even exist in a compatible form before later in development.
>
>>>> -> 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).
>
> Yes, completely agree that should be fixed.
>>
>>> 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? :)
>
> integration-stack-tests ?
>
>>>> -> 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.
>
> Yeah - if you guys can create a script for it i'm more than willing to help review it.
>
> /max
> _______________________________________________
> jbosstools-dev mailing list
> jbosstools-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>

--
Nick Boldt :: JBoss by Red Hat
Productization Lead :: JBoss Tools & Dev Studio
http://nick.divbyzero.com
_______________________________________________
jbosstools-dev mailing list
jbosstools-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Len DiMaggio (ldimaggi@redhat.com)
JBoss by Red Hat
314 Littleton Road
Westford, MA 01886  USA
tel:  978.392.3179
cell: 781.472.9912
http://www.redhat.com
http://community.jboss.org/people/ldimaggio