That's not implemented yet. Maven won't recheck poms right now. It's
just informative

On 7/2/06, Kenney Westerhof <[EMAIL PROTECTED]> wrote:
On Sun, 2 Jul 2006, Edwin Punzalan wrote:

That's not entirely true. The distributionManagement section
has a <status> field that get's set on deploy:

<quote 
http://maven.apache.org/ref/current/maven-model/maven.html#class_distributionManagement>
Gives the status of this artifact in the remote repository. This must not
be set in your local project, as it is updated by tools placing it in the
repository. Valid values are:
- none (default),
- converted (repository manager converted this from an Maven 1 POM),
- partner  (directly synced from a partner Maven 2 repository),
- deployed (was deployed from a Maven 2 instance),
- verified (has been hand verified as correct and final).
</quote>

So when the status is not 'verified', maven will keep re-checking the pom
to see if it's final.

-- Kenney

>
> 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]
>

--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
                            -- The Princess Bride

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to