什么是apt依赖范围在android gradle文件我有时看到?
一个例子是这样的?
apply plugin: 'com.android.application'
apply plugin: 'com.neenbedankt.android-apt'
android {
compileSdkVersion 20
buildToolsVersion '20.0.0'
defaultConfig {
applicationId "org.ligboy.test.card.module1"
minSdkVersion 14
targetSdkVersion 20
versionCode 1
versionName "1.0"
}
buildTypes {
release {
runProguard false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
final DAGGER_VERSION = '2.0.2'
dependencies {
compile "com.google.dagger:dagger:${DAGGER_VERSION}"
apt "com.google.dagger:dagger-compiler:${DAGGER_VERSION}"//what is this scope
provided 'org.glassfish:javax.annotation:10.0-b28'
}
在顶层构建中。gradle文件它具有以下全局相关性:
buildscript {
dependencies {
classpath 'com.android.tools.build:gradle:1.3.0'
classpath 'com.neenbedankt.gradle.plugins:android-apt:1.4'
}
}
注意在依赖项部分有一个apt作用域?我只知道编译,包和提供的范围。编译包括编译时和包中的依赖项,前提是说只在编译时包括库,并在包时丢弃它,这样它就不包括在最终构建中。包是相反的,它将依赖项包含在包中,而不是在编译时。但是什么是apt依赖范围,我们显然需要com.neenbedankt.android-apt它的工作,所以我知道它基于Android。
更新:为什么我不能使用提供的依赖范围而不是apt范围?它们有何不同?
我为那些需要更多信息的人创建了一个关于匕首依赖范围的教程。
只是想在Studio 2.2中添加如何更改此设置
dependencies {
compile 'com.google.dagger:dagger:2.4'
annotationProcessor "com.google.dagger:dagger-compiler:2.4"
}
将此添加到应用程序渐变模块中。不需要改变任何其他东西。
快乐编码:)
从android-apt
项目页面:
android apt插件与android Studio结合使用,有助于使用注释处理器。它有两个目的:
>
设置源代码路径,以便Android Studio能够正确地提取从注释处理器生成的代码。
您正在使用Dagger,它使用注释处理来生成代码。注释处理代码不应该包含在最终的APK中,您希望生成的代码对Android Studio可见。
这听起来非常类似于提供的
范围,但是apt
在一些关键方面与提供的
不同。第一个区别是,apt
依赖项生成的代码可用于IDE,而由提供的
依赖项生成的代码则不可用。
另一个重要区别是,使用提供的
范围的库中的代码位于IDE类路径上(即,您可以导入类并尝试使用它们),而
apt
依赖项中的代码则不在IDE类路径上。使用提供的,如果您实际上没有为引用的依赖项提供
编译
作用域对应项,则代码将在运行时崩溃。
您可以在此
android apt
问题上找到关于apt
与的讨论。
在Dagger的情况下,应该没有理由在任何代码中包含注释处理器和代码生成器(这是
提供的
范围所允许的)。因此,apt范围更合适。
2016年10月更新:您可能不再需要
apt
和android apt
插件。Android Gradle插件的2.2版有一个annotationProcessor
配置,您应该改用它。
查看更多关于android-apt的下一步是什么?
我想知道为什么我的简单spring boot项目不再有效。它基本上直接来自spring示例,其中一个控制器说hello world。我使用的是spring boot starter jetty和spring boot v1.1.10(也尝试了1.2.0)。我有一些使用嵌入式solr的单元测试,所以solr核心被标记为<代码> 我认为测试范围的依赖关系不应该干扰编译范围的依赖关系,并且“仅适用于测试
问题内容: 我在ivaven.xml中添加了一个依赖项(让我们将其命名为A),它在maven Central中具有一个pom文件。Ivy使用ibiblio解决了Maven依赖关系。添加到ivy.xml的依赖项(A)具有传递的依赖项(B)。到目前为止,到目前为止很好。常春藤无法解决传递性依赖项(B)的依赖项(C)。 我在ivy.xml中定义了A,如下所示: 在B的pom文件中,在编译和测试范围中都定
目前我的项目使用Spring启动测试如下: 但是,尽管有测试范围,它还是引入了sping-core(这是此版本中易受攻击的tpl)作为编译范围传递依赖项,并且它出现在我编译的二进制文件中。 我知道我可以通过使用测试范围显式拉动Spring核心来解决这个问题: 然而,这不应该是必要的。为什么只有在将依赖项拉入编译范围的测试中才有依赖项?
41.1 测试范围内的依赖 如果使用了spring-boot-starter-test“启动器”(scope为test),将得到以下库: JUnit —— Java程序单元测试事实上的标准 Spring Test & Spring Boot Test —— 工具类以及支持Spring Boot程序的集成测试 AssertJ —— 一个优美的断言库 http://hamcrest.org/JavaH
我给ivy添加了一个依赖项(我们称之为a)。在maven central中具有pom文件的xml。Ivy使用ibiblio来解析maven依赖项。添加到常春藤中的依赖项(A)。xml具有可传递依赖项(B)。到目前为止,一切都很好。传递依赖(B)的依赖(C)不能用常春藤来解决。 我在常春藤上定义了一个新的名字。如下所示的xml: 在B的pom文件中,C在编译和测试范围中定义如下: 当我在ivy的缓存
本文向大家介绍什么是REST/RESTful ?它的用途是什么?相关面试题,主要包含被问及什么是REST/RESTful ?它的用途是什么?时的应答技巧和注意事项,需要的朋友参考一下 Representational State Transfer(REST)/ RESTful (表述性状态转移)是一种帮助计算机系统通过 Internet 进行通信的架构风格。这使得微服务更容易理解和实现。 微服务可