>> cc'ing jbosstools-dev:
>>> Probably I missed discussion about this I'm sorry.
>> nope - it haven't really been discussed.
Actually, it has - see https://issues.jboss.org/browse/JBIDE-12974
Well, let me correct myself - it haven't been discussed outside a jira which only two
people are watching ;)
>>> What do you think about adding JBT integration tests
(SWTBot tests) to JBT coretest (
) update site?
>> If the integration-tests will work on the core target platform then sure.
>> But afaik you still use a mix of reddeer and soa dependencies so not sure it
makes sense to add them to coretests at this point ?
> Yes this is true but we are going to use reddeer in future and SOA tests
> are going to have soa dependencies also AFAIK.
As is pointed out in the JIRA, for now we could at least add the bot ext plugin to the
site so we don't have to build it before running every test. Bot ext doesn't
require red deer so it should be safe.
This beckon to question why bot ext was ever moved in the first place ?
And why bot tests that requires SOA tests was put together into the same repository. It
has its upsides but not sure it is the best way since these plugins life cycle are very
>> The tests that uses the core target platform and are plain core tests could go
there afaics, but depend on the usecase and when these plugins will be considered
> It's right but than we have to maintain list of test plugins considered
> as "released" and coul be published to core tests site.
I think the main issue here is the mixed dependencies of red deer. Once this gets
resolved we can then discuss if we can simply include all of them or just those considered
Yes, we need to sit down and look at the dependencies and when/where those tests need to
For me integration tests != core unit tests and should be separate managed anyway.
>>> For QE it would be useful for running tests on Jenkins
without building integration tests locally. Of course we can also solve this problem by
creating separate update site for integration tests. I can't say what is easier.
>> Having a site for integration-tests might make sense if its dependencies keeps
being a mix of things and never really released/tagged similar to the other plugins.
>> Is this *just* for running tests on jboss jenkins or your internal mchydra
jenkins tests ?
> Right now the reason is to run tests on machydra jenkins. I don't know
> about anyother reason.
Yes, right now the reason is mostly running the tests on Machydra. But not exclusively -
even if we (or anyone else) wants to run a test localy we have to build bot ext first.
Having it on the coretests site would solve this.
Also, I have some jobs for the EAP QA team set up on the main jboss
jenkins instance and it works the same way - unless bot ext is on the coretests site it
needs to be build first. I'm not saying that it is such a big problem but I think it
would make sense to have this in the coretests site if possible.
If it needs to be in coretets why is the code moved to integration tests ?
Isn't this just about integreation-tests needing to have its own updatesite ? (which
we can get easier once reddeer dependency variance is solved ?)