Hi, after a good day of debugging, here is the problem and the resolution: I had a directory structure of: groupId/artifactId/maven-metadata.xml groupId/artifactId/1.0.0-SNAPSHOT/artifactId-1.0.0-SNAPSHOT.jar groupId/artifactId/1.0.0-SNAPSHOT/artifactId-1.0.0-SNAPSHOT.pom groupId/artifactId/1.0.0-SNAPSHOT/maven-metadata.xml groupId/artifactId/1.0.1-SNAPSHOT/artifactId-1.0.1-<uniqueversion>.jar groupId/artifactId/1.0.2-SNAPSHOT/artifactId-1.0.2-<uniqueversion>.jar
The maven-metadata.xml file only seemed to have references to the 1.0.0-SNAPSHOT version (nonunique), so any attempt to resolve 1.0.2-SNAPSHOT (unique) resulted in a failure. First I thought that this was a problem on the artifactory side, i.e. Artifactory wasn't generating maven-metadata.xml for some reason for the freshly uploaded artifacts, so I went and downloaded artifactory source and started to debug. (Feedback on building Artifactory: to run a successful mvn clean install, one has to install 6(!!) artifacts manually into the local repository: opensymphony (a dead project btw), iostreams, atinject, sqljdbc4, postgresql-9.2-1002 (which is btw got downloaded by guessing URLs, since the downloads page now has 1004), ojdbc6. While I can understand that these projects can have clickthrough licenses and stuff, a README file or something would have been still really nice...) The end result of the debug session was that Artifactory did not generate a maven-metadata.xml, because the uploaded artifact did not have POM artifact and for some reason this is enough to not to generate maven-metadata.xml... Next stop was debugging the Jenkins artifactory plugin along with the build info recorder. (Feedback on build-info-recorder: The project hierarchy and the fact that each extractor has its own version number caused me quite a headache: figuring out that the 2.1.8 was using 2.1.2 version of build-info-recorder, BUT 2.1.0 version of the maven3 extractor was the first sign... Then there was no build-info-extractor-maven3-2.1.0. branch, so after looking at git history, it turned out that the "2.1.0" branch had the code I wanted to debug...) Anyways, the plugin debug showed that the project artifact for my module was pointing to target/classes (instead of being null as a different, but working module did). Debugging Maven Core 3.0.5 showed that the compile mojo execution sets the artifact file to target/classes. Since the module did not have Java source whatsoever (it's a JS project), I've simply removed the compile plugin from the pom.xml for the project, and then builds started to upload artifactId-1.0.2-<uniquversion>.pom resulting in artifactory generating maven-metadata.xml files too, meaning that suddenly the build started to work too. Thanks for reading :) cheers, Peter -- View this message in context: http://forums.jfrog.org/Maven-metadata-xml-not-updated-after-uploading-new-artifact-tp7579480p7579486.html Sent from the Artifactory - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
