maven增量编译
最近由于不清楚maven(2.2.x)增量编译的机制,导致应用出现了一个当时觉得非常诡异的一个问题。先描述一下问题。
背景是应用A有一个公用的base包,版本为1.6.6-SNAPSHOT,应用B依赖于这个公用的base包。我在base包中修改了一个字符串变量的值,该变量是一个缓存的key(如下面代码的Constants类,中的CACHE_KEY)。然后使用mvn deploy 命令把base包上传到中心库中。出现的问题是应用B打包部署,应用上线后,使用后台功能删除"cache.key.new"对应的缓存值,提示删除成功。但是前台展示的还是老的值(前台展示取的数据是从缓存取出的,简化代码后,参考下面的CategoryManager的showCategory()方法,根据key在缓存中取出值,然后前台展示)。
public Interface Constants{ public interface Cache{ String CACHE_KEY = “cache.key.new”;//旧值为"cache.key" } }
public Class CategoryManager{ private static Map<int, String> keyMaps = new HashMap<String, String>(); static { keyMaps.put(1, Constants. Cache. CACHE_KEY);//把缓存的key存到map中 ......... } public Object showCategory(){ return cacheManager.get(keyMaps.get(1));//在缓存中获取数据 } }
一开始怀疑是包没有成功deploy到中心库中,然后在中心库中把1.6.6-SNAPSHOT的源码包拉了下来,发现里面的代码是新的。
我的印象中deploy是maven生命周期的最后一步,执行deploy命令是会执行compile编译操作的,当时怀疑自己记错了,以为base包deploy的时候没有走到compile,就把包发到中心库中了,后续把base包的1.6.6-SNAPSHOT的编译后的文件拉下来,并且反编译Constants类,发现CACHE_KEY的确是新的值"cache.key.new",证明这块是被重新编译过了。(后续翻阅了下资料”http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html maven生命周期“发现自己记的的确没错)
最后把CategoryManager.class反编译过来一看,发现里面的部分代码是这样的:
public Class CategoryManager{ private static Map<int, String> keyMaps = new HashMap<String, String>(); static { keyMaps.put(1, "cache.key");//问题出在这里,这个"cache.key"没有替换成新的值"cache.key.new" ......... } ........ }
发现问题了,这里的"cache.key"并没有替换成新值。也就是说CategoryManager类并没有重新编译。这里的原因是maven的增量编译机制。
后续找了些资料表明,默认情况下maven是增量编译的,maven在编译的时候会先去比较源文件(.java)文件的修改时间和对应类文件(.class)的修改时间,如果源文件的修改时间比类文件的修改时间要晚的话,重新编译原文件否则不做处理(另外,如果删除了一个java文件,对应的class文件在增量编译时是不会被移除的)。
在这里CategoryManager的源文件并没有发生过改变,所以不会重新编译。并且这个地方恰好是静态代码块,这段代码 keyMaps.put(1, Constants. Cache. CACHE_KEY); 编译时直接被替换成 keyMaps.put(1, "cache.key"); ,如果是在非静态代码块里面使用的话,这块地方是不会出问题的。所以之前一直使用mvn deploy都没有出现过问题。
后续找了些资料表明,默认情况下maven是增量编译的,maven在编译的时候会先去比较源文件(.java)文件的修改时间和对应类文件(.class)的修改时间,如果源文件的修改时间比类文件的修改时间要晚的话,重新编译原文件否则不做处理(另外,如果删除了一个java文件,对应的class文件在增量编译时是不会被移除的)。
在这里CategoryManager的源文件并没有发生过改变,所以不会重新编译。并且这个地方恰好是静态代码块,这段代码 keyMaps.put(1, Constants. Cache. CACHE_KEY); 编译时直接被替换成 keyMaps.put(1, "cache.key"); ,如果是在非静态代码块里面使用的话,这块地方是不会出问题的。所以之前一直使用mvn deploy都没有出现过问题。
那要怎么避免这个问题呢,使用mvn clean deploy。clean会做一些清理的工作,包括移除上一次构建的文件。这样就能很好的解决这个问题了。
参考:
http://blog.jetbrains.com/teamcity/2012/03/incremental-building-with-maven-and-teamcity/ 部分有关于maven的 incremental building