Re: [RANT] This Maven thing is killing us....

> 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:kenney@...]
> > >> 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: dev-unsubscribe@...
> > > For additional commands, e-mail: dev-help@...
> > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@...
> > For additional commands, e-mail: dev-help@...
> >
>
> --
> Kenney Westerhof
> http://www.neonics.com
> GPG public key: http://www.gods.nl/~forge/kenneyw.key
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>