Red Hat Bugzilla – Bug 1257739
Missing Dependency in kie-maven-plugin-6.2.0.Final-redhat-9.pom
Last modified: 2015-10-27 13:16:50 EDT
Created attachment 1067870 [details] error log Description of problem: kie-maven-plugin-6.2.0.Final-redhat-9.pom is missing the following dependency necessary in order to build a bpmn2 file there are some scenarios where it works to add this dependency to a kmodule, and other times are not <dependency> <groupId>org.jbpm</groupId> <artifactId>jbpm-bpmn2</artifactId> </dependency> Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. git clone https://github.com/sherl0cks/ba-enablement-domain 2. mvn clean install from domain, which should fail 3. mvn clean install from knowledge, which should pass Actual results: Expected results: steps 2 and 3 should pass Additional info: see error.log and success.log
Created attachment 1067871 [details] success log
Updating this to high priority. Please note that this issue indtroduces significant problems for creating projects that can round trip between business central and eclipse.
It seems the reproducer repo (https://github.com/sherl0cks/ba-enablement-domain) is missing the "domain" module, so it is not possible to reproduce the issue this way. Justin, could you try to add the jbpm-bpmn2 dependency directly to the plugin? I believe this should work. The reason why it is not there by default is because it is optional and people compiling only rules specific resources do not need it. However, I agree that having it there by default would be easier for users and would make the OOTB experience better. The plugin config would look like this: <plugin> <groupId>org.kie</groupId> <artifactId>kie-maven-plugin</artifactId> <version>6.2.0.Final-redhat-9</version> <extensions>true</extensions> <dependencies> <dependency> <groupId>org.jbpm</groupId> <artifactId>jbpm-bpmn2</artifactId> <version>6.2.0.Final-redhat-9</version> </dependency> </dependencies> </plugin>
Yikes - I had a pom.xml issue myself. That should be fixed. Please pull from that repo and retry the reproducer. I did try adding it directly to the plugin and that does indeed solve the problem. No idea you could do this - it's a rather obscure maven feature. So while it is possible, I agree that it should be added to the plugin OOTB for ease of use. Thanks for the prompt reply Petr
I just tried the reproducer again, but still can't reproduce the issue. Tried to run it from top-level dir, and also directly from the knowledge. The build is always successful. (Tried JDK6, JDK7, JDK8 + multiple maven versions). From the attached log, I think I am _not_ executing exactly the same projects as were used to generate the logs (at least the order is different). Justin, the reproducer in the repo works for you? Could you also run Maven in debug mode and with stracktraces on (mvn clean install -e -X) and attach the log. It should be possible to see what is going on from those logs (even if we can't reproduce it locally). Thanks!
Petr, It looks like I can't reproduce this anymore either, most likely the issue was related to that errant dependency. If I remove jbpm-bpmn2 dependencies then of course it fails. That code is pushed to the same repo in branch jbpm-bpmn2-bug (https://github.com/sherl0cks/ba-enablement-domain/tree/jbpm-bpmn2-bug). Log attached as jbpm-bpmn2-bug.log.
Created attachment 1071343 [details] jbpm-bpmn2-bug.log
Justin, do I understand correctly that you can't reproduce the issue anymore? The log you posted is when the dependency is not declared, correct? The plugin by default only depends on drools-core and drools-compiler, so even when using decisions tables, one needs to explicitly add that dependency in the pom. There is a lot of optional dependencies like decision tables, decision trees, pmml, processes, etc and we included them all the plugin would become rather heavy. So it is OK to leave as it assuming the build works when the jbpm-bpmn2 dependency is added directly to the project?
You are correct that it is no longer reproducible once the pom is corrected. What is the concern with a heavy build plugin? The dependencies don't get added to the final archive, just used during compilation? Why should users be forced to figure out all these dependencies on their own? In practice, most people get rid of the kie-plugin for java centric development because it is a total pain in eclipse. I have a strong understanding of maven and a very strong understanding of kie and this was a challenge for me. I think it is in our best interests to simply make this easier for people to use.
I personally disagree with a few sentences in last Justin's comment. In particular I'm a bit surprised by this question: "Why should users be forced to figure out all these dependencies on their own?" Isn't this what they normally do with ANY Java project? You figure out the dependencies you need and add them to your pom in order to make your project compile and that's all. Sorry but I also don't see what there is of so challenging here: it's enough to add the necessary dependencies into the pom's top-level <dependencies> block. How is this different from any other required dependency? Finally I usually like to keep things modular and minimal. For instance why should I make the plugin to explicitly depend on PMML (or any other technology or format that we will decide to cover in future) even if 99.99% of projects won't ever use it? Edson, I already chatted quickly with Petr about this issue and I found that his point of view is quite different from mine. Of course I'm open to discuss this and explicitly add those dependencies to the plugin if we will decide so. This will also require to move the plugin somewhere else (-integration?) but very likely the effort required for this will be limited so this is not a relevant point, but only something else that has to be considered. Please let me know what you think we should here. Thanks, Mario
Mario, the question here is: are the dependencies required by the project itself, or only by the plugin at build time? If it is the first, then the user should be responsible for adding them to the main dependencies section of the pom. If the dependencies are only required by the plugin in order to build the project, then the dependencies should be part of the plugin definition. It is not clear to me which is the case here?
If the project only contains drools/jbpm artifacts then yes, the dependencies are necessary only by the plugin at build time. In this sense I believe that you and Petr are right when you say that they should be part of the plugin definition. Thanks for having clarified this.
Excellent - are we all in agreement to add the build time dependencies to the plugin?
Yes, I am preparing and testing the changes just now.
The plugin has been moved into droolsjbpm-integration repository so that it can depend on jbpm-bpmn2. Following jars are included by default (they should cover all supported resource types): - drools-compiler - drools-decisiontables - drools-templates - drools-pmml - drools-scorecards - jbpm-bpmn2 Commits on 6.3.x branch: https://github.com/droolsjbpm/drools/commit/809d0a9a https://github.com/droolsjbpm/droolsjbpm-integration/commit/6fbc1c87 Note: The changes are not part of the upcoming 6.3.0.Final, and thus won't make it into the 6.2.0.ER3 build. They will appear in the next product build.
Verified in 6.2.0.ER4 by building projects from attached reproducer git repo. Everything builds fine.