Download JAR files tagged by driver with all dependencies

A timer using the crontab syntax and additional binary input to provide a resolution of one second (1000 ms / 1000 millis / 1s). The timer uses the whiteboard pattern to notify the clients. There are only a few dependencies to commons-codec, osgi and osgi-blueprint. The bundle 'org.i3xx.step/org.i3xx.step.clockmongo' provides a store for the clock configuration based on mongodb. The additional dependency is 'org.mongodb/mongo-java-driver'. The bundle 'org.i3xx.util/org.i3xx.util.whiteboard' can be used to avoid a dependency to bundles used. In other words, your bundle can use the clock but need no dependency to the bundle 'org.i3xx.step.clock'. Take a look at the description there.

This module creates two things: (1) a text file that contains a list of GAV coordinates needed for the 2nd stage boot loader (2) jar files mentioned above, in the Maven repository directory layout. Using Maven repository directory layout, as opposed to more simpler "flat directory with full of jars", allow us to share the jar files between fallback bees-driver dependencies and boot2, which saves disk space a lot. We do this in a separate module outside boot2, so that the list includes the bees-boot2 jar itself.

relay-jdbc allows a JDBC connection to be relayed through an intermediate relay server: it is both a JDBC driver (client) and a JDBC relay server. It is a fork of https://github.com/AugeoSoftware/VJDBC project, where Aleksei Yu. Semenov has implemented a number of brilliant improvements of the orignal VJDBC project hosted on http://vjdbc.sourceforge.net Original Developers were: Hunter Payne ([email protected]) and Michael Link ([email protected]). For all pre-existing code, credits go to the original respective author. This product brings the original VJDBC concept further and (apart from code quality improvements and bug fixes) implements complete separation of the underlying transport mechanism, introducing support for connecting directly through a SSH pipe, where the relay server interacts with the client through standard I/O pipes. The re-designed transport architecture supports easy development of new transport implementations, allowing this JDBC relay to be quickly adapted to a variety of exotic environments.

JCQL is a tool allowing to generate boilerplate java code from existing cassandra schema. It is intended to be used with Cassandra 2.1+ due to support of UDTs (User Defined Types)/Tuples/Collections. Cassandra's UDTs/Tuples/Collections and an ability to introspect schema through java driver make it possible to automatically generate POJOs and corresponding mappers between database and java models. Properly generated java code saves development efforts and is less error-prone compared to hand coding. Accompanied with proper CI and deployment it can also guarantee consistency between database and java models at any point of application lifecycle from development to production rollout. JCQL does not rely on java reflection or annotations which means all discrepancies between actual cassandra schema and what client code expects it to be will be identified during compilation not at runtime in the middle of the night right after production release. No need to worry about Cassandra client code performance implications due to use of reflection.

Java Prolog Interface (JPI) is an Application Provider Interface (API) for interaction between Java and Prolog programming languages. Is a bidirectional interface that communicate Java applications with Prolog program or database and Prolog procedures with Java class and methods. JPI is an abstraction layer over concrete prolog drivers over Prolog Engines. This API define all mechanism to interact with any Prolog Engine and maintain the application independent to a specific underlying engine. JPI have several connectors to open source prolog engines like SWI, YAP, XSB native engines and tuProlog, jTrolog, jLog Java based prolog engines. JPI study all related Java-Prolog integration libraries and take the betters features from each solution with the propose to achieve a common integration interface. The last feature allows switch the under laying Prolog Engine driver and the application code still be the same. JPI run over any Java Virtual Machine that support Java SE 5 or above. The project was tested over HotSpot, Open J9 and JRockit Virtual Machines over Operating Systems like Windows (7,8,10), Linux (Debian, Ubuntu) and Mac OS X. Can be deployed on Servlets Containers like Jetty, Tomcat or Glassfish Application Server. JPI can be include in any Java Project using the commonest Java Integration Development Enviroment (IDE) like Eclipse, Netbeans, IntelijIDEA and so on. JPI is developed and maintained by Prolobjectlink Project an open source initiative for build logic based applications using Prolog like fundamental Logic Programming Language in the persistence layer and application programming.