I had the same problem. One quick fix in the mean time is to set uniqueValue to true in the distributionManagement section of the project pom.
On 7/2/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Unfortunately the SNAPSHOT-feature is broken (at least in 2.0.4): When you have a copy of a snapshot versioned artifact, the jar is not updated when a new jar with same snapshot version is uploaded to the repository. I already filed this as a bug and hope it will be fixed in 2.0.5. It is annoying to increase version numbers during development or sending mails around "please delete xyz in you local repository... Roger > -----Ursprüngliche Nachricht----- > Von: Andrew Williams [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 2. Juli 2006 11:11 > An: Maven Developers List > Betreff: Re: [RANT] This Maven thing is killing us.... > > This is only true for release repositories though, as a > snapshot repository will have an updated version when you > re-deploy surely? > > Andy > > On Sun, 2006-07-02 at 07:01 +0800, Edwin Punzalan wrote: > > May I add, that when maven already downloaded a > poor/invalid pom, even > > after fixing the pom in the repository, maven won't know that it's > > changed (unless the version changed) and it will not > download it. So > > you end up still using your local repo copy. > > > > To re-download a pom, you have to delete your local copy first. > > > > This is a good solution though: > > http://jira.codehaus.org/browse/MNG-1258 > > > > > > Mike Perham wrote: > > >> -----Original Message----- > > >> From: Kenney Westerhof [mailto:[EMAIL PROTECTED] > > >> Sent: Saturday, July 01, 2006 2:59 PM > > >> To: Maven Developers List > > >> Subject: RE: [RANT] This Maven thing is killing us.... > > >> > > >> > > >> > > >>> Perhaps we can have a rule that every dependency MUST have > > >>> > > >> a declared > > >> > > >>> <scope> and <optional> element so that we know the > > >>> > > >> developer has thought > > >> > > >>> about the correct values for them, rather than always using the > > >>> defaults? > > >>> > > >> That's against Maven philosophy: conventions based builds. > > >> Only specify > > >> things that don't follow the defaults.. > > >> > > >> I think the problems with poms are because they're generated by > > >> default or converted from maven 1, or just uploaded by > someone who > > >> wants it there. > > >> If a project is built using maven 2, the poms should be correct. > > >> > > >> > > > > > > Agreed, but how do we solve the problem? My suggestion does not > > > force anyone to change their POMs _unless_ they want them > hosted at central. > > > The issue is that anything hosted at central necessarily > becomes a > > > publicly available component that others can use. If > people want to > > > use the conventions, fine, but there obviously needs to > be a higher > > > standard to make your component publicly available for use by > > > others. We are hurting nobody but ourselves by > distributing poorly > > > defined POMs because inevitably the Maven project as a > whole gets the blame. > > > > > > mike > > > > > > > -------------------------------------------------------------------- > > > - 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] > > --------------------------------------------------------------------- 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]
