CDIUnit does'nt discover Test class as CDI class when using gradle about cdi-unit HOT 13 CLOSED

I don't know much about Gradle. Is it possible to tell if the a folder is a test output folder at runtime? Is it standardised like in Maven?

from cdi-unit.

Not really, the dir structure looks like this:
[cid:[email protected]]

You can check for build/classes/main and build/classes/test. Not very stable.

IMHO Best idea would be to use the weld BeanManager to check if a bean is discovered instead of using own code for discovery.
That solves the issue for all different types of environements (since weld takes care of it).

from cdi-unit.

Strictly speaking I think the CDI spec requires beans.xml to be present in a classpath location for classes to be included in the deployment, so I would have thought that even if we used standard Weld discovery it would still ignore your classes.

Also events can cause whole subsystems of your app to start when they are not required for the test and makes the startup time to run a test case too large.

The best I can think of here is to add some extra logging so that if a class is included in additional classes but was missing beans.xml then an error is reported with instructions about how to resolve it.

from cdi-unit.

That's interesting. So unlike Maven Gradle doesn't combine resources and classes in the compile step? Your images of directory structure in the earlier mail didn't come through. Can you send them to me directly [email protected] so that we are talking from the same page.

CDI events as in:

@Inject
Event<Object> foo;

from cdi-unit.

Unfortunately not:
http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.SourceSetOutput.html

I maybe could configure output.resourcesDir = output.classesDir. I am not sure if this will have some sideeffects.

from cdi-unit.

I'm not completely certain, but I have a feeling that the default Weld discovery would have an issue with this as well (unless classpath entries that are not archives are treated differently).

The only reason the extra classloaders are used is to be able to detect when a classpath entry has got the required beans.xml thus solving #14

If you start up a standard WeldSE container does it find your classes?

from cdi-unit.

The BeanManager on Test Startup found it. See attached screenshot (hope this worked).

from cdi-unit.

I think screenshots don't work with GitHub.

The best thing to do is if you have a minimal project that you can package up and send to me directly [email protected] then I will have a look.

It could be that CDI treats classpath entires that are not archives differently, in which case this would be a bug.

from cdi-unit.

I believe I have the same issue as well. When using gradle to start my integration tests using CDIUnit, I got the WELD-1408 error (the same exact tests work fine in my IDE). The workaround I used was to copy the resources output directories over to the main and test output directories. When I reran the tests in gradle, they worked.

from cdi-unit.

I have added classes/test/ as a directory that is always CDI enabled in the same way as test-classes/ is for maven.
This should fix this issue for 99% of Gradle users.

from cdi-unit.

Works for us.

from cdi-unit.

I have added classes/test/ as a directory that is always CDI enabled in the same way as test-classes/ is for maven.
This should fix this issue for 99% of Gradle users.

how did you do this? I cant find it in the source code?

from cdi-unit.

It's in WeldTestUrlDeployment.populateCdiClasspathSet. Basically it's a hack as we can't tell what the classpath is going to be for Gradle and resources don't get combined so beans.xml isn't ever going to be present (which is a requirement for CDI), so I have added the default paths as always being cdi enabled.

from cdi-unit.