maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Kuhnert" <jkuhn...@gmail.com>
Subject Re: [RANT] This Maven thing is killing us....
Date Sun, 02 Jul 2006 21:04:31 GMT
Maybe they've been deploying versions using a normal repository element
instead of defining a snapshot repository and -SNAPSHOT version ?

On 7/2/06, Jesse Kuhnert <jkuhnert@gmail.com> wrote:
>
> Yeah....Even though in my instance it wasn't what I wanted to happen (not
> maven's fault, unrelated local patches..), I have seen definite updates of
> SNAPSHOT builds with the same version.
>
> You can pretty easily infer why it works by looking at the timestamp
> generated poms from them...
>
>
> On 7/2/06, Carlos Sanchez <carlos@apache.org> wrote:
> >
> > I don't know what you're saying, you are the first one complaining
> > about it. SNAPSHOTS work for me
> >
> > On 7/2/06, roger.butenuth@sdm.de < roger.butenuth@sdm.de> 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:andy@handyande.co.uk]
> > > > 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:kenney@apache.org]
> > > > > >> 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@maven.apache.org For
> > > > > > additional commands, e-mail: dev-help@maven.apache.org
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > > > additional commands, e-mail: dev-help@maven.apache.org
> > > > >
> > > >
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For
> > > > additional commands, e-mail: dev-help@maven.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > > For additional commands, e-mail: dev-help@maven.apache.org
> > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >                              -- The Princess Bride
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>



-- 
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message