|
»
»
»
RE: [RANT] This Maven thing is killing us....
|
View:
New views
20 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 - 3 - 4 - 5 | Next > |
 |
RE: [RANT] This Maven thing is killing us....
by Mike Perham
::
Rate this Message:
"I'll spare you the details on that one"
This does nothing to solve the problem. We can't fix what we don't know about. The quality of the repository metadata has always struck me as something that will make or break the long-term success of Maven. We can only document it as best as possible - it's up to the module owner to provide a quality POM. Maybe we need a much harsher line around the quality of accepted POMs. 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? > -----Original Message----- > From: tcurdt@... [mailto:tcurdt@...] On Behalf Of > Torsten Curdt > Sent: Friday, June 30, 2006 12:06 PM > To: Maven Developers List > Subject: Fwd: [RANT] This Maven thing is killing us.... > > FYI > > ---------- Forwarded message ---------- > From: Bertrand Delacretaz <bdelacretaz@...> > Date: Jun 30, 2006 5:58 PM > Subject: [RANT] This Maven thing is killing us.... > To: dev@... > > > Hi gang, > > It's Friday, I'm tired and a bit depressed after losing about two more > hours unsuccessfully trying to add OJB to the dependencies of the > bricks-archetype example I'm working on (would have needed all of six > minutes to do this with our old ant build). > > I'll spare you the details on that one, but I think each of us present > at the ApacheCon EU Hackathon has lost several hours this week > fighting with Maven (or rather Maven repositories) problems instead of > doing useful progress. > > From what I understand now, it seems like most people using Maven in > their companies have their own local repositories, which they take > care to keep in good shape. > > But using public repositories seems to bring us more problems than > Maven should solve, especially because Cocoon integrates many > libraries from the ASF and from other places, and there are many ways > in which dependencies can be broken apparently. > > I'm sorry that I have nothing to suggest at this point (except going > back to ant, but it's probably a lot of work). > > The main thing is that I'm afraid our users will go away if they are > confronted with the same problems than many of us had this week trying > to catch up with 2.2. The collective time wasted on this is huge and > it hides all the good things that are in 2.2. > > Suggestions are welcome I guess. > > -Bertrand > > --------------------------------------------------------------------- > 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@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Alexandre Poitras
::
Rate this Message:
I don't know what he complains about. True sometimes the repository
quality sucks but just submit a patch and it usually take 3 to 4 days until the problem is solves. Really I don't want to seem arrogant but I haven't had those kind of troubles. On 6/30/06, Mike Perham <Mike.Perham@...> wrote: > "I'll spare you the details on that one" > > This does nothing to solve the problem. We can't fix what we don't know > about. > > The quality of the repository metadata has always struck me as something > that will make or break the long-term success of Maven. We can only > document it as best as possible - it's up to the module owner to provide > a quality POM. > > Maybe we need a much harsher line around the quality of accepted POMs. > 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? > > > -----Original Message----- > > From: tcurdt@... [mailto:tcurdt@...] On Behalf Of > > Torsten Curdt > > Sent: Friday, June 30, 2006 12:06 PM > > To: Maven Developers List > > Subject: Fwd: [RANT] This Maven thing is killing us.... > > > > FYI > > > > ---------- Forwarded message ---------- > > From: Bertrand Delacretaz <bdelacretaz@...> > > Date: Jun 30, 2006 5:58 PM > > Subject: [RANT] This Maven thing is killing us.... > > To: dev@... > > > > > > Hi gang, > > > > It's Friday, I'm tired and a bit depressed after losing about two more > > hours unsuccessfully trying to add OJB to the dependencies of the > > bricks-archetype example I'm working on (would have needed all of six > > minutes to do this with our old ant build). > > > > I'll spare you the details on that one, but I think each of us present > > at the ApacheCon EU Hackathon has lost several hours this week > > fighting with Maven (or rather Maven repositories) problems instead of > > doing useful progress. > > > > From what I understand now, it seems like most people using Maven in > > their companies have their own local repositories, which they take > > care to keep in good shape. > > > > But using public repositories seems to bring us more problems than > > Maven should solve, especially because Cocoon integrates many > > libraries from the ASF and from other places, and there are many ways > > in which dependencies can be broken apparently. > > > > I'm sorry that I have nothing to suggest at this point (except going > > back to ant, but it's probably a lot of work). > > > > The main thing is that I'm afraid our users will go away if they are > > confronted with the same problems than many of us had this week trying > > to catch up with 2.2. The collective time wasted on this is huge and > > it hides all the good things that are in 2.2. > > > > Suggestions are welcome I guess. > > > > -Bertrand > > > > --------------------------------------------------------------------- > > 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@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Bertrand L. Delacretaz
::
Rate this Message:
On 6/30/06, Mike Perham <Mike.Perham@...> wrote:
> "I'll spare you the details on that one" > > This does nothing to solve the problem. We can't fix what we don't know > about... Sorry about that, if was meaning to write to the Maven list with more precise information later, my email was meant for the Cocoon team first. I will be talking with Cocoon people who know Maven better than me and come back with more constructive ideas hopefully. -Bertrand --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
RE: [RANT] This Maven thing is killing us....
by Kenney Westerhof-3
::
Rate this Message:
On Fri, 30 Jun 2006, Mike Perham wrote:
<snip> > Maybe we need a much harsher line around the quality of accepted POMs. Maybe that's wise. > 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. -- Kenney > > -----Original Message----- > > From: tcurdt@... [mailto:tcurdt@...] On Behalf Of > > Torsten Curdt > > Sent: Friday, June 30, 2006 12:06 PM > > To: Maven Developers List > > Subject: Fwd: [RANT] This Maven thing is killing us.... > > > > FYI > > > > ---------- Forwarded message ---------- > > From: Bertrand Delacretaz <bdelacretaz@...> > > Date: Jun 30, 2006 5:58 PM > > Subject: [RANT] This Maven thing is killing us.... > > To: dev@... > > > > > > Hi gang, > > > > It's Friday, I'm tired and a bit depressed after losing about two more > > hours unsuccessfully trying to add OJB to the dependencies of the > > bricks-archetype example I'm working on (would have needed all of six > > minutes to do this with our old ant build). > > > > I'll spare you the details on that one, but I think each of us present > > at the ApacheCon EU Hackathon has lost several hours this week > > fighting with Maven (or rather Maven repositories) problems instead of > > doing useful progress. > > > > From what I understand now, it seems like most people using Maven in > > their companies have their own local repositories, which they take > > care to keep in good shape. > > > > But using public repositories seems to bring us more problems than > > Maven should solve, especially because Cocoon integrates many > > libraries from the ASF and from other places, and there are many ways > > in which dependencies can be broken apparently. > > > > I'm sorry that I have nothing to suggest at this point (except going > > back to ant, but it's probably a lot of work). > > > > The main thing is that I'm afraid our users will go away if they are > > confronted with the same problems than many of us had this week trying > > to catch up with 2.2. The collective time wasted on this is huge and > > it hides all the good things that are in 2.2. > > > > Suggestions are welcome I guess. > > > > -Bertrand > > > > --------------------------------------------------------------------- > > 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@... |
|
|
|
|
|
Re: [RANT] This Maven thing is killing us....
by Edwin Punzalan
::
Rate this Message:
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@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Andrew Williams-5
::
Rate this Message:
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@...] > >> 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@... > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Kenney Westerhof-3
::
Rate this Message:
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@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Carlos Sanchez-4
::
Rate this Message:
That's not implemented yet. Maven won't recheck poms right now. It's
just informative On 7/2/06, Kenney Westerhof <kenney@...> 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: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@... > > -- 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@... For additional commands, e-mail: dev-help@... |
|
|
Re: [RANT] This Maven thing is killing us....
by Kenney Westerhof-3
::
Rate this Message:
On Sun, 2 Jul 2006, Carlos Sanchez wrote:
Ah.. Well, it used to work in the beta's.. :) There was a problem then with manually installed projects who lacked the status field - it tried to download them from ibiblio which didn't have them, and then the build failed. But that's a long time ago now. But I'm probably wrong.. :) > That's not implemented yet. Maven won't recheck poms right now. It's > just informative > > On 7/2/06, Kenney Westerhof <kenney@...> 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: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@... > > > > > > > -- > 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@... > 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@... |
|
|
|
|
|
Re: [RANT] This Maven thing is killing us....
by Alexandre Poitras
::
Rate this Message:
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, roger.butenuth@... <roger.butenuth@...> 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@...] > > 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@...] > > > >> 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@... > > > > > > > > > --------------------------------------------------------------------- > > 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@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: |
