cc'ing jbosstools-dev: > Probably I missed discussion about this I'm sorry. nope - it haven't really been discussed. > What do you think about adding JBT integration tests (SWTBot tests) to JBT coretest ( http://download.jboss.org/jbosstools/updates/nightly/coretests) 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 ?

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

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

/max

On 19. 11. 2012, at 9:35, Vlado Pakan <vpakan(a)redhat.com&gt; wrote: > On 11/17/2012 12:26 AM, Max Rydahl Andersen wrote: >> 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 Nick? :) >> >>> What do you think about adding JBT integration tests (SWTBot tests) to JBT coretest ( http://download.jboss.org/jbosstools/updates/nightly/coretests) 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. >> >> 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 "released" > 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 "ready". >> >>> 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. -Martin

>>> 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 > Nick? :) 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 ( http://download.jboss.org/jbosstools/updates/nightly/coretests) 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 different.

>>> 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 "released" >> 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 "ready". Yes, we need to sit down and look at the dependencies and when/where those tests need to be run. 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 ?)

/max

>>>>> 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 ? > We wanted to have ability to change our tests after code freeze because > we have to fix tests once new version of JBT/JBDS is available for QE. the base library for doing tests aren't part of that - that should just affect the main test code, right?

>> 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 different. >> > I think to have SOA tests separated in different repo would be good. I > don't know why it was put to the same repo as "core" integration tests. We cant run a git migraiton on the integration-tests repo to split it up. Your call.

>>> 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 ?) > To have separate update site for integration-tests would be good. I was > just thinking that it would be easier to add integration-tests to > existing coretests update site that it will need less work than creating > new update site and changing our builds to use it. which builds - you guys have your own root parent pom now you can add additional site to afaik. You already did it for reddeer, doing that is not bad in itself, bad was that it was/is? pointing to an updatesite not mirrored/maintained/etc.

/max

>>>> This beckon to question why bot ext was ever moved in the first place ? >>> We wanted to have ability to change our tests after code freeze because >>> we have to fix tests once new version of JBT/JBDS is available for QE. >> the base library for doing tests aren't part of that - that should just affect the main test code, right? > Unfortunately sometimes we are fixing also bot ext part when new > JBDS/JBT build is available for QE thats a shame :( >>>> 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 different. >>>> >>> I think to have SOA tests separated in different repo would be good. I >>> don't know why it was put to the same repo as "core" integration tests. >> We cant run a git migraiton on the integration-tests repo to split it up. Your call. > OK. We will think about it. sorry - that should say "We *can* run git migration scripts". >>>>> 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 ?) >>> To have separate update site for integration-tests would be good. I was >>> just thinking that it would be easier to add integration-tests to >>> existing coretests update site that it will need less work than creating >>> new update site and changing our builds to use it. >> >> which builds - you guys have your own root parent pom now you can add additional site to afaik. You already did it for reddeer, doing that is not bad in itself, bad was that it was/is? pointing >> to an updatesite not mirrored/maintained/etc. > I meant builds on machydra running all ours bot tests. We QE have to > discuss abut creating update site for integration tests. Once we decide > if we gonna do it I will inform you. What I'm suggesting is that the integration-tests gets published to 1 or 2 updatesites under download.jboss.org just like the other builds - but it kinda requires the git repository we built has a consistent set of dependencies IMO. /max _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

The division of the tests into 2 sites sounds OK - but in the JIRA it sounds like you are recommending one 1 site? --Len (Sent from my iPhone) On Nov 20, 2012, at 12:10 PM, Nick Boldt <nboldt(a)redhat.com&gt; wrote: > +1 for publishing i-tests to 1 or 2 sites: > > * 1 for JBT/JBDS Core tests (and upstream non-bot tests, if needed, plus > framework plugins) > > * 1 for JBT/JBDS SOA/BRMS ("Integration Stack") tests (and upstream > non-bot tests, if needed, plus framework plugins) > > Can we continue the conversation in > https://issues.jboss.org/browse/JBIDE-12974, if anything more than +1s > are needed? > > N > > On 11/20/2012 11:16 AM, Max Rydahl Andersen wrote: >> >>>>>> This beckon to question why bot ext was ever moved in the first place ? >>>>> We wanted to have ability to change our tests after code freeze because >>>>> we have to fix tests once new version of JBT/JBDS is available for QE. >>>> the base library for doing tests aren't part of that - that should just affect the main test code, right? >>> Unfortunately sometimes we are fixing also bot ext part when new >>> JBDS/JBT build is available for QE >> >> thats a shame :( >> >>>>>> 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 different. >>>>> I think to have SOA tests separated in different repo would be good. I >>>>> don't know why it was put to the same repo as "core" integration tests. >>>> We cant run a git migraiton on the integration-tests repo to split it up. Your call. >>> OK. We will think about it. >> >> sorry - that should say "We *can* run git migration scripts". >> >>>>>>> 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 ?) >>>>> To have separate update site for integration-tests would be good. I was >>>>> just thinking that it would be easier to add integration-tests to >>>>> existing coretests update site that it will need less work than creating >>>>> new update site and changing our builds to use it. >>>> >>>> which builds - you guys have your own root parent pom now you can add additional site to afaik. You already did it for reddeer, doing that is not bad in itself, bad was that it was/is? pointing >>>> to an updatesite not mirrored/maintained/etc. >>> I meant builds on machydra running all ours bot tests. We QE have to >>> discuss abut creating update site for integration tests. Once we decide >>> if we gonna do it I will inform you. >> >> What I'm suggesting is that the integration-tests gets published to 1 or 2 updatesites under download.jboss.org just like the other builds - but it kinda requires the git repository we built has a consistent set of dependencies IMO. >> >> /max >> >> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

>>>>> This beckon to question why bot ext was ever moved in the first place ? >>>> We wanted to have ability to change our tests after code freeze because >>>> we have to fix tests once new version of JBT/JBDS is available for QE. >>> the base library for doing tests aren't part of that - that should just affect the main test code, right? >> Unfortunately sometimes we are fixing also bot ext part when new >> JBDS/JBT build is available for QE > thats a shame :( It's reasonable. For example when target platform is changed and Eclipse UI behaves differently than previous version we have to fix it within bot ext even when some preferences default value is changed.

>> It's reasonable. For example when target platform is changed and Eclipse >> UI behaves differently than previous version we have to fix it within >> bot ext even when some preferences default value is changed. > can you point me to a github commit that outlines this ? > > I don't understand why shared code should be affected by target platform change ? > > /max Because when target platform is changed Eclipse UI can change behavior. I don't know commits but here are examples I remember: - JBT switched to Juno - SWTBot was not able to find toolbar buttons and we had to implement workaround - with target platform changed automatic code completion was introduced (when there is only one item for code completion it's automatically inserted when user press Ctrl+Space) and we have to add new shared method working with this scenario.