Description of problem: When the workbench generates a maven pom, it should set the archetype to kjar and configure the plugin so that if users clone the repo and compile with maven in the command line, they get the same compile time validation of the content as well as the bytecode caching that kjars support. Version-Release number of selected component (if applicable): 6.0.0.ER7 How reproducible: Generate a project in the workbench, check the pom. POM file should include: ... <packaging>kjar</packaging> ... <build> <plugins> <plugin> <groupId>org.kie</groupId> <artifactId>kie-maven-plugin</artifactId> <version>${project.version}</version> <extensions>true</extensions> </plugin> </plugins> </build> ...
Edson, Can you advise what default dependencies a new project should have too? This shows drools-core and drools-compiler:- https://github.com/droolsjbpm/drools/blob/master/kie-maven-plugin-example/pom.xml Whereas this shows only the plugin itself (and a bug that has been discussed between Rikkola and mfusco - need to include the dependency in the plugin itself):- https://github.com/droolsjbpm/drools-wb/blob/master/drools-wb-rest-defaultapprover/pom.xml
Michael, Depending on drools-compiler should be enough. All other dependencies would be retrieved transitively. Lets talk about the plugin dependency bug and figure out what to do there.
After discussion with Edson and Mario it was agreed to only add the kie-maven-plugin to Projects' pom.xml. This is considered a short-term solution; as ideally drools-compiler needs to be included as a dependency so tests can be ran from the CLI for Projects created within KIE-WB. At present, adding drools-compiler, causes a number of undesirable side-effects:- (1) Validation added for https://bugzilla.redhat.com/show_bug.cgi?id=1007055 fails when drools-compiler is a project dependency; due to drools-compiler using various "provided" scope classes. The whole point of the captioned BZ is to check all classes required by a dependency are available. (2) If we slacken validation for the above (e.g. report them as warnings, rather than errors) then all of drools-compiler classes become available for rule authoring (c.~200+ classes, spanning MVEL, ANTLR, Janino). These not only confuse the authoring environment but also lead to a massive degradation in workbench performance.
Issue (1) has been resolved under BZ https://bugzilla.redhat.com/show_bug.cgi?id=1063742. Issue (2) can be forgotten: It is possible to have the KJAR compile without needing drools-compiler as a project dependency (although any code wanting to use a KJAR at runtime would obviously need the dependency).
Verified fixed in 6.0.1-ER1.