<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000'>Nick - looks good - one question - what about the dependency jbosstools-integration-stack-itests has on Zest?<br><br><br>-- Len<br><br><br><br><br><hr id="zwchr"><blockquote style="border-left:2px solid rgb(16, 16, 255);margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Nick Boldt" <nboldt@redhat.com><br><b>To: </b>"Max Rydahl Andersen" <max.andersen@redhat.com><br><b>Cc: </b>"jbosstools-dev jbosstools-dev" <jbosstools-dev@lists.jboss.org><br><b>Sent: </b>Thursday, March 14, 2013 9:02:55 AM<br><b>Subject: </b>Re: [jbosstools-dev] Time for a new SOA test repo?<br><br>So after much discussion, I'm hearing that:<br><br>1) individual projects' non-integration tests (that is, relatively fast <br>UNIT tests) will run as part of those projects' builds, and their <br>features & plugins will be published to the staging composite site, then <br>aggregated into two aggregate sites, as we did in JBT 4.0.0 and before:<br><br>* http://download.jboss.org/jbosstools/updates/nightly/coretests/<br>* http://download.jboss.org/jbosstools/updates/nightly/soatests/<br><br>2) jbosstools-integration-tests repo will be split into:<br><br>* jbosstools-itests and<br>* jbosstools-integration-stack-itests<br><br>which will publish 2 SEPARATE update sites. Name choice is based on <br>Maven "itests" convention:<br><br>http://docs.codehaus.org/display/MAVENUSER/Maven+and+Integration+Testing<br><br>3) jbosstools-itests site will build using the JBT target platform <br>(Kepler). We should also ensure we are building a Juno version so that <br>this site can exist and the jbosstools-integration-stack-itests build <br>can depend on it. This is where UI testing framework code such as <br>org.jboss.tools.ui.bot.ext should go.<br><br>4) jbosstools-integration-stack-itests site will build using the JBTIS <br>target platform (Juno) and will depend on the jbosstools-itests update <br>site from 4.0.x, as well as the upstream coretests and/or soatests <br>sites, if necessary.<br><br>---<br><br>As to the Zest question, it will only be added to the JBT 4.1 target <br>platform for *Kepler*, since it is only that version of Central which is <br>planned to be updated w/ SpringIDE 3.2. Should we decide we want to <br>include SpringIDE 3.2 in Central for JBT 4.0.1 / JBDS 6.0.1 as well, we <br>would need to add Zest to the Juno target platform too.<br><br>If that is something that PM and QE would like to happen, please provide <br>input in https://issues.jboss.org/browse/JBDS-2395 so I can set that up <br>ASAP.<br><br>Thanks!<br><br>Nick<br><br>On 03/14/2013 08:29 AM, Max Rydahl Andersen wrote:<br>>>>> The problem is (was) that:<br>>>>> * The ESB tests require the ESB UI which requires Zest - tests build fails on master for 7.0<br>>>>> * Zest is not in the JBT test package, but it is in the JBTIS test package<br>>>><br>>>> we probably need Zest for other reasons anyway so that probably makes sense to add to core TP anyway.<br>>><br>>> ok, so one problem will be solved. but spliting the repos make sense anyway imo.<br>><br>> Yes, totally agree - remember I was the one objecting when you put all tests into the integration test repo :)<br>><br>>>>> * Adding JBTIS TP repo to our root pom in integration-tests would affect all our tests:<br>>>><br>>>>> -> The tests would run slower<br>>>><br>>>> Hopefully not...did you see a big effect ?<br>>><br>>> 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<br>><br>> 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.<br>><br>> 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.<br>><br>>>>> -> The JBTIS test package might affect our tests - we might miss issues of plugins not being in the JBT test package<br>>>><br>>>> not following what you mean here ? if JBTIS test package does affect your test we want to know about it ;)<br>>><br>>> 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.<br>>> 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).<br>><br>> Yes, completely agree that should be fixed.<br>>><br>>>> 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.<br>>><br>>> Sure, that's why it would be good for JBTIS integration tests to be separate - they need to use JBTIS TP and update site.<br>>><br>>>>> So - what are the solutions?<br>>>><br>>>> Split out the github repository and move the integration-platform tests to a separate repo.<br>>><br>>> +1<br>><br>>>>> Second, long-term<br>>>>> * We had talked about this in the past - creating a new SOA test repo<br>>>><br>>>> integration-test repo - its no longer just SOA.<br>>><br>>> We tend to say "soa integration tests" because integration stack integration tests is even more confusing. Do you have a better suggestion here? :)<br>><br>> integration-stack-tests ?<br>><br>>>>> -> This will mean that existing 4.0.x work would move to the new repo<br>>>><br>>>> you'll need to migrate the history very carefully yes.<br>>><br>>> Yeah, another exercise for filter-branch/fast-filter I guess.<br>><br>> Yeah - if you guys can create a script for it i'm more than willing to help review it.<br>><br>> /max<br>> _______________________________________________<br>> jbosstools-dev mailing list<br>> jbosstools-dev@lists.jboss.org<br>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev<br>><br><br>-- <br>Nick Boldt :: JBoss by Red Hat<br>Productization Lead :: JBoss Tools & Dev Studio<br>http://nick.divbyzero.com<br>_______________________________________________<br>jbosstools-dev mailing list<br>jbosstools-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/jbosstools-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span><br>Len DiMaggio (ldimaggi@redhat.com)<br>JBoss by Red Hat<br>314 Littleton Road<br>Westford, MA 01886 USA<br>tel: 978.392.3179<br>cell: 781.472.9912<br>http://www.redhat.com<br>http://community.jboss.org/people/ldimaggio<br><br><a href="http://www.redhat.com"><img doc="Briefcase/RHxJBpngthumb.png" src="cid:9c26201eb58a7437491d10121eeb6f481c644e80@zimbra" style="border: 0pt none;"></a><br><span name="x"></span><br></div></div></body></html>