Group: net.wetheinter - All Dependencies

XApi - Web Component Implementation · A web component API for manually building web components via WebComponentBuilder, or generating them from interfaces via WebComponentFactory

XApi - Polymer Wrappers · A collection of simple web components that wrap polymer elements; support is rather limited and optimized for the GWT.create 2015 presentation.

XApi - Maven plugins · Mojos for using xapi-dev utilies in maven builds.

XApi - Jre uber jar · 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 X_, autocomplete will expose newly added services.

XApi - Gwt Compiler Implementation · This module contains the business logic of running gwt compiles. It implements and exposes all functionality of the gwt compiler, and should only ever be included in dev-mode runtimes that need to perform gwt compiles. In the maven plugin, the jre frontend and this backend are used together in one runtime. In the collide plugin, the gwt frontend runs in the browser, and this backend runs in vert.x server.

XApi - Dev Mode Gwt Compiler · This module is a parent for the gwt compiler api, and a number of gui implementations. The core module is an event-based wrapper around gwt compile events, as well as a set of UI controller interfaces which must be implemented. Frontends for gwt and jre are provided, which will replace the compilers used in maven and collide.

XApi - Jre SuperPom · This is the main aggregator for all jre submodules. It will contain all of the default implementations for all java runtimes, and leave extension points for any cross-platform differences between restricted platforms, like android, appengine or servlet environments.

XApi - GWT ui superpom · This super module contains the gwt user interface layer for xapi.

XApi - Gwt SuperPom · This is the main aggregator for all gwt submodules. All gwt-specific code resides here. Submodules should avoid inheriting from each other unless necessary. This goes for maven structure and gwt.xml structure. The super module is where our jre emulation layer and super-source live; all modules should inherit super, and a minimum of other modules. Some modules, like injection, are fulfilling an api in the core module, and should be accessed only through core service interfaces. Other modules, like reflection, are capable of being standalone inherits, but can benefit from core utilities like injection, so, two (or more) .gwt.xml modules may be provided. As XApi nears 1.0, all submodules will be routinely stitched together into an uber-jar, in order to have a single jar with a single gwt module that can provide all of the services at once. Internal projects will never use the uber jar, to help maintain modularity, but external projects that want to use more than one service will certainly prefer inheriting one artifact, instead of twelve. When distributed in uber-jar format, it will likely be necessary for either the uber jar, or just xapi-gwt-api.jar to appear before gwt-dev on your compile-time classpath. If using gwt-maven-plugin, the gwtFirstOnClasspath option may become problematic. If so, we will provide a forked gwt-plugin to make sure our compiler enhancements are included in the build process. There is also work going on to make a super-source-everything plugin, which will use maven to find source files, and generate synthetic .gwt.xml for you, as part of an effort to create a wholly unified programming environment. In addition to java-to-javascript, we intend to compile java-to-java and possibly other languages, like go; imagine implementing gwt deferred binding to eliminate cross-platform differences between server environments, or operating systems, or versions of a platform, or anywhere else a core api needs to bind to multiple implementations, depending on the runtime environment.

XApi - Dev mode super-pom · Our aggregator for dev-mode tools

XApi - Dev uber jar · Everything needed to run a comprehensive dev environment. Just type X_ and pick a service from autocomplete; new dev modules will be added as they are built. The only dev service not included in the uber jar is xapi-dev-maven, as it includes all runtime dependencies of maven, adding ~4 seconds to build time, and 6 megabytes to the final output jar size (without xapi-dev-maven, it's ~1MB).

XApi - Core ui superpom · This super module contains the modules for the core user interface api.

XApi - Core SuperPom · This is the main aggregator for all implementation code shared between modules. Each module contains one or more service interfaces, exposed statically using "X_" prefixed classes. Core modules will define their API interfaces, their static accessor, and often a "plain-jre" default implementation which can be replaced by injection override. There must be zero external dependencies in any core modules. A low-performance, low-feature default is preferred over thick, dependency-ridden shared inherits.

XApi (Extremely Extensible Cross-Platform API) · XApi is a dependency injection, service-oriented, polyglot java framework. It is comprised of standalone modules for use in web, desktop and mobile java applications. This codebase enables complete reuse of all code across your java stack, as well as the ability to easily define your own Platform, so you can build your own customized runtime environment to extend or replace existing platforms. It is currently geared towards servlets and gwt clients, but the target we are currently developing include: java, gwt [webkit, firefox, ie], javafx, playn [android, ios, flash], appengine & vert.x For Google Web Toolkit, we also include reflection support, more complete emulation of java.lang.Class, zero-overhead dependency injection, a range of code generation utilities, and even "magic-method injection" (for production compiles any method in the app can be swapped out with others based on configuration properties, or any AST mangling / code generating methods you wish to write). There is also a bytecode transformer in the works which will replace calls into the DI utility with direct references to static final factories, to allow the java compiler to completely erase all injection overhead in all java runtimes.

Maven GWT Plugin · Maven plugin for the Google Web Toolkit.

XApi - Code Generator Templates · A simple templating system for java codegen. This library includes an object-oriented, fluent source writing api, for a chained, intuitive codegen api. It also includes a template processor which can take java source files formatted with "magic comments", to allow simple mapping of GeneratorClass#generatorMethod() to inject dynamic source content. //@generateWith(GeneratorClass)// -Sets the current generator. You may use as many as you please //generatorMethod(arbitrary-string-data-you-may-want-to-parse)// -invokes the named method on the current injector, with any text (between brackets) sent as a string This allows you to markup default source with hooks where you may want to inject arbitrary code. It is especially useful for generating super-source in gwt compiles; changes to the default class are propagated to overrides.