Ok, I got it.
The dependency is specified as an import package, not as a
Require-Bundle. So that with Eclipse, the import-package will resolve
to org.junit4 bundle (which exposes JUnit 4.3), and in later version,
it will resolve to org.junit bundle.
The constraint is that we cannot have org.junit >=4 in pre-Helios
Eclipse.
Let's repeat my goal: Having a single update-site for SWTBot, whatever
version of Eclipse it targets. The choice must be made by selecting the
right features to install.
I think that a solutions here are to extract the code specific to a
version of JUnit in bundle org.eclipse.swtbot.junit4_x. Once this is
extracted, we have a "normal" and a JUnit-specific bundle. Then we
split this bundle into 2 (one for each version of JUnit), using
constrained dependencies on bundle org.junit4 or org.junit rather that
packages, and provide these specific bundles in different additional
features.
I hope I'll have time to give it a try soon.
Regards,
Le 22/11/2010 17:06, Mickael Istria a écrit :
The SWTBot bundle that causes complexity is
org.eclipse.swtbot.junit_4.x, which has several versions of the same
class according on the version of JUnit: 4.3 or 4.5. If I understand
correctly, the issue with jdt.junit is the one that causes trouble when
moving from JUnit 3.8 to JUnit 4.x (See [1]). This is not a blocking
point for choosing definitely a version of JUnit 4 in SWTBot.
Are we speaking about the same issue with jdt.junit? If no, could you
provide me some more documentation on this topic?
By the way a started a Git branch for my experiences with SWTBot
(inverting dependencies to avoid these headaches with JUnit and Eclipse
versions, and start building with Tycho). It is available at [2], but
since I am not at all familiar nor easy with Git, and since I want to
change everything in the same time, it may be a little messy... But
feel free to comment it if you have time.
Regards,
[1]
http://dev.eclipse.org/viewsvn/index.cgi/org.eclipse.jdt.junit.runtime/META-INF/MANIFEST.MF?view=log#rev1.43
[2] https://github.com/mickaelistria/SWTBot
Le 22/11/2010 15:24, Ketan Padegaonkar a écrit :
On Mon, Nov 22, 2010 at 5:07 PM, Mickael
Istria <mickael.istria@xxxxxxxxxxxxxx>
wrote:
Currently SWTBot has some
hacks to support 2 different versions of
JUnit. I don't understand *why*. This adds much more complexity than
value to the project, whereas SWTBot could simply be built against a
specific version of JUnit, and ship with it. Am I missing a technical
issue that explains this choice?
Older versions of eclipse don't work with newer versions of
junit. Dropping in a new junit bundle breaks jdt.junit bundle that is
essential to run any junit/pde-junit/swtbot tests. The only other way
(that I know of) to support this is to branch out but I'm not sure I
have the capacity to manage 3 branches and ensuring that that patch
sets are applied to all three branches.
I'm open to other ideas to solving this problem.
_______________________________________________
swtbot-dev mailing list
swtbot-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/swtbot-dev
--
Mickael Istria
R&D Engineer
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.
--
Mickael Istria
R&D Engineer
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.
|
