Use stand-alone weld-se-core dependency instead of an uber-jar weld-se

[tomasz]

The org.jboss.weld.se:weld-se jar is an uber-jar that comes bundled with all its dependencies inside. I think it's better to use the weld-se-core artifact as a dependency, and let Maven resolve the dependencies' versions.

The problem is it can cause runtime exceptions when your project is using classes from different versions of dependencies that are bundled in the weld-se uber-jar. For me it was causing NoSuchMethod exceptions when using Guava collections. I'm using Guava 18.0, weld-se comes bundled with 13.0.1. The classes I've used were loaded from the weld-se jar, even though there's an explicit Guava dependency in my project's pom.xml.

I can be completely, totally and utterly off base here:
Using the weld-se-core we can let Maven worry about the multiple versions of a dependency. The problem is that Maven will only pick one version of the dependency using the "nearest in the dependency tree" strategy. It did solve my problem, and left all CDI functioning properly, but it's possible it can cause the same problems for other users.

For what it's worth, the mvvmfx-cdi test passed when run with weld-se-core:2.2.11.Final and guava:18.0 as forced dependencies.

[manuel-mauky]

Thanks for your pull request.
I will test your change with some example projects within the next days.

[manuel-mauky]

After some testing I haven't found any problems with weld-se-core as dependency. Indeed it wasn't possible to use the latest guava version which was a suprise for me. I didn't know this problem with weld-se. Thanks for this advice.

[tomasz]

Glad I could help. 😃