JBossDeveloper

Thanks for the precisions, Aslak.

You are right that the XmlInclude change was breaking, sorry about that but I didn't have much choice in this case.  I'll make sure to document these more extensively if it happens again.

The removed packages were not used at all (not even by TestNG), so hopefully this didn't have any impact on Arquilian.

I'm not sure how to address your Guice concern, though:  TestNG embeds its dependencies in its jar file (which causes problems of its own, but that's a separate topic), I don't see what more I can do to make sure that additional dependencies have no impact on users.

Finally, don't hesitate to contact me directly next time you are running into issues, I'll be happy to work with you to make this process as smooth as possible.

--

Cédric

Cédric, thanks for the reply.

I didn't notice Guice was bundled in the jar. So the user don't have to add the extra dep as I first suspected.

But by bundling Guice with TestNG, you have efficiently killed TestNG as a possible test framework for all users of Guice. One Guice release / patch and they're screwed. Do you provide a TestNG-without-guice artifact ?

-aslak-

Hi Aslak,

I don't provide a Guice-less TestNG jar file at the moment, which hasn't been a problem since Guice hasn't released much since 2.0.  I definitely plan to, though, and I'm actually already doing this with another dependency (BSH:  TestNG comes as a "bsh" and "nobsh" jar file).

Which means that very soon, I'll have to offer four different Jar files (bsh-guice, nobsh-guice, bsh-noguice and nobsh-noguice).

I wish Java offered a good solution for this kind of problem because this is clearly not scalable...

--

Cédric

I implemented this in the current beta (http://testng.org/beta ):

The default jar contains both Guice and BSH and the directory other-jars/ contains all the other combinations.

The Eclipse plug-in uses the default jar file for now.

Thanks Cedric.