commit | 31d711c977df78d491ef9e7ffa1402046868e1aa | [log] [tgz] |
---|---|---|
author | ronshapiro <ronshapiro@google.com> | Fri Jan 13 08:58:02 2017 -0800 |
committer | Ron Shapiro <shapiro.rd@gmail.com> | Fri Jan 13 16:17:34 2017 -0500 |
tree | 7e89df8f862009ae595c56579c93bdbaa0b0e2fb | |
parent | 645657a691f6908a20718890b07fa8c8f4f68193 [diff] |
Build Dagger with Bazel The Maven infrastructure is not being removed in this CL. We will build and test with both Maven and Bazel until we have a successful release to Maven Central using bazel-built artifacts and automated tools to generate poms/ship to Central. This CL does not address any of the scripts in util/ like publishing snapshots or generating javadoc. It also does not reorganize files into a more traditional bazel project structure. Open questions: - What should we do about shading? - Right now, only auto-common is shaded. If we shade it, should we remove it from the deps of the compiler POM, since other users don't need it to build? - How should we implement shading? One idea is to make a unified jar of the bazel-built compiler and auto-common, and then use jarjar to rename classes. - What should we do with dagger-gwt? I'm not a GWT expert but it seems that we could recreate that jar with a genrule + jarjar ------------- Created by MOE: https://github.com/google/moe MOE_MIGRATED_REVID=144448160
A fast dependency injector for Android and Java.
Dagger 2 is a compile-time evolution approach to dependency injection. Taking the approach started in Dagger 1.x to its ultimate conclusion, Dagger 2.x eliminates all reflection, and improves code clarity by removing the traditional ObjectGraph/Injector in favor of user-specified @Component
interfaces.
This github project represents the Dagger 2 development stream. The earlier project page (Square, Inc's repository) represents the earlier 1.0 development stream. Both versions have benefitted from strong involvement from Square, Google, and other contributors.
Dagger is currently in active development, primarily internally at Google, with regular pushes to the open-source community. Snapshot releases are auto-deployed to sonatype's central maven repository on every clean build with the version HEAD-SNAPSHOT
.
You can find the dagger documentation here which has extended usage instructions and other useful information. Substantial usage information can be found in the API documentation.
You can also learn more from the original proposal, this talk by Greg Kick, and on the dagger-discuss@googlegroups.com mailing list.
You will need to include the dagger-2.x.jar
in your application's runtime. In order to activate code generation and generate implementations to manage your graph you will need to include dagger-compiler-2.x.jar
in your build at compile time.
In a Maven project, include the dagger
artifact in the dependencies section of your pom.xml
and the dagger-compiler
artifact as either an optional
or provided
dependency:
<dependencies> <dependency> <groupId>com.google.dagger</groupId> <artifactId>dagger</artifactId> <version>2.x</version> </dependency> <dependency> <groupId>com.google.dagger</groupId> <artifactId>dagger-compiler</artifactId> <version>2.x</version> <optional>true</optional> </dependency> </dependencies>
If you use the beta dagger-producers
extension (which supplies parallelizable execution graphs), then add this to your maven configuration:
<dependencies> <dependency> <groupId>com.google.dagger</groupId> <artifactId>dagger-producers</artifactId> <version>2.x</version> </dependency> </dependencies>
// Add plugin https://plugins.gradle.org/plugin/net.ltgt.apt plugins { id "net.ltgt.apt" version "0.5" } // Add Dagger dependencies dependencies { compile 'com.google.dagger:dagger:2.x' apt 'com.google.dagger:dagger-compiler:2.x' }
// Add Dagger dependencies dependencies { compile 'com.google.dagger:dagger:2.x' annotationProcessor 'com.google.dagger:dagger-compiler:2.x' }
If you're using a version of the Android gradle plugin below 2.2
, see https://bitbucket.org/hvisser/android-apt.
If you're using the Android Databinding library, you may want to increase the number of errors that javac
will print. When Dagger prints an error, databinding compilation will halt and sometimes print more than 100 errors, which is the default amount for javac
. For more information, see #306.
gradle.projectsEvaluated { tasks.withType(JavaCompile) { options.compilerArgs << "-Xmaxerrs" << "500" // or whatever number you want } }
master
branch on GitHub)If you do not use maven, gradle, ivy, or other build systems that consume maven-style binary artifacts, they can be downloaded directly via the Maven Central Repository.
Developer snapshots are available from Sonatype's snapshot repository, and are built on a clean build of the GitHub project's master branch.
Copyright 2012 The Dagger Authors Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.