The suggestion (automatically upload to local repo) sounds like a good one, though I thought of a different solution that I'd like your opinion on:
This project is used for running integration-level regression tests. The project is checked into source control (SVN). Conceivably, I may have a need to run the project tomorrow against an older version of code. If I were to do this, I'd want to run with the same version of the internal jars that I had used at that date. If I were to tell SVN to load the project as of date/label x (might be a release from 6 months ago..) -- and then run the project, I wouldn't want to take the latest version of those internal jars, I'd want to use the version that I used back at that date. To that end, I was thinking of creating a subdirectory within the project inside SVN reserved for holding those internal jars. This way, whenever I revert the project back to SVN version <x>, I'll be assured I'm using those same version of those same internal jars that I had originally used on that date/label. To ensure I'm using the latest version (when I'm trying to run 'latest'), I could write a script to auto-commit those jars to the subdirectory of my project within SVN, overwriting the previous version. In reality it seems very similar to the suggestion you had, but it's utilizing SVN to house those artifacts instead of the local nexus repo. What are your thoughts on this? If I were to do this, what would the proper configuration be for Maven, i.e. to treat this special subdirectory as a location for retrieving artifacts, and to ensure that it's not cached, so that when I build, it will always use the version in that directory? Thanks for your help. I'm fairly new at this and appreciate the guidance. -- View this message in context: http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5722573.html Sent from the Maven - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
