Re: [swtbot-dev] Moving build to Tycho

[Mickael Istria]

Le 10/11/2010 12:58, Ketan Padegaonkar a écrit : On 11/10/10 3:19 PM, Mickael Istria wrote: This is a dependency of the junit4_x plugin. Some of the internal API in junit 4.3 was declared an API somewhere in a later version. JUnit 4.3 ships with eclipse 3.4. Junit 4.5 ships with eclipse 3.5. Junit 4.8 ships with eclipse 3.6. As far as compatibility is concerned, SWTBot needs to be compatible with eclipse 3.4. There's more downloads for swtbot/3.4 than there is for swtbot/3.6. I totally agree with keeping compatibility. My aim at the moment is to find an organization of bundles that would avoid the hack of MANIFEST templates according to Eclipse/JUnit version in build. What is the technical constraint? CQ #3000 allows SWTBot to be coupled and shipped with JUnit 4.5. Let's take it from Orbit and put it on the update site and write code against JUnit 4.5. Then we are sure that anywhere SWTBot is installed, we have JUnit 4.5, and we don't have to keep some deprecated code, we can remove bundles and then the repository and the build are much easier to maintain. Is there something wrong with this approach? Ketan, what is your opinion on this suggestion? If memory serves right. The JDT-JUnit bundles on some versions of eclipse have an upper and a lower limit on the junit bundle. So upgrading junit on certain versions of eclipse breaks jdt. I think the issue is about the replacement of the bundle org.junit4 by the bundle org.junit 4.x. But it does not seem very problematic for SWTBot, since this is not the same application and runner for JUnit 4 and JUnit 3. But maybe there is another one I am not aware of... However it seems that since Helios, JDT requires at least JUnit 4.7. In my opinion, we should open a CQ to reuse org.junit 4.7 from Orbit, ship it with SWTBot, add also the org.junit4 "symlink" bundle from "plu...@org.junit4=v20100104,:pserver:anonymous:@dev.eclipse.org:/cvsroot/eclipse,,org.junit4" to keep it working with pre-3.6 Eclipse, and remove all the JUnit pre-4.7 stuff. Shipping JUnit 4.3/4.5/4.8 is certainly doable, just need to keep this dependency breakage in mind when doing any sort of osgi-foo :( This is the primary reason I'd given up on split packages and different bundles for different eclipse versions which pick up different manifests and source dirs, and an ant file that gave me this control without having to yakshave with osgi :( The best way to avoid using advanced OSGi constraint would be to force a version of JUnit for SWTBot. As I said a few lines above, if SWTBot works with org.junit 4.x, it could ship org.junit 4.7+ and only use this one as API. -- Mickael Istria R&D Engineer email : mickael.ist...@bonitasoft.com This message and any attachment (the "message") is intended solely for the addressees and is confidential. If you receive this message by mistake, please delete it and notify the sender immediately. Any use not in accordance with its purpose, any out-spread or disclosure, either as a whole or partially, is prohibited except with formal approval. Internet cannot guarantee the integrity of this message, therefore BonitaSoft will not be liable for the message if modified.

_______________________________________________
swtbot-dev mailing list
swtbot-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/swtbot-dev