So you just want to verify?

$ mvn --help

usage: mvn [options] [<goal(s)>] [<phase(s)>]

Options:
 -am,--also-make                        If project list is specified, also
                                        build projects required by the
                                        list
 -amd,--also-make-dependents            If project list is specified, also
                                        build projects that depend on
                                        projects on the list
 -B,--batch-mode                        Run in non-interactive (batch)
                                        mode
 -C,--strict-checksums                  Fail the build if checksums don't
                                        match
 -c,--lax-checksums                     Warn if checksums don't match

Kalle


On Fri, Aug 6, 2010 at 1:01 PM, Haszlakiewicz, Eric
<[email protected]> wrote:
>>-----Original Message-----
>>From: [email protected] [mailto:[email protected]]
> On
>>
>>On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric
>><[email protected]>wrote:
>>
>>> Please read the rest of the email thread.  The short summary is:
>>>  Yes, I know what *should* happen, but the world isn't perfect and
>>release
>>> artifacts DO sometimes change.  It is not absurd to be able to detect
> and
>>> recover from that kind of situation.
>>>
>>>
>>The solution is to wipe out your local artifact. No one should be
> updating
>>released artifacts. If they do, they abused what a release means --
> hence
>>the problem to begin with. The solution given is the only (correct) one
> in
>>Maven.
>
> I'm AGREEING with you that the solution is to wipe out the local
> artifact!  But you can only do that once you know there is something
> wrong.  How do you detect that the artifact has changed?
> Maybe you'll get lucky and something is different enough in your
> artifact that the build process fails.  Or maybe you have some
> regression testing that you'll do so you notice the problem.  Having
> maven compare the checksums seems like a much more reliable way to catch
> these problems.
>
> eric
>
> ---------------------------------------------------------------------
> 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]

Reply via email to