[jboss-jira] [JBoss JIRA] (DROOLS-419) "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
Matteo Mortari (JIRA)
issues at jboss.org
Thu Jan 30 14:25:29 EST 2014
Matteo Mortari created DROOLS-419:
-------------------------------------
Summary: "Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
Key: DROOLS-419
URL: https://issues.jboss.org/browse/DROOLS-419
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 6.0.1.Final
Environment: Right hand side of diagram at http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933
Reporter: Matteo Mortari
Assignee: Mark Proctor
Attachments: 20140130.drools6testmvnlatest.zip
Hello, this is to report (potentially) a bug about "Cannot find KieModule: com.acme:X:RELEASE" or "Cannot find KieModule: com.acme:X:LATEST" when invoking {{kieServices.newKieContainer( releaseId )}} with LATEST or RELEASE instead of explicit version number (eg: 0.0.1) on a application where the KIE module Rule artifact project kjar has been locally-installed from remote Maven repository.
More precisely, with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , I mean that before launching Application, I performed
{code}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
{code}
h5. Disclaimer
I'm not 100% sure whether this is bug of maven process, maven libraries, or Drools library; I prefer to report it anyway because likely could impact other users if installing via the maven-dependency-plugin:get goal, especially in distributed or JavaEE deployments? Sorry if actually not Drools library bug, I report all details below, *including current workaround* I have found to avoid this issue.
h5. DETAILS
Suppose there is a kjar artifact KIE module, {{'drools6testmvnlatest.therules'}}, as per attached project zip file. And this artifact is installed in local nexus repository at http://nexus-hostname/nexus/content/repositories/releases/ .
Now ,suppose with reference to http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/#d0e933 , _Application_ is jar {{'drools6testmvnlatest.thestandaloneengine'}} as per attached project zip file, and is being executed on a dedicate machine, not the development computers.
{code:title=App.java}
public static void main( String[] args ) {
KieServices kieServices = KieServices.Factory.get();
ReleaseId releaseId = kieServices.newReleaseId( "com.acme", "drools6testmvnlatest.therules", args[0] );
KieContainer kContainer = kieServices.newKieContainer( releaseId );
KieBaseConfiguration kieBaseConf = kieServices.newKieBaseConfiguration();
kieBaseConf.setOption( EventProcessingOption.STREAM );
KieBase kBase = kContainer.newKieBase(kieBaseConf);
for ( KiePackage a : kBase.getKiePackages()) {
for (Rule r : a.getRules()) {
logger.info("KiePackage {} Rule {}", new Object[]{a.getName(), r.getName()});
}
}
}
{code}
The first thing to do before executing it, would be to fetch and install into local .m2 repository the required KIE module Rule artifact project kjar {{'drools6testmvnlatest.therules'}}. To do so, the following command is executed:
{code}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get -Dartifact=com.acme:drools6testmvnlatest.therules:LATEST -DrepoUrl=http://nexus-hostname/nexus/content/repositories/releases/
{code}
Execution of
{code}
java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar RELEASE
{code}
Would generate the following stack trace
{code}
Exception in thread "main" java.lang.RuntimeException: Cannot find KieModule: com.acme:drools6testmvnlatest.therules:RELEASE
at org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:86)
at com.acme.drools6testmvnlatest.thestandaloneengine.App.main(App.java:24)
{code}
Same for LATEST as launch parameter.
But fixed version, eg: 0.0.2 as launch parameter, will work.
{code}
D:\inbox>java -jar drools6testmvnlatest.thestandaloneengine-jar-with-dependencies.jar 0.0.2
2014-01-30 19:24:12,128 [main] INFO org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added:ZipKieModule[ ReleaseId=com.acme:drools6testmvnlatest.therules:0.0.2file=D:\Documents and Settings\mmortari\.m2\repository\com\acme\drools6testmvnlatest.therules\0.0.2\drools6testmvnlatest.therules-0.0.2.jar]
2014-01-30 19:24:12,440 [main] INFO com.acme.drools6testmvnlatest.thestandaloneengine.App - KiePackage com.acme.drools6testmvnlatest.therules Rule Dummy rule on String
{code}
Please notice at this point this is the content of the .m2 local repository (this led me to discover the workaround)
{code}
D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
└───drools6testmvnlatest.therules
│ maven-metadata-nexus-hostname-nexus.xml
│ maven-metadata-nexus-hostname-nexus.xml.sha1
│ maven-metadata-temp.xml
│ maven-metadata-temp.xml.sha1
│ resolver-status.properties
│
└───0.0.2
drools6testmvnlatest.therules-0.0.2.jar
drools6testmvnlatest.therules-0.0.2.jar.sha1
drools6testmvnlatest.therules-0.0.2.pom
drools6testmvnlatest.therules-0.0.2.pom.sha1
_remote.repositories
{code}
h5. WORKAROUND
The only options 1-2-3 ways I found to avoid this issue, and be able to launch successfully with RELEASE or LATEST as the launch parameter for the ReleaseId version, is to:
h6. Workaround Option 1
Do 'fake' a pom.xml with the dependency, something similar to:
{code}
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.acme</groupId>
<artifactId>fakepom</artifactId>
<version>0.0.1</version>
<packaging>jar</packaging>
<dependencies>
<dependency>
<groupId>com.acme</groupId>
<artifactId>drools6testmvnlatest.therules</artifactId>
<version>RELEASE</version>
</dependency>
</dependencies>
</project>
{code}
And then launch maven in the same directory of this 'fake' pom.xml with the following command:
{code}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:go-offline
{code}
This usually generate the 'maven-metadata-local' file in the local .m2 repo:
{code}
D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
└───drools6testmvnlatest.therules
│ maven-metadata-nexus-hostname-nexus.xml
│ maven-metadata-nexus-hostname-nexus.xml.sha1
│ maven-metadata-local.xml
│ maven-metadata-local.xml.sha1
│ maven-metadata-temp.xml
│ maven-metadata-temp.xml.sha1
│ resolver-status.properties
│
└───0.0.2
drools6testmvnlatest.therules-0.0.2.jar
drools6testmvnlatest.therules-0.0.2.jar.sha1
drools6testmvnlatest.therules-0.0.2.pom
drools6testmvnlatest.therules-0.0.2.pom.sha1
_remote.repositories
{code}
h6. Workaround Option2
Well, actually this is to report that not all the time the Option1 works, so what I do, is that I copy-rename the 'maven-metadata-temp.xml' file into the 'maven-metadata-local.xml' file.
h6. Workaround Option3
Download manually the .jar file, the .pom file from the nexus webapplication, then usual maven
{code}
D:\inbox>mvn install:install-file -Dfile=drools6testmvnlatest.therules-0.0.2.jar -DpomFile=drools6testmvnlatest.therules-0.0.2.pom -Dpackaging=jar
{code}
This will create directly the 'maven-metadata-local.xml' file and the ' -Dpackaging=jar' option do force it to install it in the .m2 local repository with .jar extension (not kjar)
{code}
D:\DOCUMENTS AND SETTINGS\MMORTARI\.M2\REPOSITORY\COM\ACME
└───drools6testmvnlatest.therules
│ maven-metadata-local.xml
│
└───0.0.2
drools6testmvnlatest.therules-0.0.2.jar
drools6testmvnlatest.therules-0.0.2.pom
_remote.repositories
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jboss-jira
mailing list