Nevermind. I was able to figure out how the internals worked with the caching of the projects in shorthand form. I was then able to use reflection to gain access to the ReactorRead's private variables and remap each of the versions in the in-memory cache which is what the reactor uses to know not to go out to the local/remote repositories to fetch the artifact. I also discovered that the projects were also told to point to the original pom.xml files as well for the transitive dependency resolution and so I was able to rewrite the pom.xml as a temporary file and associate that file with the projects instead allowing everything to work in complex multi-reactor situations as well.
I appreciate anyone giving it time to look into it and would love to know if there is a "cleaner" way to do this and/or enhance maven in the future to allow version number alterations to take place. The code that I did all of this with is listed at the github location above and is also published to the official maven repo as well for public consumption (version 1.2 being the one that has this fixed in for proper reactor support). Thanks, On Sat, Dec 21, 2013 at 6:00 PM, Sejal Patel <sepa...@gmail.com> wrote: > Hey guys, I was hoping that someone might be able to help me out with an > issue I'm having on a plugin I've written. > > The high level of what the plugin does is automatically change the version > number of a project to match whatever the name of the git branch name is > that it is on without any physical change to the pom.xml or anything (i'll > skip the reason for this as it is not relevant to the question). > > What I've written so far works great as long as I "install" or "deploy" > the artifacts as well. However, it does not seem to work so well from > within a "reactor" setup. > > So here is the reactor scenario > > Parent > \__ ChildA > \__ ChildB (depends on ChildA) > > Well the plugin will properly change the version number of Parent, ChildA, > and ChildB and it will properly update the version number of ChildA (that > is the dependency list of ChildB) to the branch-SNAPSHOT name. However, > well it goes to "resolve" that dependency it does not appear to find it > within the reactor artifacts that are created and thus tries to find it > from the local or remote repositories instead. > > Because the install/deploy actually physically modify the pom that is to > be "deployed" out, everything works great once you have actually > installed/deployed it once. For some reason once it locates the pom file it > decides to use the version of the artifact that was built from within the > reactor (or so it appears but I haven't tested this part too deeply). What > I'm not able to do is get that "initial" build to work correctly though and > I do not wish to be forced into doing a "install" or "deploy" to make this > work. > > So the issue appears to be that the DefaultArtifactResolver is unable to > resolve it and so what I'd like to know is if there is any way for me to > manually put something into the cache or repository or something from an > in-memory state that is only for the life of that reactor so that it will > resolve correctly to the artifact that was just built from within the > reactor and not from a local/remote repository? > > The code if anyone is interested is up on github at > https://github.com/sepatel/maven-scm-version-plugin if it helps people to > understand what I'm talking about. > > Thanks for any help or ideas that can be offered, > > -- > *Justice is nothing more than that which is in the greatest self-interest > of the largest portion of the population.* > -- *Justice is nothing more than that which is in the greatest self-interest of the largest portion of the population.*
