Now that I think about this...I think the metadata file that was confusing IntelliJ might have been a different one, i.e. w/o Nexus in the name. I can't be sure since I have since deleted my local repo to try to solve this problem. I know there was a metadata file in that folder that just had the build/timestamp info which pointed to artifacts that do not exist and when I deleted it...IntelliJ changed to referencing the plain snapshot file (e.g. no timestamp in file name) which is what I want.
-Dave On Fri, Aug 24, 2012 at 4:01 PM, David Hoffer <[email protected]> wrote: > There are several metadata files...the one I was referring to is > maven-metadata-nexus.xml. Yeah I don't know for sure who generated > this Maven/Nexus...I just assumed Nexus because of the file name. > > Yes in our builds we will sometimes run lesser important builds once a > day, or at night, javadocs is a good example. Javadoc generation adds > considerably to the build time and doesn't have high value to be > generated with each build because they don't change that often...and > to be honest devs don't put much in javadocs anyway. > > This worked fine with Maven2...since Maven2 just generated simple > snapshot jars it just overwrote the last one (which is what we want). > Now with Maven3/Nexus this is broke. > > -Dave > > On Fri, Aug 24, 2012 at 3:49 PM, Brian Fox <[email protected]> wrote: >> On Fri, Aug 24, 2012 at 5:43 PM, David Hoffer <[email protected]> wrote: >>> I can't say the whole problem is with Nexus. I can say that the >>> requirement in Maven3 to always use timestamped snapshots has not be >>> addressed in a complete way with tools like Nexus and my beloved IDE >>> IntelliJ. We have hundreds if not thousands of builds happening every >>> day and they should be able to generate artifacts with various >>> classifiers, i.e. sources.jar and javadoc.jar, etc. But they don't >>> all have to generate all of these classifiers with each build. I >>> might want to generate javadocs just at night because the build takes >>> too long, etc. Well this completely breaks Nexus and IntelliJ because >>> Nexus will spit out a metadata file that says that the last >>> timestamped build is, lets say 45, well that might be true for one of >>> the artifacts, lets say it was javadocs, but 45 does not yet have >>> sources or the main jar artifact (the latest for those is 44). >>> However since Nexus advertised that build 45 is the latest, all the >>> tools, i.e. IntelliJ go looking for artifacts for that build number >>> and they do not exist. So the only workaround for that is that all >>> builds must include all classifiers...can't do just the one we >>> need/want. >> >> This is an interesting use case, so you run different builds that >> produce different classified artifacts but not at the same time? >> Maven3 allows this, it used to be Maven that would break. Will double >> check this in Nexus. >> >>> >>> I don't know if the same problem exists with Artifactory...all I can >>> say is that I have not seen these types of errors using that repo >>> manager. >>> >>> Then there is the local repo size problem with timestamped >>> snapshots...my hard drive is just not big enough for that. >>> Timestamped snapshots is a solution to a problem I've never seen. I >>> expect snapshots to change so never want to be wed to a particular >>> one. >>> >>> -Dave >>> >>> On Fri, Aug 24, 2012 at 3:27 PM, Laird Nelson <[email protected]> wrote: >>>> On Fri, Aug 24, 2012 at 1:52 PM, David Hoffer <[email protected]> wrote: >>>> >>>>> We have been having nothing but trouble with Nexus and >>>>> Maven3 with the time-stamped snapshots and all the various metadata >>>>> files that Nexus spits out (which confuse Maven and IDEs). >>>> >>>> >>>> Oh, so this whole thing is a Nexus problem? Is that why none of my >>>> maven-metadata.xml files in my SNAPSHOT directories in my Nexus repository >>>> feature a <latest> tag (mind you, I'm guessing in the dark here about what >>>> this tag is for, and also guessing that it is used in resolving SNAPSHOTs)? >>>> Am I wrong in thinking that these files *should* feature such a tag if >>>> they are to be useful at all? Where would I go to learn more information >>>> about this? >>>> >>>> It certainly seems to be the case from others I've talked to that the >>>> "solution" is "redeploy another SNAPSHOT; that's the only way to get rid of >>>> this, and we don't know why it happens either". Surely that can't be the >>>> case. Surely there's some way to convince Maven to figure out what the >>>> latest SNAPSHOT is in a directory? Or to otherwise help it correct its >>>> mistaken belief that there are *no* *possible* snapshot resolutions? Is >>>> this a rare problem? >>>> >>>> Thanks for the input, David. >>>> >>>> Thanks, >>>> Laird >>>> >>>> -- >>>> http://about.me/lairdnelson >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
