kjar maven dependencies are downloaded even if scope is set to provided or test (maybe bug?)

[Lindsay Thurmond]

The creation of a new kbase triggers the specified rules kjar to be downloaded from the remote Maven repository.  This works as expected but has the side effect of also downloading the Maven dependencies for the kjar.  The problem is that it is downloading ALL the Maven dependencies even if they are specified as provided or test scope.  I have the requirement to prevent this from happening as we shouldn't need to download dependencies into the local .m2 repo that are already on the running application's classpath (and we shouldn't need to download test dependencies at all during runtime).  

I did some digging into the Drools source to and found out that

 KieRepositoryImpl#getKieModule()

contains logic to check the classpath for the KieModule and if it can't find it to load everything from the Maven repo which includes downloading all the dependencies (and dependencies of dependencies and so on).

Unfortunately the code for checking the classpath is not actually implemented and looks like this:

private KieModule checkClasspathForKieModule(ReleaseId releaseId) {
    // TODO
    // ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
    // URL url = classLoader.getResource( ((ReleaseIdImpl)releaseId).getPomPropertiesPath() );
    return null;
}

After nothing is found on the classpath everything is downloaded from Maven. You can see all the stuff that is going to be downloaded (if its not already in your Maven repo) in

DefaultProjectDependenciesResolver#resolve() //line 159

 You can even see here that the dependencies have been marked as provided, but regardless they are going to be downloaded.

I'm wondering if this is the intended behavior or if there is a plan to change/fix this in the future.  I tested this with Drools 6.3.0 Final and attached screen shots of the dependency trees I see when tracing the source.

I looked through the Drools open issues and found this similar one complaining about errors when looking for test dependencies and am thinking its related.  https://issues.jboss.org/browse/DROOLS-1051  I couldn't find any other relevant issues.

Right now my team is stuck and having to find a workaround for how to manage these extra dependencies from within a docker container (which I'm not asking about, just giving you background for why we need to prevent it other than the obvious overhead of downloading stuff we don't need).

[Petr Široký]

Hello,

I agree that "test" and "provided" dependencies should not be fetched at runtime.

https://issues.jboss.org/browse/DROOLS-1051 looks very similar, but seems to just request ignoring failures when fetching the test scoped deps (instead of completely ignoring them).

Thanks for reporting this. I will take a deeper look and probably will simply just exclude the test and provided scoped dependencies.

Petr