我不能当快照依赖更新常春藤更新缓存。 解析器（以具有以下设置：
<url name="xxx" m2compatible="false"
checkmodified="true" changingMatcher="regexp"
changingPattern=".*-SNAPSHOT.*">
一个例子伪像的文件名（在Artifactory的）为：
my-jar-1.999-SNAPSHOT.jar
决心的详细蚂蚁日志包括：
[NOT REQUIRED] com.myorg#my-module;1.999-SNAPSHOT!my-jar.jar
有关于神器没有POM。
分解器是链分解器下方; 它们都具有所有相关属性进行设置。 我已阅读https://issues.apache.org/jira/browse/IVY-938和https://issues.apache.org/jira/browse/IVY-1221 ，包括所有的意见，并AFAICT（可能是错误！ ）没有解决方法是相关的。
我应该放弃快照，只是使用明确的版本与“integration.latest”动态版本的依赖？ 我担心这可能最终以失败告终，当我们有集成构建发生多个主要版本。 在这一点上我们需要进行拆分主要版本到单独的存储库，或者放在工件名称的主要版本号，或者同样笨重，只是为了让“integration.latest”工作。
I'm not a fan of using the url resolver when talking to Maven repository managers.
The problem is Maven has special and rather unique handling for snapshot revisions..... The url resolver is better suited for use against ivy respositories.
I use Nexus, but the following should also apply to Artifactory. The following settings file sets up Maven Central and my two hosted repositories (Maven repositories come in two flavours, release or snapshot):
<ivysettings>
<settings defaultResolver="repos" />
<resolvers>
<chain name="repos">
<ibiblio name="central" m2compatible="true"/>
<ibiblio name="my-releases" m2compatible="true" root="https://myhost/releases"/>
<ibiblio name="my-snapshots" m2compatible="true" root="https://myhost/snapshots"/>
</chain>
</resolvers>
</ivysettings>
You'll notice I'm using the ibilio resolver which has internal logic to decipher Maven's special Snapshot handling.
When I require a snapshot revision I think declare it explicitly as follows:
<ivy-module version="2.0">
<info organisation="myOrg" module="Demo"/>
<dependencies>
<dependency org="myOrg" name="myModule" rev="2.7-SNAPSHOT"/>
..
</dependencies>
</ivy-module>
Under the hood the ibilio resolver is reading the Maven repository meta data files to determine which timestamped artifact should be fetched from the snapshot repository.
Update
I would suggest reading the following presentation:
- Continuous delivery with Maven
It outlines pretty well the Maven philosophy separating releases from dev builds (or snapshots). It also explains one of the very clunky aspects of Maven... Two different ways to publish artifacts...
I suspect what you're trying to do is along the lines of the author which is setup a CD pipe-line. In that case every build is a potential release and should be treated as such (No dynamic dependencies which are allowed by snapshots).
I would suggest limiting snapshots to developer only builds. Only deploy release candidates. The problems with this approach will be in managing lots and lots of releases. Some of the repository managers (Nexus, Artifactory, Archiva) offer "staging" features which make it possible to certify or discard releases that don't pass your quality toll-gates.
Update 2
If you are using ivy to publish snapshots into a Maven repository then there are a couple of issues:
- Ivy doesn't support the publication of snapshots with timestamps
- Ivy doesn't update the Maven module's metadata.xml file
In my opinion time-stamped files is one of the killer features of using snapshots in the first place. With ivy it's only possible to provide the latest file (overwriting the previous latest file).
There are work-arounds to address these issues:
- As suggested in the second link you can ignore metadata completely (setting the "useMavenMetadata" attribute to false) and default back to ivy's older mechanism of comparing file names. This only fixes the problem for ivy clients.
- The repository manager should be able to regenerate the metadata files (Nexus at least has a task to do this).
- Use the Maven ANT task.
The last suggestion is not as crazy as it seems. Firstly it's the only way I know to support timestamped snapshots and secondly the Maven client appears to do a lot of extra processing (updating the module metadata) that is largely undocumented.
经过斗争的日子......
问题是，对于
checkmodified="true" changingMatcher="regexp"
到上工作一个<解析器>，它必须是在层级线每旋转变压器 -所有父<链>解析器和所述<URL>，<本地>或<ibiblio上>分解器在底部。
