Artifacts using XApi Core Injection API (9)

Sort by:Popular▼

✓Popular✓Newest

All jre-specific runtime implementation for dependency injection goes in here. Note that the xapi-core-inject core library can operate without runtime support; so long as your services are correctly mapped in META-INF, you will not need runtime classpath scanning or bytecode lookup.

A fluent, functional codegen utility

Core interfaces for our collections api.

In order to implement the core XApi dependency injection in gwt, we had to swap out the injection methods themselves with magic methods that call into generated-on-the-fly provider classes.

This module contains static services and default implementations for other core services. In order to keep core dependencies as clean as possible, we avoid accessing helpers like X_Inject so users can choose when / if they inherit larger dependencies.

This module contains a classpath scanner, and bytecode reader. It is useful in any java runtime environment, and allows java code to parse bytecode into a meta structure of classes, annotations, methods and fields. This meta structure is used throughout xapi to allow us to extend java structures in a cross-platform compliant way (exposing services and service objects so you can hack support for whatever runtime you need). It is especially useful for fast runtime injection, and as an ...

All Gwt jre emulation code goes in this module, as well as any gwt-compiler overrides. xapi-gwt-api.jar must come before gwt-dev.jar on your compile classpath. A plugin is being built to automatically adjust maven runtime dependencies, but users of ant or IDEs will need to ensure the super jar comes before gwt-dev. We will petition gwt to accept our mods, but, until then, if you want bleeding edge features, you gotta do bleeding edge configuration. Code that ties directly into other ...

This super module contains the modules for the core user interface api.

This module exists solely to package all other jre modules into a single uber jar. This makes deploying to non-mavenized targets much easier. Of course, you would be wise to inherit your dependencies individually; the uber jar is intended for projects like collide, which have complex configuration, and adding many jars would be a pain. It also allows dependent modules to discover new features, as modules graduate from labs to final, they will be added here. As you type ...