knowledge-api maven version don't have new version?
What is the impact will be if other drools libraries upgraded to 7?
As new versions of Drools are released, some Jars are end-of-life'd as their functionality is either subsumed into other jars or no longer supported.
The knowledge-api jar was a part of Drools 6.x, but is not part of Drools 7. This is logical since it was intended to be an adapter from the Drools 5 drools-api jar to the KIE APIs. Since the adapter's purpose was to facilitate backwards compatibility for the previous release, it makes sense it wasn't included in Drools 7 at all, since everything relying on the Drools 5 functionality should have been long since upgraded.
At least for this particular library ...
Version
Jar
Drools 5
drools-api
Drools 6
knowledge-api
Drools 7
kie-api
... though note that these jars are likely not drop-in replacements depending on what you're using from the library itself. The package names and class names usually change between major releases.
knowledge-api was replaced by kie-api
Related
We have been using OptaPlanner for a potential On-Prem/Cloud solution. We are currently using drools-rules that are compiled at runtime (i think the default behaviour?).
OptaPlanner is pulling in the "Eclipse ECJ" dependency via the Drools compiler.
optaplanner-core -> drools-compiler -> ecj
ECJ uses the EPL 1.0 licence which we have been instructed should not be distributed.
My question(s):
Does OptaPlanner support pre-compiled drools rules?
Are there any alternatives if we were to exclude 'ecj'?
ConstraintStreams are probably a way to avoid ECJ, as the Drools implementation won't compile DRL. And the faster Bavet implementation won't use Drools at all. However, ConstraintStreams are still young... (but very actively being worked on).
So far we have been using the Findbugs JSR-305 annotations (com.google.code.findbugs:jsr305) and everything including tool support (Sonar, Eclipse, Findbugs, …) has been working fine.
However it is our understanding that Jigsaw in Java 9 is going to break JSR-305 annotations (one package in two modules is not allowed). This was confirmed at JavaOne 2015. Oracle's reasoning is JSR-305 never happened and JSR-250 would have to endorse these annotations.
We're looking for replacements for JSR-305 annotations that work in both Java 8 and Java 9. If history is any guide the time between Java 9 GA and Java 8 EOL will be rather short and we would like to fix any incompatibilities in our code in advance. In theory we could upgrade the annotations module of the JDK but doing this across our toolchain seems like a lot of work.
It’s true that two modules cannot, ordinarily, define types in the same
package. Until recently, putting jsr305.jar on the class path of a
JDK 9 build would have no effect: That JAR file defines types in the
javax.annotation package but that package is defined in the platform’s built-in
java.xml.ws.annotation module, and the latter takes precedence.
Owing in part to the widespread use of jsr305.jar, however, and also to make
it easier for existing application servers to migrate to JDK 9, we changed
the default set of root modules to exclude the annotations module, among
others. Putting jsr305.jar on the JDK 9 class path works out-of-the-box
with both JDK 9 and JDK 10; details are available in
JEP 261. It will continue
to work out-of-the-box with later releases since the annotations module, along
with all the other Java EE and CORBA modules, were removed in JDK 11
per JEP 320.
I have two questions:
1. Which Jetty version is used by GWT 2.5.1 in dev-mode?
2. Is there a way to change this version?
6.1.11 (source: https://gwt.googlesource.com/gwt/+/2.5.1/dev/build.xml)
Note that 2.6 and 2.7 use Jetty 8.1.12.v20130726, and 2.8 uses Jetty 9.2.14.v20151106
Yes, you can implement a ServletContainerLauncher that starts another version of Jetty. Beware of classpath conflicts though! (but I suppose you'll want to use a recent version and the new versions use org.eclipse.jetty rather than org.mortbay.jetty as a root package so there shouldn't be any problem (with the old GWT pre-2.6).
FYI, gwt-dev will be split into several JARs in the next version of GWT (or maybe the one after that) and the dependency on Jetty will be moved to an optional JAR, and will possibly be updated as well. (note though that GWTTestCase also depends on Jetty)
EDIT: this finally happens with GWT 2.8, but Jetty is needed for SDM (CodeServer) and Jetty has a bad track of backwards compatibility.
I am using GWT 2.4 with Hibernate 3.0. I wanted to know what changes I need to make in my application for integrating GWT 2.5 in my application ?
Nothing special.
Replace 2.4.0 dependencies with 2.5.0-rc1 ones (depending on how you manage dependencies, either download the SDK and drop the new JARs to replace the previous ones, or bump the version number in your POM –if using Maven– or similar build file).
If you're using Maven and the gwt-maven-plugin, make sure you re-define the plugin dependencies too (note gwt-maven-plugin 2.4.0 also needs gwt-servlet to be overridden); or you can test the gwt-maven-plugin 2.5.0-rc1.
Check the list of breaking changes though; chances are small that they affect you, but there's still a risk.
Do anyone know when Eclipse plans to move its codebase to > 1.5 (i.e. using generic & annotation)?
Even the latest plan for the upcoming eclipse 3.6 Helios still mentions:
Most of the Eclipse SDK is "pure" Java code and has no direct dependence on the underlying operating system. The chief dependence is therefore on the Java Platform itself.
Portions are targeted to specific classes of operating environments, requiring their source code to only reference facilities available in particular class libraries (e.g. J2ME Foundation 1.1, J2SE 1.4, Java 5, etc).
In general, the 3.6 release of the Eclipse Project is developed on a mix of Java 1.4, Java 5 and Java 6 VMs.
As such, the Eclipse SDK as a whole is targeted at all modern, desktop Java VMs.
Most functionality is available for 1.4 level development everywhere, and extended development capabilities are made available on the VMs that support them.
So as long as they want to support platforms with an old JDK, the incentive to rewrite a large portion of the codebase in recent JDK is low.
Note: e4 (Eclipse 4.0) will be based on Java 5.
In general, the 1.0 release of the e4 Project is developed on Java SE 5.
Some of Eclipse codebase (the Java EE part) is already using 1.5 level. As for the rest of it, I don't think they have any plans - I doubt if it is worth the effort.
More here -> http://www.eclipse.org/downloads/moreinfo/jre.php