What good is checkModificationExcludeList for release:prepare?
I'm using the release plugin for tagging and branching on CVS projects. Certain user-specific property files should not be taggeg nor branched, so I defined checkModificationExcludeList for the release plugin. This passes the first modification check well, but when it comes to tagging by scm plugin, maven produces an error Provider message: The cvs tag command failed. Command output: cvs tag: developer.properties is locally modified cvs [tag aborted]: correct the above errors first! at org.apache.maven.lifecycle.internal.MojoExecutor.execute( MojoExecutor.java:213) So am I doing anything wrong or ist the ignore-option useless in combination with tagging/branching? Can anyone explain the sense of this option? Kind regards Frank
No reattempt to resolve broken released artifacts
Hello, we shortly switched our company's infrastructure to maven and are now experiencing a strange behaviour of dependency resolution. Say my.project:1.0.0 requires my.cool.component:jar:3.7.0 and I try to build my.project:1.0.0 before the dependency was deployed to my central repository, my local repository ends up having the folder structure of my/cool/component/3.7.0 with two files in it, namely my.cool.component.jar.lastUpdated and my.cool.component.pom.lastUpdated. The build fails, which is perfectly correct. Afterwards, my.cool.component:jar:3.7.0 is deployed to central repo, but my local repo never gets the jar, so I always have to clean my local repo manually, before I can get the build of my.project:1.0.0 working. Is this by design or simply a bug? Regards Frank
Dependency resolution problem
Hello, we are currently migrating from Ant to Maven and are encountering some dependency resolution issues. According to the documentation Maven resolves by nearest-to-root-algorithm, so given a project structure like P - A (1.1.0) - B (1.5.0) P - B (1.3.0) meaning P depends on A in version 1.1 etc. would resolve A (1.1) and B (1.3). Our semantics for compatibility assumes different major numbers as generally incompatible, which should result in a build failure. All different minor numbers are treatet as generally backwards compatible. A project setup like P - A (1.1.0) - B (2.1.0) P - B (1.3.0) should cause a build failure, a setup like P - A (1.1.0) - B (1.5.0) P - B (1.3.0) should not, but we have to guarantee, that B (1.5.0) is resolved, not B (1.3.0), which is not the standard maven dependency resolution. Has anyone an idea how to solve this? Regards Frank Jakop
