Hello, the client I currently work for has strange requirements when it comes to maven version ranges.
Part 1: Snapshots should not be included in Version Ranges, unless they are specifically mentioned in the upper or lower bound e.g. [0.5,1.0) should not match 0.6-SNAPSHOT [0.6-SNAPSHOT,1.0) should match 0.6-SNAPSHOT, but not 0.6.1-SNAPSHOT (This is loosely equivalent to http://jira.codehaus.org/browse/MNG-3092 , and my client has previously used maven 2.09 with the patch attached to this issue) I have managed to implement this functionality in Maven 3 using a) the patch I contributed to this issue: http://jira.codehaus.org/browse/MNG-5017 and b) a custom VersionScheme implementation that extends GenericVersionScheme and decorates the GenericVersionConstraint objects with the above requirements. Now I just have to hope that MNG-5017 gets accepted (or else my client will again have a complicated migration path for future versions) Part2: It gets even more complicated, unfortunately. My client's requirement is as follows: if a project has several paths to a given dependency and at least one path includes a SNAPSHOT version, then this version should be included in all version constraints for this node Example: [this project] | | | +------> artifactA ------> artifactB [0.5,1.0) | +---------> artifactC ------> artifactB [0.4,) in this scenario, version 0.5-SNAPSHOT won't be included [this project] | | | +------> artifactA ------> artifactB [0.5-SNAPSHOT,1.0) | +---------> artifactC ------> artifactB [0.4,) in this scenario, version 0.5-SNAPSHOT will be included, as it is included in at least one version range Obviously, I can't implement this requirement with my above approach alone. From what I see so far, I will have to use a DependencyGraphTransformer somehow. I can think of the following approach: a) Implement a DependencyGraphTransformer that is added in the Transformer chain before NearestVersionConflictResolver. b) This Transformer would check all version constraints for the current node to see if this scenario applies. c) If it does, this Transformer would have to change all constraints in the current node to allow snapshots. Since I already use Custom VersionConstraint decorators, b) and c) will be easy to achieve, however a) is the problem. The way I see is to - implement an AbstractMavenLifecycleParticipant and register it as a component (store the artifact in $MAVEN_HOME/lib/ext) - in AbstractMavenLifecycleParticipant.afterSessionStart(session), get the current DependencyGraphTransformer from session.getRepositorySession() - Create a ChainedDependencyGraphTransformer delegating to a) my custom transformer and b) the previous transformer - inject that ChainedDependencyGraphTransformer back into session.getRepository() (probably using org.sonatype.guice.bean.reflect.BeanProperty.set(bean, value)) Would that approach work? Is there a better way to implement this functionality? Thanks in advance, Sean Floyd -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
