maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Hoffer <>
Subject Re: Maven/Nexus metadata interaction question
Date Fri, 24 Aug 2012 22:01:36 GMT
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.


On Fri, Aug 24, 2012 at 3:49 PM, Brian Fox <> wrote:
> On Fri, Aug 24, 2012 at 5:43 PM, David Hoffer <> 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
>> 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 <> wrote:
>>> On Fri, Aug 24, 2012 at 1:52 PM, David Hoffer <> 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
>>> --
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message