On 14. 3. 2013, at 13:29, Max Rydahl Andersen <max.andersen(a)redhat.com> 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 :)
I don't remember that :P but OK, if you were objecting, you were right
>>> * 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.
Yes.
>>> -> 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 ?
Sounds ok to me.
>>> -> 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.
Yep, probably it's waiting for me then.
Created
https://issues.jboss.org/browse/JBIDE-13790
-Martin