I have a simple process, call it X,that is built by Maven, packaged in a kjar file, and placed into our Nexus repository. I can go to the jBPM Console and add that unit for deployment by specifying the GAV; jBPM dutifully downloads the kjar and anything else it needs into the local repository and the unit is deployed. No problems there.
Now I have another process, call it A, that has two dependencies: B which is another process packaged in a kjar, and C which is a utility JAR file used in a lot of other projects, it isn't a kjar. Now when I attempt to deploy A to jBPM, once again A, B and C are all downloaded from Nexus and placed into the local repository but deployment fails with errors like this:
Only a type can be imported. aaa.bbb.ccc.ddd.SomeClass resolves to a package
SomeOtherClass cannot be resolved to a type
Each of the classes mentioned in the error are classes defined in C.
If I take C.jar and place it in jbpm-console.war/WEB-INF/lib, then A deploys successfully.
So my question:
1) Is there anything that I could do to avoid having to place C.jar into the jbpm-console lib directory? Something like adding a descriptor/file/config somewhere.
2) If I have to place C.jar into the jbpm-console lib directory, what is the best mechanism to isolate C.jar? I can use Maven's copy-dependencies, but there is no filter that can be used to differentiate kjars from regular jars (they are all just jar artifacts as far as Maven is concerned).
For question 2, note that what I have given here is a simplified example, In my environment I have about 20 service kjars, many of which depend on each other. And in addition I have about another dozen or so helper JARs specifically for use by the jBPM processes I have developed, and perhaps a hundred or more other JAR files, some open source, others proprietary, that are transitive dependencies pulled in by the service jkars. So while I could easily manage the simple case containing only components A, B and C, in the real environment things are much more difficult and a really need an automated way of separating out the dependencies that will work just by being in the local repository from those that need to be in the lib directory.