Re: force maven to redownload/refresh "released" dependencies
On 09/08/2010 1:25 PM, Jason van Zyl wrote: On Aug 9, 2010, at 12:57 PM, Haszlakiewicz, Eric wrote: -Original Message- From: Jason van Zyl [mailto:ja...@sonatype.com] The nut of the problem is that if we had to support every optional behavior for a particular subset of the community the code base would likely be unmaintainable. No one here is going to implement anything toward what you're specifically asking for because Maven was specifically designed not to work for what you want. It probably would not be hard to do what you ask for, but just because something is possible doesn't mean it's a good idea to do it. I understand that including every potential optional feature is not reasonable, and I'm not expecting that someone immediately go implement this for me just because I'm asking. However, I was hoping that it wouldn't get immediately dismissed without apparently considering the usefulness of it (especially since it seems like sometime similar is already done for snapshots), and I was hoping to perhaps even get a pointer of the sort of "we don't have the time to do it, but if you really want to work on this look at X". But, oh well, I guess I'll try to figure it out on my own. Now what you're asking for here sounds particularly disastrous. If across your organization a release does not actually mean a release in the Maven Again, you're missing my point. I AM NOT ASKING TO ALLOW RELEASES TO CHANGE! I think a few steps down the road, and what you are asking for makes that very possible. I'm just cognizant of the thin end of the wedge, and one small change opens up all sorts of unexpected results. I just want a way to detect that something has become inconsistent when someone makes a mistake, and fail the build. If you think detecting problems is disastrous, well I don't really know what to say to that. That is an erroneous logical extension of what I described. Any movement toward and supporting mutable releases is disastrous. Detecting problems is far to general a category to assign us not caring about. Preventing this problem by not allowing releases to change is better than detecting them afterwards. You might also want to consider the approach that we took. We eliminated 90% of the dependency references in individual POMs by using aggregating POMs that define the dependency on whole sets of individual artifacts so that application POMs only refer to a few (5 or so) aggregations to get 60-70 individual artifacts into the application jars and wars. This makes it easy to fix the kind of problem that you encountered since I only have to fix and rerelease 1 SNAPSHOT to get everyone back on the same page if we are in the SNAPSHOT phase of a release or fix and update the minor release of the aggregation if it is released. If we are actually preparing a release, people do have to be told to update their dependencies but at least it is easy to find since you only have 5 to look through and you know you have it because almost every project POM has it. I suspect that the kind of error that you hit, would always occur in a SNAPSHOT phase and never in the release phase of an application since the error would jump out at you as soon as you tried to use the badly named artifacts. You could write your own metadata on deploy, and use the enforcer plugin to verify the state as you wish, react accordingly. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Aug 9, 2010, at 12:57 PM, Haszlakiewicz, Eric wrote: >> -Original Message- >> From: Jason van Zyl [mailto:ja...@sonatype.com] >> >> The nut of the problem is that if we had to support every optional > behavior >> for a particular subset of the community the code base would likely be >> unmaintainable. No one here is going to implement anything toward what >> you're specifically asking for because Maven was specifically designed > not >> to work for what you want. It probably would not be hard to do what you > ask >> for, but just because something is possible doesn't mean it's a good > idea >> to do it. > > I understand that including every potential optional feature is not > reasonable, and I'm not expecting that someone immediately go implement > this for me just because I'm asking. However, I was hoping that it > wouldn't get immediately dismissed without apparently considering the > usefulness of it (especially since it seems like sometime similar is > already done for snapshots), and I was hoping to perhaps even get a > pointer of the sort of "we don't have the time to do it, but if you > really want to work on this look at X". > But, oh well, I guess I'll try to figure it out on my own. > >> Now what you're asking for here sounds particularly disastrous. If > across >> your organization a release does not actually mean a release in the > Maven > > Again, you're missing my point. I AM NOT ASKING TO ALLOW RELEASES TO > CHANGE! I think a few steps down the road, and what you are asking for makes that very possible. I'm just cognizant of the thin end of the wedge, and one small change opens up all sorts of unexpected results. > I just want a way to detect that something has become > inconsistent when someone makes a mistake, and fail the build. If you > think detecting problems is disastrous, well I don't really know what to > say to that. That is an erroneous logical extension of what I described. Any movement toward and supporting mutable releases is disastrous. Detecting problems is far to general a category to assign us not caring about. You could write your own metadata on deploy, and use the enforcer plugin to verify the state as you wish, react accordingly. > > eric > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Jason van Zyl [mailto:ja...@sonatype.com] > >The nut of the problem is that if we had to support every optional behavior >for a particular subset of the community the code base would likely be >unmaintainable. No one here is going to implement anything toward what >you're specifically asking for because Maven was specifically designed not >to work for what you want. It probably would not be hard to do what you ask >for, but just because something is possible doesn't mean it's a good idea >to do it. I understand that including every potential optional feature is not reasonable, and I'm not expecting that someone immediately go implement this for me just because I'm asking. However, I was hoping that it wouldn't get immediately dismissed without apparently considering the usefulness of it (especially since it seems like sometime similar is already done for snapshots), and I was hoping to perhaps even get a pointer of the sort of "we don't have the time to do it, but if you really want to work on this look at X". But, oh well, I guess I'll try to figure it out on my own. >Now what you're asking for here sounds particularly disastrous. If across >your organization a release does not actually mean a release in the Maven Again, you're missing my point. I AM NOT ASKING TO ALLOW RELEASES TO CHANGE! I just want a way to detect that something has become inconsistent when someone makes a mistake, and fail the build. If you think detecting problems is disastrous, well I don't really know what to say to that. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Wayne Fay [mailto:wayne...@gmail.com] > >>> I rapidly browsed the thread, please excuse me if I missed something. >>> Isn't mvn dependency:purge-local-repository the solution? >> >> The issue identified by the OP is that there's no way to (pro-actively) >detect that a release has changed. > >I apologize in advance for a TERRIBLE suggestion... assuming you are >running a local MRM and thus merely consuming local bandwith... you >could bind purge-local-repo to init phase. > >PS- Don't do this! Even with a local repository manager this isn't that great of a suggestion: local might mean faster network, but not infinite bandwidth, especially when you've got more than a few developers working on things. (and the few extra minutes it would add to the build even for one developer would be kind of annoying) eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
>> I rapidly browsed the thread, please excuse me if I missed something. >> Isn't mvn dependency:purge-local-repository the solution? > > The issue identified by the OP is that there's no way to (pro-actively) > detect that a release has changed. I apologize in advance for a TERRIBLE suggestion... assuming you are running a local MRM and thus merely consuming local bandwith... you could bind purge-local-repo to init phase. PS- Don't do this! Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Aug 8, 2010, at 5:32 AM, Baptiste MATHUS wrote: > Hi, > > I rapidly browsed the thread, please excuse me if I missed something. > Isn't mvn dependency:purge-local-repository the solution? The issue identified by the OP is that there's no way to (pro-actively) detect that a release has changed. > > Please note that I'm 100% with people saying releases must never change. And > it's so important it's not something specific to maven world. Imagine you > release a 1.0 to some client, and try to find the corresponding sources when > encountering a blocking bug. You're either going not to be able to find the > right sources, or to have to do some ugly thing like storing svn-revision in > the MANIFEST while packaging the jar... That's just something that should > not be done in the software world, period. > > Cheers > > Le 5 août 2010 22:08:03 UTC+2, Wayne Fay a écrit : > >>> The network traffic that that would cause in a modern project with dozens >> of >>> dependencies would create a real nuisance. >> >> If every artifact had md5 and sha1 hashes etc, then the traffic would >> merely be to check the hashes against the local artifact... which >> Maven already does, and complains when things don't match. >> >> Note: I'm not encouraging this approach. Releases must never change, >> period, end of story. Push another release if you find a given release >> is broken. >> >> Wayne >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > -- > Baptiste MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 08/08/2010 5:32 AM, Baptiste MATHUS wrote: Hi, I rapidly browsed the thread, please excuse me if I missed something. Isn't mvn dependency:purge-local-repository the solution? Please note that I'm 100% with people saying releases must never change. And it's so important it's not something specific to maven world. Imagine you release a 1.0 to some client, and try to find the corresponding sources when encountering a blocking bug. You're either going not to be able to find the right sources, or to have to do some ugly thing like storing svn-revision in the MANIFEST while packaging the jar... That's just something that should not be done in the software world, period. That is exactly what happened to us using an open source project. Caused grief for a long time. One is never really sure which artifact or set of sources match up with what you are running. Ron Cheers Le 5 août 2010 22:08:03 UTC+2, Wayne Fay a écrit : The network traffic that that would cause in a modern project with dozens of dependencies would create a real nuisance. If every artifact had md5 and sha1 hashes etc, then the traffic would merely be to check the hashes against the local artifact... which Maven already does, and complains when things don't match. Note: I'm not encouraging this approach. Releases must never change, period, end of story. Push another release if you find a given release is broken. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Hi, I rapidly browsed the thread, please excuse me if I missed something. Isn't mvn dependency:purge-local-repository the solution? Please note that I'm 100% with people saying releases must never change. And it's so important it's not something specific to maven world. Imagine you release a 1.0 to some client, and try to find the corresponding sources when encountering a blocking bug. You're either going not to be able to find the right sources, or to have to do some ugly thing like storing svn-revision in the MANIFEST while packaging the jar... That's just something that should not be done in the software world, period. Cheers Le 5 août 2010 22:08:03 UTC+2, Wayne Fay a écrit : > > The network traffic that that would cause in a modern project with dozens > of > > dependencies would create a real nuisance. > > If every artifact had md5 and sha1 hashes etc, then the traffic would > merely be to check the hashes against the local artifact... which > Maven already does, and complains when things don't match. > > Note: I'm not encouraging this approach. Releases must never change, > period, end of story. Push another release if you find a given release > is broken. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Baptiste MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
Re: force maven to redownload/refresh "released" dependencies
Eric This is the kindest and gentlest explanation of the situation and the best offer that you are going to get. Ron On 06/08/2010 8:38 PM, Jason van Zyl wrote: The nut of the problem is that if we had to support every optional behavior for a particular subset of the community the code base would likely be unmaintainable. No one here is going to implement anything toward what you're specifically asking for because Maven was specifically designed not to work for what you want. It probably would not be hard to do what you ask for, but just because something is possible doesn't mean it's a good idea to do it. Generally when people argue along the lines of "well my organization doesn't do that and we can't change" I retort that the community of Maven users is like an organization and it's far more powerful then yours. We don't do that and we're not going to change. So the onus would be on you to take the sources of Maven and alter it for your use and then the cost of maintaining that behavior becomes yours and it's not cheap. It's really not cheap. We can't make everyone happy and that's ok with us, well it's at least ok with me. I guess I can't speak for everyone. There are other build tool options, or you can maintain your own fork of Maven with the behavior your organization desires. Now what you're asking for here sounds particularly disastrous. If across your organization a release does not actually mean a release in the Maven sense you are going to have so many problems with what plugins normally expect and how artifacts may be integrated across different groups. Trust me, you do not want to go hunting around trying to figure out if something actually changed because looking at an artifact that is supposed to be immutable in Maven but isn't just screams out N points of failure. None of the IDE integration would work properly, many of the CI tools also wouldn't work very well. You're just asking for a world of very expensive pain. Every organization can change. You may not be able to change tomorrow but you can change. I've seen it happen at the biggest of the big. My suggestion if you are looking at Maven is to start with a smaller project and use Maven the way it's supposed to be used and evaluate if that's workable for your organization today. I can tell you with absolute certainty that what you're asking for is never going to implemented. But on the dev list we can point you in the right direction if you want to hack something up yourself. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
if the developer just completed the code but the artifact did'nt execute and pass all the test-suites tag as alpha so the user community know thats its dicey at best artifact-version-alpha-1 if the artifact passes muster (no errors and no failures) with all the test suites (surefire) then tag it as beta artifact-version-beta-2 if someone wants a build right now the artifact developer can release immediately as snapshot artifact-version-snapshot if the artifactId is blessed by more than the developer then you can tag as RC e.g. artifact-version-RC1 the idea behind version controlled build environments (such as maven) is the developer can request a specific artifact for example: e.g. user pings author to request artifact-A will incorporate function X developer factors code to implement function X author releases artifact-version-snapshot all the other developers know that referencing an alpha or beta or snapshot is dicey and should not pollute their production builds when the developer finally sees the artifact version has been promoted to RC (release candidate) they can reference the Release Candidate in their production builds this is my understanding of how maven contributes to the SDLC process. Take a look at configuring classifier for use in a qualified artifact for implementation details http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-platform-classifier.html Bedankt Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Subject: Re: force maven to redownload/refresh "released" dependencies > From: kath...@kathrynhuxtable.org > Date: Fri, 6 Aug 2010 18:28:32 -0500 > To: users@maven.apache.org > > On Aug 6, 2010, at 6:16 PM, Ron Wheeler wrote: > > > On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote: > >>> -Original Message- > >>> From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > >>>> I'm AGREEING with you that the solution is to wipe out the local > >>>> artifact! But you can only do that once you know there is something > >>>> wrong. How do you detect that the artifact has changed? > >>> If you can not deploy the release, that will tell you that you are > >>> trying to rerelease an artifact. > >>>> Maybe you'll get lucky and something is different enough in your > >>>> artifact that the build process fails. > >>> Your attempt to deploy will fail. That will tell you right away that > >> you > >>> are doing the wrong thing. > >> No, the deployment of a project that USES a changed artifact will NOT > >> fail. > > > > Yes. > > That is why releases can not be replaced. > > In your case, you should have deleted the wrong artifacts and loaded them > > with new versions. > > And informed the victims that they needed to update their dependencies. > > > > You were completely in control of the versions and names. > > And, frustrating though it is, that's what I've done when my bad QC has > released bad stuff onto Central. You just put out another version and > apologize on the web page. There's not a lot else to do, and it's not that > bad. > > -K > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org >
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 3:53 PM, Haszlakiewicz, Eric wrote: >> -Original Message- >> From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org] >> >> Eric, you're not going to win this one. It's part of the philosophy of >> Maven. It's also good practice. >> >> Give it up. >> >> I'm not going to fight the site generation being split out of Maven. I >> think I understand Jason's point on that, though I disagree. And that's > a >> *much* less nasty violation of Maven's perceived function, if in fact, > it >> is a violation. >> >> What you're wanting is a violation. > > You're missing the point of what I'm asking. I'm not suggesting that > maven make it possible or easy to *create* the violation. I'm > suggesting that it should be able to *detect* the violation. > > I'm baffled as to why the maven community is so against the idea of > having additional (optional) checks to detect problems. > The nut of the problem is that if we had to support every optional behavior for a particular subset of the community the code base would likely be unmaintainable. No one here is going to implement anything toward what you're specifically asking for because Maven was specifically designed not to work for what you want. It probably would not be hard to do what you ask for, but just because something is possible doesn't mean it's a good idea to do it. Generally when people argue along the lines of "well my organization doesn't do that and we can't change" I retort that the community of Maven users is like an organization and it's far more powerful then yours. We don't do that and we're not going to change. So the onus would be on you to take the sources of Maven and alter it for your use and then the cost of maintaining that behavior becomes yours and it's not cheap. It's really not cheap. We can't make everyone happy and that's ok with us, well it's at least ok with me. I guess I can't speak for everyone. There are other build tool options, or you can maintain your own fork of Maven with the behavior your organization desires. Now what you're asking for here sounds particularly disastrous. If across your organization a release does not actually mean a release in the Maven sense you are going to have so many problems with what plugins normally expect and how artifacts may be integrated across different groups. Trust me, you do not want to go hunting around trying to figure out if something actually changed because looking at an artifact that is supposed to be immutable in Maven but isn't just screams out N points of failure. None of the IDE integration would work properly, many of the CI tools also wouldn't work very well. You're just asking for a world of very expensive pain. Every organization can change. You may not be able to change tomorrow but you can change. I've seen it happen at the biggest of the big. My suggestion if you are looking at Maven is to start with a smaller project and use Maven the way it's supposed to be used and evaluate if that's workable for your organization today. I can tell you with absolute certainty that what you're asking for is never going to implemented. But on the dev list we can point you in the right direction if you want to hack something up yourself. > eric > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - the course of true love never did run smooth ... -- Shakespeare
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 6:16 PM, Ron Wheeler wrote: > On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote: >>> -Original Message- >>> From: Ron Wheeler [mailto:rwhee...@artifact-software.com] I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? >>> If you can not deploy the release, that will tell you that you are >>> trying to rerelease an artifact. Maybe you'll get lucky and something is different enough in your artifact that the build process fails. >>> Your attempt to deploy will fail. That will tell you right away that >> you >>> are doing the wrong thing. >> No, the deployment of a project that USES a changed artifact will NOT >> fail. > > Yes. > That is why releases can not be replaced. > In your case, you should have deleted the wrong artifacts and loaded them > with new versions. > And informed the victims that they needed to update their dependencies. > > You were completely in control of the versions and names. And, frustrating though it is, that's what I've done when my bad QC has released bad stuff onto Central. You just put out another version and apologize on the web page. There's not a lot else to do, and it's not that bad. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 06/08/2010 5:56 PM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? If you can not deploy the release, that will tell you that you are trying to rerelease an artifact. Maybe you'll get lucky and something is different enough in your artifact that the build process fails. Your attempt to deploy will fail. That will tell you right away that you are doing the wrong thing. No, the deployment of a project that USES a changed artifact will NOT fail. Yes. That is why releases can not be replaced. In your case, you should have deleted the wrong artifacts and loaded them with new versions. And informed the victims that they needed to update their dependencies. You were completely in control of the versions and names. Ron eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote: >> Is it really going to be that much wasted bandwidth to download a few >> checksums? >> >> Can a plugin hook into the existing support for detecting changes in >> snapshots? >You do not have to. >SNAPSHOTS are checked in exactly the way you want releases to be checked >because SNAPSHOTS are supposed to change and by default you get the >latest deployed SNAPSHOT. >To find out if you have the latest SNAPSHOT, Maven will check the >repository and download the new version for you automatically. So you're saying that I should always upload a released package using a SNAPSHOT version? Then it seems like I'm lying about what the package actually is. >That is why we are so comfortable with the current system. >Only the stuff that you indicate is unstable, is checked and the stable >stuff (called Releases) can be used from your local cache without problem. > >The clear distinction between a stable release and a SNAPSHOT is your >team's commitment to each other not to break things after you have said >that they are done. ...snip... I am not arguing against the idea of having snapshots that can be updated, and releases that stay stable. I'm perfectly fine with that being what *should* happen, but I know it's impossible that the correct procedures will be followed at all times. It seems that you're connecting the creation of a release with the process of uploading it to a particular repository. If you're dealing solely with projects that use maven, and perfect people that never fiddle with the repository directly, then you can probably consider those to be equivalent. But not everything is a maven project, and not everyone follows the perfect procedures, and not all disks are perfectly immune from corruption. If there is ever a problem with uploading the artifact to the repository, or with it after it's been uploaded, then I'd want to know that there is something wrong. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] >> I'm AGREEING with you that the solution is to wipe out the local >> artifact! But you can only do that once you know there is something >> wrong. How do you detect that the artifact has changed? >If you can not deploy the release, that will tell you that you are >trying to rerelease an artifact. >> Maybe you'll get lucky and something is different enough in your >> artifact that the build process fails. >Your attempt to deploy will fail. That will tell you right away that you >are doing the wrong thing. No, the deployment of a project that USES a changed artifact will NOT fail. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 06/08/2010 4:04 PM, Haszlakiewicz, Eric wrote: -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric wrote: You're missing the point of what I'm asking. I'm not suggesting that maven make it possible or easy to *create* the violation. I'm suggesting that it should be able to *detect* the violation. I'm baffled as to why the maven community is so against the idea of having additional (optional) checks to detect problems. Eric, The point is releases don't change. To "detect" means wasting bandwidth comparing your supposedly unchanging released local artifacts to supposedly unchanging released remote artifacts. If anything, writing a Maven plug-in for this would be more appropriate, but I don't see your suggestion as part of Maven core. Is it really going to be that much wasted bandwidth to download a few checksums? Can a plugin hook into the existing support for detecting changes in snapshots? You do not have to. SNAPSHOTS are checked in exactly the way you want releases to be checked because SNAPSHOTS are supposed to change and by default you get the latest deployed SNAPSHOT. To find out if you have the latest SNAPSHOT, Maven will check the repository and download the new version for you automatically. That is why we are so comfortable with the current system. Only the stuff that you indicate is unstable, is checked and the stable stuff (called Releases) can be used from your local cache without problem. The clear distinction between a stable release and a SNAPSHOT is your team's commitment to each other not to break things after you have said that they are done. With SNAPSHOTS you can decide to stick with a certain version of a SNAPSHOT or take the latest depending on your informal contract with the developer. If I tell you that today I am deploying a SNAPSHOT that is tested to do this function and that function while I am continuing to work on a third function and fix a deficiency in the first function, at least you know what you have to deal with. Youi can decide that you want to get my fixes as soon as they are deployed or you want to stick with the buggy one since your code deals with the bug and you want to go on testing with a stable version of my SNAPSHOT. But it is your choice and you know what you are getting. If I deploy a Release of my artifact, you are assured that I am promising you a production quality artifact ready to go in the final build. If you, God forbid, find a bug in my release 2.1.4, I must issue a patched version with a new version number 2.1.5 or 2.1.4.1 and let people know that if they want the fixed version, they have to change their dependencies or suffer the bug that you found. I can not lie to you about what you are getting. In a team, this is a big help. Ron eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 06/08/2010 4:01 PM, Haszlakiewicz, Eric wrote: -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric wrote: Please read the rest of the email thread. The short summary is: Yes, I know what *should* happen, but the world isn't perfect and release artifacts DO sometimes change. It is not absurd to be able to detect and recover from that kind of situation. The solution is to wipe out your local artifact. No one should be updating released artifacts. If they do, they abused what a release means -- hence the problem to begin with. The solution given is the only (correct) one in Maven. I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? If you can not deploy the release, that will tell you that you are trying to rerelease an artifact. Maybe you'll get lucky and something is different enough in your artifact that the build process fails. Your attempt to deploy will fail. That will tell you right away that you are doing the wrong thing. Or maybe you have some regression testing that you'll do so you notice the problem. Having maven compare the checksums seems like a much more reliable way to catch these problems. Yes use SNAPSHOTS. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 2:58 PM, Paul Benedict wrote: > On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric > wrote: > >> You're missing the point of what I'm asking. I'm not suggesting that >> maven make it possible or easy to *create* the violation. I'm >> suggesting that it should be able to *detect* the violation. >> >> I'm baffled as to why the maven community is so against the idea of >> having additional (optional) checks to detect problems. >> >> > Eric, > > The point is releases don't change. To "detect" means wasting bandwidth > comparing your supposedly unchanging released local artifacts to supposedly > unchanging released remote artifacts. If anything, writing a Maven plug-in > for this would be more appropriate, but I don't see your suggestion as part > of Maven core. And actually, it wouldn't be that hard to write such a plugin. But you have to want it... -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Eduardo M KALINOWSKI [mailto:edua...@kalinowski.com.br] > >On Sex, 06 Ago 2010, "Haszlakiewicz, Eric" wrote: >> I'm AGREEING with you that the solution is to wipe out the local >> artifact! But you can only do that once you know there is something >> wrong. How do you detect that the artifact has changed? > >You don't have to, because released artifacts do not change[0]. > >[0]Unless someone intentionally screws up. And it is no accidental >screw up, I think all artifact managers forbid redeploying a non >snapshot version. So in order to that happen, someone must circunvent >the normal deploying route. If someone really needs to do so, then >that person may simply warn everyone that might be affected. That is >feasible, because such situation should never happen in any of the >public repositories, being limited to the organization repository. It doesn't require much of a screwup to create a changed release artifacts. For example, all it takes is a simple typo when uploading an artifact to your nexus repository. I did exactly this when trying to import a specific release of a package that isn't available on central and isn't built through maven. I ended up with releases in the repository with the wrong jar files attached, and by the time I noticed it was wrong people had already tried to build things using it, and I didn't realize that there was something I needed to warn about. Even if I did warn people, the overhead of everyone needing to read an email, figure out where they ran builds from, figure out what needs to be removed and remove the files from every machine that they might have worked on is huge. i.e. I intended to upload foox-1.2.jar as com.mycompany:foox:1.2 fooy-1.2.jar as com.mycompany:fooy:1.2 but I actually ended up with it switched fooy-1.2.jar as com.mycompany:foox:1.2 foox-1.2.jar as com.mycompany:fooy:1.2 I don't have control over the release cycle of these packages so I couldn't just declare a new release. Even after I fixed our central repository people were having problems building. Eventually we figured out what was going on, but it would have been far easier if maven could have actually told us that there was an inconsistency between the central repo and the .m2 directories. In the real world artifacts DO change. I've seen other people ask about this on the mailing list so I know I'm not the only one that has run into situations like this. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
On Sex, 06 Ago 2010, "Haszlakiewicz, Eric" wrote: I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? You don't have to, because released artifacts do not change[0]. [0]Unless someone intentionally screws up. And it is no accidental screw up, I think all artifact managers forbid redeploying a non snapshot version. So in order to that happen, someone must circunvent the normal deploying route. If someone really needs to do so, then that person may simply warn everyone that might be affected. That is feasible, because such situation should never happen in any of the public repositories, being limited to the organization repository. -- Be circumspect in your liaisons with women. It is better to be seen at the opera with a man than at mass with a woman. -- De Maintenon Eduardo M KALINOWSKI edua...@kalinowski.com.br - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On >On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric >wrote: > >> You're missing the point of what I'm asking. I'm not suggesting that >> maven make it possible or easy to *create* the violation. I'm >> suggesting that it should be able to *detect* the violation. >> >> I'm baffled as to why the maven community is so against the idea of >> having additional (optional) checks to detect problems. >> >> >Eric, > >The point is releases don't change. To "detect" means wasting bandwidth >comparing your supposedly unchanging released local artifacts to supposedly >unchanging released remote artifacts. If anything, writing a Maven plug-in >for this would be more appropriate, but I don't see your suggestion as part >of Maven core. Is it really going to be that much wasted bandwidth to download a few checksums? Can a plugin hook into the existing support for detecting changes in snapshots? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
So you just want to verify? $ mvn --help usage: mvn [options] [] [] Options: -am,--also-makeIf project list is specified, also build projects required by the list -amd,--also-make-dependentsIf project list is specified, also build projects that depend on projects on the list -B,--batch-modeRun in non-interactive (batch) mode -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksums Warn if checksums don't match Kalle On Fri, Aug 6, 2010 at 1:01 PM, Haszlakiewicz, Eric wrote: >>-Original Message- >>From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] > On >> >>On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric >>wrote: >> >>> Please read the rest of the email thread. The short summary is: >>> Yes, I know what *should* happen, but the world isn't perfect and >>release >>> artifacts DO sometimes change. It is not absurd to be able to detect > and >>> recover from that kind of situation. >>> >>> >>The solution is to wipe out your local artifact. No one should be > updating >>released artifacts. If they do, they abused what a release means -- > hence >>the problem to begin with. The solution given is the only (correct) one > in >>Maven. > > I'm AGREEING with you that the solution is to wipe out the local > artifact! But you can only do that once you know there is something > wrong. How do you detect that the artifact has changed? > Maybe you'll get lucky and something is different enough in your > artifact that the build process fails. Or maybe you have some > regression testing that you'll do so you notice the problem. Having > maven compare the checksums seems like a much more reliable way to catch > these problems. > > eric > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
> On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric > wrote: > >> You're missing the point of what I'm asking. I'm not suggesting that >> maven make it possible or easy to *create* the violation. I'm >> suggesting that it should be able to *detect* the violation. >> >> I'm baffled as to why the maven community is so against the idea of >> having additional (optional) checks to detect problems. >> >> > Eric, > > The point is releases don't change. To "detect" means wasting bandwidth > comparing your supposedly unchanging released local artifacts to > supposedly > unchanging released remote artifacts. If anything, writing a Maven plug-in > for this would be more appropriate, but I don't see your suggestion as > part > of Maven core. Exactly what I suggested. If you really need this you will have to do it yourself. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On > >On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric >wrote: > >> Please read the rest of the email thread. The short summary is: >> Yes, I know what *should* happen, but the world isn't perfect and >release >> artifacts DO sometimes change. It is not absurd to be able to detect and >> recover from that kind of situation. >> >> >The solution is to wipe out your local artifact. No one should be updating >released artifacts. If they do, they abused what a release means -- hence >the problem to begin with. The solution given is the only (correct) one in >Maven. I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? Maybe you'll get lucky and something is different enough in your artifact that the build process fails. Or maybe you have some regression testing that you'll do so you notice the problem. Having maven compare the checksums seems like a much more reliable way to catch these problems. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Fri, Aug 6, 2010 at 2:53 PM, Haszlakiewicz, Eric wrote: > You're missing the point of what I'm asking. I'm not suggesting that > maven make it possible or easy to *create* the violation. I'm > suggesting that it should be able to *detect* the violation. > > I'm baffled as to why the maven community is so against the idea of > having additional (optional) checks to detect problems. > > Eric, The point is releases don't change. To "detect" means wasting bandwidth comparing your supposedly unchanging released local artifacts to supposedly unchanging released remote artifacts. If anything, writing a Maven plug-in for this would be more appropriate, but I don't see your suggestion as part of Maven core. Paul
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Kathryn Huxtable [mailto:kath...@kathrynhuxtable.org] > >Eric, you're not going to win this one. It's part of the philosophy of >Maven. It's also good practice. > >Give it up. > >I'm not going to fight the site generation being split out of Maven. I >think I understand Jason's point on that, though I disagree. And that's a >*much* less nasty violation of Maven's perceived function, if in fact, it >is a violation. > >What you're wanting is a violation. You're missing the point of what I'm asking. I'm not suggesting that maven make it possible or easy to *create* the violation. I'm suggesting that it should be able to *detect* the violation. I'm baffled as to why the maven community is so against the idea of having additional (optional) checks to detect problems. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
I second this! I've used Artifactory and liked it. (I somewhat prefer Nexus, at least the last time I looked at Artifactory.) -K On Aug 6, 2010, at 1:47 PM, Yoav Landman wrote: > You may want to take a look at the CI integration in Artifactory - > http://wiki.jfrog.org/confluence/display/RTF/Build+Integration > You can get a json object with a report of all this information captured at > build time: detailed build environment information, published artifacts and > resolved dependencies of all scopes. > Like many have commented here, re-downloading cached release artifacts if > you run your build from scratch should be done from the caches of your repo > manager. > > Yoav > > On Sat, Jul 31, 2010 at 12:07 AM, Shan Syed wrote: > >> no, this isn't in regard to our own published artifacts >> >> I regret starting this thread, I apologize >> I didn't mean this question to be an affront to maven conventions - I just >> need to figure out a better way to capture a full log >> they even want a log of how the build environment was downloaded and >> installed >> >> >> On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict >> wrote: >> >>> There is a maxim to follow when deploying: "do not redeploy a version >> more >>> than once". Once you deploy version X.Y.Z, it should never be updated, >> and >>> those who download it never need to download it again. So, back to the >>> original problem, are you guys doing that? >>> >>> On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: >>> it only applies to our final release cuts, not our day-to-day just once for this project really; I wanted to insert such this switch >>> (if existed) in our "delivery build" profile we use archiva for everything else, and actually only make use of >> public maven repositories when we up a version of our dependencies, which is >>> rare because of change control it's all weird stuff, I know, but sometimes I just don't question it On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: >>> deleting the m2 works, I was just curious to see if there was a >>> switch > in >>> maven to force all downloads again >> >> This makes absolutely no sense, doesn't change your BOM, and is >> just >> wasteful. Consumes bandwidth unnecessarily from a resource that is being >> used by the whole Maven community. > > I'd think that if you had enough developers doing this on every > machine on a consistent basis (eg every build), it might add up to > enough traffic to get you on a blacklist somewhere... You really need > to install Nexus or another MRM, this is just plain dumb. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > >>> >> - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
You may want to take a look at the CI integration in Artifactory - http://wiki.jfrog.org/confluence/display/RTF/Build+Integration You can get a json object with a report of all this information captured at build time: detailed build environment information, published artifacts and resolved dependencies of all scopes. Like many have commented here, re-downloading cached release artifacts if you run your build from scratch should be done from the caches of your repo manager. Yoav On Sat, Jul 31, 2010 at 12:07 AM, Shan Syed wrote: > no, this isn't in regard to our own published artifacts > > I regret starting this thread, I apologize > I didn't mean this question to be an affront to maven conventions - I just > need to figure out a better way to capture a full log > they even want a log of how the build environment was downloaded and > installed > > > On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict > wrote: > > > There is a maxim to follow when deploying: "do not redeploy a version > more > > than once". Once you deploy version X.Y.Z, it should never be updated, > and > > those who download it never need to download it again. So, back to the > > original problem, are you guys doing that? > > > > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: > > > > > it only applies to our final release cuts, not our day-to-day > > > just once for this project really; I wanted to insert such this switch > > (if > > > existed) in our "delivery build" profile > > > we use archiva for everything else, and actually only make use of > public > > > maven repositories when we up a version of our dependencies, which is > > rare > > > because of change control > > > > > > it's all weird stuff, I know, but sometimes I just don't question it > > > > > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > > > > > > > >> deleting the m2 works, I was just curious to see if there was a > > switch > > > > in > > > > >> maven to force all downloads again > > > > > > > > > > This makes absolutely no sense, doesn't change your BOM, and is > just > > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is > > > being > > > > > used by the whole Maven community. > > > > > > > > I'd think that if you had enough developers doing this on every > > > > machine on a consistent basis (eg every build), it might add up to > > > > enough traffic to get you on a blacklist somewhere... You really need > > > > to install Nexus or another MRM, this is just plain dumb. > > > > > > > > Wayne > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > > >
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 1:00 PM, Haszlakiewicz, Eric wrote: >> -Original Message- >> From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] >> >> On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric >> wrote: -Original Message- >>> I don't (yet) know much about the internals of maven, but is it really >>> that much of an impact on the code? There's already support present for >>> checking for differences in snapshot versions, right? I'm imagining >>> that making it work for release artifacts would be a matter of not >>> distinguishing between release and snapshot artifacts and having the >>> check apply to both. >>> It sounds like you think it'll be harder to do than that; what I am >>> missing? >> >> What you are asking is absurd. That's the exact difference between >> snapshots and releases; snapshots should be updated and releases >> shouldn't. Why would you insist on removing this differentiation? >> Wouldn't it be easier for you to just use snapshots if you need to >> check for updates? > > Please read the rest of the email thread. The short summary is: > Yes, I know what *should* happen, but the world isn't perfect and release > artifacts DO sometimes change. It is not absurd to be able to detect and > recover from that kind of situation. Eric, you're not going to win this one. It's part of the philosophy of Maven. It's also good practice. Give it up. I'm not going to fight the site generation being split out of Maven. I think I understand Jason's point on that, though I disagree. And that's a *much* less nasty violation of Maven's perceived function, if in fact, it is a violation. What you're wanting is a violation. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Aug 6, 2010, at 12:57 PM, Kalle Korhonen wrote: > On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric > wrote: >>> -Original Message- >> I don't (yet) know much about the internals of maven, but is it really >> that much of an impact on the code? There's already support present for >> checking for differences in snapshot versions, right? I'm imagining >> that making it work for release artifacts would be a matter of not >> distinguishing between release and snapshot artifacts and having the >> check apply to both. >> It sounds like you think it'll be harder to do than that; what I am >> missing? > > What you are asking is absurd. That's the exact difference between > snapshots and releases; snapshots should be updated and releases > shouldn't. Why would you insist on removing this differentiation? > Wouldn't it be easier for you to just use snapshots if you need to > check for updates? What Katie (and others) said! I have my differences with the current Maven philosophy, but one thing that has been baked in from the beginning is that artifact coordinates imply a fixed thing. The artifact does not change. That's one of the *points* of Maven. -K - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>>-Original Message- >>From: Manfred Moser [mailto:manf...@mosabuam.com] >> >>It seems like we will not agree here. The changes necessary and the >>additional overhead to make your suggestions work have to much of a >>negative impact imho. I cant see your feature getting implemented by >>anybody. Your only option is to implement it yourself and see how you >>fare. If you do it as a plugin that does the check you want you might > get >>traction with other users. > > I don't (yet) know much about the internals of maven, but is it really > that much of an impact on the code? There's already support present for > checking for differences in snapshot versions, right? I'm imagining > that making it work for release artifacts would be a matter of not > distinguishing between release and snapshot artifacts and having the > check apply to both. > It sounds like you think it'll be harder to do than that; what I am > missing? It might be easy to he do but I have a feeling you will not be liked by the community. By doing this in your own plugin or forked codebase you will by merely running it put a large additional strain and the public and shared infrastructure like maven central and others. You will not get any good will and might end up getting blocked by central. I really suggest you drop this idea and adopt a proper process or move to a different tool. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric wrote: > Please read the rest of the email thread. The short summary is: > Yes, I know what *should* happen, but the world isn't perfect and release > artifacts DO sometimes change. It is not absurd to be able to detect and > recover from that kind of situation. > > The solution is to wipe out your local artifact. No one should be updating released artifacts. If they do, they abused what a release means -- hence the problem to begin with. The solution given is the only (correct) one in Maven. Paul
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Kalle Korhonen [mailto:kalle.o.korho...@gmail.com] > >On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric > wrote: >>>-Original Message- >> I don't (yet) know much about the internals of maven, but is it really >> that much of an impact on the code? There's already support present for >> checking for differences in snapshot versions, right? I'm imagining >> that making it work for release artifacts would be a matter of not >> distinguishing between release and snapshot artifacts and having the >> check apply to both. >> It sounds like you think it'll be harder to do than that; what I am >> missing? > >What you are asking is absurd. That's the exact difference between >snapshots and releases; snapshots should be updated and releases >shouldn't. Why would you insist on removing this differentiation? >Wouldn't it be easier for you to just use snapshots if you need to >check for updates? Please read the rest of the email thread. The short summary is: Yes, I know what *should* happen, but the world isn't perfect and release artifacts DO sometimes change. It is not absurd to be able to detect and recover from that kind of situation. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric wrote: >>-Original Message- > I don't (yet) know much about the internals of maven, but is it really > that much of an impact on the code? There's already support present for > checking for differences in snapshot versions, right? I'm imagining > that making it work for release artifacts would be a matter of not > distinguishing between release and snapshot artifacts and having the > check apply to both. > It sounds like you think it'll be harder to do than that; what I am > missing? What you are asking is absurd. That's the exact difference between snapshots and releases; snapshots should be updated and releases shouldn't. Why would you insist on removing this differentiation? Wouldn't it be easier for you to just use snapshots if you need to check for updates? Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Manfred Moser [mailto:manf...@mosabuam.com] > >It seems like we will not agree here. The changes necessary and the >additional overhead to make your suggestions work have to much of a >negative impact imho. I cant see your feature getting implemented by >anybody. Your only option is to implement it yourself and see how you >fare. If you do it as a plugin that does the check you want you might get >traction with other users. I don't (yet) know much about the internals of maven, but is it really that much of an impact on the code? There's already support present for checking for differences in snapshot versions, right? I'm imagining that making it work for release artifacts would be a matter of not distinguishing between release and snapshot artifacts and having the check apply to both. It sounds like you think it'll be harder to do than that; what I am missing? eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
> The network traffic that that would cause in a modern project with dozens of > dependencies would create a real nuisance. If every artifact had md5 and sha1 hashes etc, then the traffic would merely be to check the hashes against the local artifact... which Maven already does, and complains when things don't match. Note: I'm not encouraging this approach. Releases must never change, period, end of story. Push another release if you find a given release is broken. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 05/08/2010 1:13 PM, Manfred Moser wrote: Eric, It seems like we will not agree here. The changes necessary and the additional overhead to make your suggestions work have to much of a negative impact imho. I cant see your feature getting implemented by anybody. Your only option is to implement it yourself and see how you fare. If you do it as a plugin that does the check you want you might get traction with other users. However I cant see anybody from the core team working on this. If the problem is really so big for yourself then you can go and fix it. If fixing it is too much hazzle you will have to change your procedure. Your choice. The network traffic that that would cause in a modern project with dozens of dependencies would create a real nuisance. Ron Apart from that I think we can agree to disagree. manfred -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] On 04/08/2010 6:34 PM, Manfred Moser wrote: For everyone that says "Released artifacts MUST NOT CHANGE", that great if you live in an ideal world, but guess what: some of us actually have to live in the *real* world where things don't always follow the guidelines. It would be nice if maven didn't make it so hard to deal with those situations. Sorry.. but in this case I think the cost of accommodating for behaviours against the known best practice would far outweigh the benefits. I would not want to see such a feature available even for the pure cost people then using it. Just adapt your practice. +1. We are still suffering from a project that allowed released artifacts to change without creating a new release. Bad practices need to stopped not supported. Ron I'm sure I'm not the only person that is very disappointed at the lack of desire to help people get things working. It's one thing to encourage people to do things the right way, but I think it's stupid to actively put obstacles in the path of people trying to deal with environments that aren't perfect. If you see a blind man walking into traffic do you help him step off the curb? Yes, actually I would. At the same time I would mention that it might be better for him to use the crosswalk. I certainly wouldn't take away his cane so he can't even tell the curb is there until he trips over it. You can stop people from changing released artifacts. Get them to use SNAPSHOTs until they really have tested the release and got the OK to issue a release. If people are not testing their SNAPSHOTs before releasing them, you need to stop this. No, actually you can't. It is absolutely impossible to ensure that a release artifact will never change. You certainly can (and should) do a lot to discourage that from happening, and you can do a lot to make it difficult to cause it to happen, but once it does happen you shouldn't continue to make things difficult for people to notice that something is wrong and to fix it. Do you really think it's better to not have any way to recover from the case when a project changes release artifacts? The repository manager can delete a release which does allow you to rerelease the save version. When this is done, each programmer has to manually remove the bad version from their local cache to ensure that Maven gets the rereleased artifact. This should only be done once in a blue moon not as part of regular operation. And if this happens, maven should tell you about it! I think it would be nice it there was an easy way to tell maven to remove the bad version from the local cache, but the bare minimum it should do is spit out an error like: [ERROR] release artifact com.example:foo in the local cache does not match repository version (http://central/com/example/foo) [ERROR] to use the repository version, remove the files at ~/.m2/repository/com/example/foo As you say, you're still suffering from it. Perhaps that's exactly because maven doesn't provide you the tools to effectively deal with it! I am suffering because it is hard to tell which release 2.1.3 is the "good" version with the patches. So why wouldn't you want to know that there are two different copies of that release? I don't understand why there is such resistance to providing the tools to effectively deal with problematic situations. IMO, maven should, at the very least, be able to indicate an error when things are inconsistent, even for release artifacts. The current behaviour, where you have absolutely NO CLUE what's going on if an artifact changes, leads to huge amounts of confusion. That is not a Maven problem it is a people problem. That is why you don't let artifacts change. I don't know what world you live in, but in mine I don't have absolute control over everything. eric - To unsubscribe,
Re: force maven to redownload/refresh "released" dependencies
On 05/08/2010 1:00 PM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] On 04/08/2010 6:34 PM, Manfred Moser wrote: For everyone that says "Released artifacts MUST NOT CHANGE", that great if you live in an ideal world, but guess what: some of us actually have to live in the *real* world where things don't always follow the guidelines. It would be nice if maven didn't make it so hard to deal with those situations. Sorry.. but in this case I think the cost of accommodating for behaviours against the known best practice would far outweigh the benefits. I would not want to see such a feature available even for the pure cost people then using it. Just adapt your practice. +1. We are still suffering from a project that allowed released artifacts to change without creating a new release. Bad practices need to stopped not supported. Ron I'm sure I'm not the only person that is very disappointed at the lack of desire to help people get things working. It's one thing to encourage people to do things the right way, but I think it's stupid to actively put obstacles in the path of people trying to deal with environments that aren't perfect. If you see a blind man walking into traffic do you help him step off the curb? Yes, actually I would. At the same time I would mention that it might be better for him to use the crosswalk. I certainly wouldn't take away his cane so he can't even tell the curb is there until he trips over it. You can stop people from changing released artifacts. Get them to use SNAPSHOTs until they really have tested the release and got the OK to issue a release. If people are not testing their SNAPSHOTs before releasing them, you need to stop this. No, actually you can't. It is absolutely impossible to ensure that a release artifact will never change. You certainly can (and should) do a lot to discourage that from happening, and you can do a lot to make it difficult to cause it to happen, but once it does happen you shouldn't continue to make things difficult for people to notice that something is wrong and to fix it. Do you really think it's better to not have any way to recover from the case when a project changes release artifacts? The repository manager can delete a release which does allow you to rerelease the save version. When this is done, each programmer has to manually remove the bad version from their local cache to ensure that Maven gets the rereleased artifact. This should only be done once in a blue moon not as part of regular operation. And if this happens, maven should tell you about it! I think it would be nice it there was an easy way to tell maven to remove the bad version from the local cache, but the bare minimum it should do is spit out an error like: [ERROR] release artifact com.example:foo in the local cache does not match repository version (http://central/com/example/foo) [ERROR] to use the repository version, remove the files at ~/.m2/repository/com/example/foo No way! I do not want that kind of traffic going through my repo and network. Checking SNAPSHOTs is enough of a load. Checking almost 100 released artifacts to do a build would bring things to a halt. Is the user has release 2.1.2 in his local cache and his build calls for release 2.1.2, that is it. Use it, don't be wandering over the internet to my repo site "just checking" to see if someone screwed with 2.1.2. If you have to fix 2.1.2 then issue a 2.1.2.1 if you can not stand 2.1.3. As you say, you're still suffering from it. Perhaps that's exactly because maven doesn't provide you the tools to effectively deal with it! I am suffering because it is hard to tell which release 2.1.3 is the "good" version with the patches. So why wouldn't you want to know that there are two different copies of that release? I don't understand why there is such resistance to providing the tools to effectively deal with problematic situations. IMO, maven should, at the very least, be able to indicate an error when things are inconsistent, even for release artifacts. The current behaviour, where you have absolutely NO CLUE what's going on if an artifact changes, leads to huge amounts of confusion. That is not a Maven problem it is a people problem. That is why you don't let artifacts change. I don't know what world you live in, but in mine I don't have absolute control over everything. I do. You need to bring this problem to the attention of someone who does have control and make sure that they understand the problem caused by not QCing releases and expecting to rerelease until they have it right. You can tell him/her that it is a Maven "problem" but don't quote anyone here as regarding that as a problem. You can also describe in detail, by now, the difficul
RE: force maven to redownload/refresh "released" dependencies
Eric, It seems like we will not agree here. The changes necessary and the additional overhead to make your suggestions work have to much of a negative impact imho. I cant see your feature getting implemented by anybody. Your only option is to implement it yourself and see how you fare. If you do it as a plugin that does the check you want you might get traction with other users. However I cant see anybody from the core team working on this. If the problem is really so big for yourself then you can go and fix it. If fixing it is too much hazzle you will have to change your procedure. Your choice. Apart from that I think we can agree to disagree. manfred >>-Original Message- >>From: Ron Wheeler [mailto:rwhee...@artifact-software.com] >> >> On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] On 04/08/2010 6:34 PM, Manfred Moser wrote: >> For everyone that says "Released artifacts MUST NOT CHANGE", that >>> great >> if you live in an ideal world, but guess what: some of us actually >>> have >> to live in the *real* world where things don't always follow the >> guidelines. It would be nice if maven didn't make it so hard to >>> deal >> with those situations. > Sorry.. but in this case I think the cost of accommodating for >>> behaviours > against the known best practice would far outweigh the benefits. I >>> would > not want to see such a feature available even for the pure cost >>> people > then using it. Just adapt your practice. > +1. We are still suffering from a project that allowed released > artifacts >>> to change without creating a new release. Bad practices need to stopped not supported. Ron >>> I'm sure I'm not the only person that is very disappointed at the > lack >>> of desire to help people get things working. It's one thing to >>> encourage people to do things the right way, but I think it's stupid > to >>> actively put obstacles in the path of people trying to deal with >>> environments that aren't perfect. >>If you see a blind man walking into traffic do you help him step off > the >>curb? > > Yes, actually I would. At the same time I would mention that it might > be better for him to use the crosswalk. I certainly wouldn't take away > his cane so he can't even tell the curb is there until he trips over it. > >>You can stop people from changing released artifacts. >>Get them to use SNAPSHOTs until they really have tested the release > and >>got the OK to issue a release. >>If people are not testing their SNAPSHOTs before releasing them, you >>need to stop this. > > No, actually you can't. It is absolutely impossible to ensure that a > release artifact will never change. > You certainly can (and should) do a lot to discourage that from > happening, and you can do a lot to make it difficult to cause it to > happen, but once it does happen you shouldn't continue to make things > difficult for people to notice that something is wrong and to fix it. > >>> Do you really think it's better to not have any way to recover from > the >>> case when a project changes release artifacts? >>The repository manager can delete a release which does allow you to >>rerelease the save version. >>When this is done, each programmer has to manually remove the bad >>version from their local cache to ensure that Maven gets the rereleased >>artifact. >>This should only be done once in a blue moon not as part of regular >>operation. > > And if this happens, maven should tell you about it! I think it would > be nice it there was an easy way to tell maven to remove the bad version > from the local cache, but the bare minimum it should do is spit out an > error like: > [ERROR] release artifact com.example:foo in the local cache does not > match repository version (http://central/com/example/foo) > [ERROR] to use the repository version, remove the files at > ~/.m2/repository/com/example/foo > >>> As you say, you're still >>> suffering from it. Perhaps that's exactly because maven doesn't > provide >>> you the tools to effectively deal with it! >>I am suffering because it is hard to tell which release 2.1.3 is the >>"good" version with the patches. > > So why wouldn't you want to know that there are two different copies of > that release? I don't understand why there is such resistance to > providing the tools to effectively deal with problematic situations. > >>> IMO, maven should, at the very least, be able to indicate an error > when >>> things are inconsistent, even for release artifacts. The current >>> behaviour, where you have absolutely NO CLUE what's going on if an >>> artifact changes, leads to huge amounts of confusion. >>That is not a Maven problem it is a people problem. >>That is why you don't let artifacts change. > > I don't know what world you live in, but in mine I don't have absolute > control over everything. >
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > > On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote: >>> -Original Message- >>> From: Ron Wheeler [mailto:rwhee...@artifact-software.com] >>> >>> On 04/08/2010 6:34 PM, Manfred Moser wrote: > For everyone that says "Released artifacts MUST NOT CHANGE", that >> great > if you live in an ideal world, but guess what: some of us actually >> have > to live in the *real* world where things don't always follow the > guidelines. It would be nice if maven didn't make it so hard to >> deal > with those situations. Sorry.. but in this case I think the cost of accommodating for >> behaviours against the known best practice would far outweigh the benefits. I >> would not want to see such a feature available even for the pure cost >> people then using it. Just adapt your practice. >>> +1. >>> We are still suffering from a project that allowed released artifacts >> to >>> change without creating a new release. >>> Bad practices need to stopped not supported. >>> >>> Ron >> I'm sure I'm not the only person that is very disappointed at the lack >> of desire to help people get things working. It's one thing to >> encourage people to do things the right way, but I think it's stupid to >> actively put obstacles in the path of people trying to deal with >> environments that aren't perfect. >If you see a blind man walking into traffic do you help him step off the >curb? Yes, actually I would. At the same time I would mention that it might be better for him to use the crosswalk. I certainly wouldn't take away his cane so he can't even tell the curb is there until he trips over it. >You can stop people from changing released artifacts. >Get them to use SNAPSHOTs until they really have tested the release and >got the OK to issue a release. >If people are not testing their SNAPSHOTs before releasing them, you >need to stop this. No, actually you can't. It is absolutely impossible to ensure that a release artifact will never change. You certainly can (and should) do a lot to discourage that from happening, and you can do a lot to make it difficult to cause it to happen, but once it does happen you shouldn't continue to make things difficult for people to notice that something is wrong and to fix it. >> Do you really think it's better to not have any way to recover from the >> case when a project changes release artifacts? >The repository manager can delete a release which does allow you to >rerelease the save version. >When this is done, each programmer has to manually remove the bad >version from their local cache to ensure that Maven gets the rereleased >artifact. >This should only be done once in a blue moon not as part of regular >operation. And if this happens, maven should tell you about it! I think it would be nice it there was an easy way to tell maven to remove the bad version from the local cache, but the bare minimum it should do is spit out an error like: [ERROR] release artifact com.example:foo in the local cache does not match repository version (http://central/com/example/foo) [ERROR] to use the repository version, remove the files at ~/.m2/repository/com/example/foo >> As you say, you're still >> suffering from it. Perhaps that's exactly because maven doesn't provide >> you the tools to effectively deal with it! >I am suffering because it is hard to tell which release 2.1.3 is the >"good" version with the patches. So why wouldn't you want to know that there are two different copies of that release? I don't understand why there is such resistance to providing the tools to effectively deal with problematic situations. >> IMO, maven should, at the very least, be able to indicate an error when >> things are inconsistent, even for release artifacts. The current >> behaviour, where you have absolutely NO CLUE what's going on if an >> artifact changes, leads to huge amounts of confusion. >That is not a Maven problem it is a people problem. >That is why you don't let artifacts change. I don't know what world you live in, but in mine I don't have absolute control over everything. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 05/08/2010 11:00 AM, Haszlakiewicz, Eric wrote: -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] On 04/08/2010 6:34 PM, Manfred Moser wrote: For everyone that says "Released artifacts MUST NOT CHANGE", that great if you live in an ideal world, but guess what: some of us actually have to live in the *real* world where things don't always follow the guidelines. It would be nice if maven didn't make it so hard to deal with those situations. Sorry.. but in this case I think the cost of accommodating for behaviours against the known best practice would far outweigh the benefits. I would not want to see such a feature available even for the pure cost people then using it. Just adapt your practice. +1. We are still suffering from a project that allowed released artifacts to change without creating a new release. Bad practices need to stopped not supported. Ron I'm sure I'm not the only person that is very disappointed at the lack of desire to help people get things working. It's one thing to encourage people to do things the right way, but I think it's stupid to actively put obstacles in the path of people trying to deal with environments that aren't perfect. If you see a blind man walking into traffic do you help him step off the curb? You can stop people from changing released artifacts. Get them to use SNAPSHOTs until they really have tested the release and got the OK to issue a release. If people are not testing their SNAPSHOTs before releasing them, you need to stop this. Do you really think it's better to not have any way to recover from the case when a project changes release artifacts? The repository manager can delete a release which does allow you to rerelease the save version. When this is done, each programmer has to manually remove the bad version from their local cache to ensure that Maven gets the rereleased artifact. This should only be done once in a blue moon not as part of regular operation. As you say, you're still suffering from it. Perhaps that's exactly because maven doesn't provide you the tools to effectively deal with it! I am suffering because it is hard to tell which release 2.1.3 is the "good" version with the patches. IMO, maven should, at the very least, be able to indicate an error when things are inconsistent, even for release artifacts. The current behaviour, where you have absolutely NO CLUE what's going on if an artifact changes, leads to huge amounts of confusion. That is not a Maven problem it is a people problem. That is why you don't let artifacts change. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: Ron Wheeler [mailto:rwhee...@artifact-software.com] > > On 04/08/2010 6:34 PM, Manfred Moser wrote: >>> For everyone that says "Released artifacts MUST NOT CHANGE", that great >>> if you live in an ideal world, but guess what: some of us actually have >>> to live in the *real* world where things don't always follow the >>> guidelines. It would be nice if maven didn't make it so hard to deal >>> with those situations. >> Sorry.. but in this case I think the cost of accommodating for behaviours >> against the known best practice would far outweigh the benefits. I would >> not want to see such a feature available even for the pure cost people >> then using it. Just adapt your practice. >> >+1. >We are still suffering from a project that allowed released artifacts to >change without creating a new release. >Bad practices need to stopped not supported. > >Ron I'm sure I'm not the only person that is very disappointed at the lack of desire to help people get things working. It's one thing to encourage people to do things the right way, but I think it's stupid to actively put obstacles in the path of people trying to deal with environments that aren't perfect. Do you really think it's better to not have any way to recover from the case when a project changes release artifacts? As you say, you're still suffering from it. Perhaps that's exactly because maven doesn't provide you the tools to effectively deal with it! IMO, maven should, at the very least, be able to indicate an error when things are inconsistent, even for release artifacts. The current behaviour, where you have absolutely NO CLUE what's going on if an artifact changes, leads to huge amounts of confusion. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 04/08/2010 6:34 PM, Manfred Moser wrote: For everyone that says "Released artifacts MUST NOT CHANGE", that great if you live in an ideal world, but guess what: some of us actually have to live in the *real* world where things don't always follow the guidelines. It would be nice if maven didn't make it so hard to deal with those situations. Sorry.. but in this case I think the cost of accommodating for behaviours against the known best practice would far outweigh the benefits. I would not want to see such a feature available even for the pure cost people then using it. Just adapt your practice. +1. We are still suffering from a project that allowed released artifacts to change without creating a new release. Bad practices need to stopped not supported. Ron 1. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
> For everyone that says "Released artifacts MUST NOT CHANGE", that great > if you live in an ideal world, but guess what: some of us actually have > to live in the *real* world where things don't always follow the > guidelines. It would be nice if maven didn't make it so hard to deal > with those situations. Sorry.. but in this case I think the cost of accommodating for behaviours against the known best practice would far outweigh the benefits. I would not want to see such a feature available even for the pure cost people then using it. Just adapt your practice. manfred - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: force maven to redownload/refresh "released" dependencies
>-Original Message- >From: a.geo [mailto:aquiles@gmail.com] >Sent: Monday, August 02, 2010 9:54 AM >To: Maven Users List >Subject: Re: force maven to redownload/refresh "released" dependencies > >mvn package -U > >maybe? > >the -U parameter tell to maven to refresh all dependencies required by the >artifact I tried that, but it only works for snapshots. (as is implied by the long version of that: --update-snapshots). There really should be a way to get maven to force a check on all dependencies. For everyone that says "Released artifacts MUST NOT CHANGE", that great if you live in an ideal world, but guess what: some of us actually have to live in the *real* world where things don't always follow the guidelines. It would be nice if maven didn't make it so hard to deal with those situations. eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 02/08/2010 11:00 AM, Nicola Musatti wrote: Shan Syed wrote: ok, thanks basically for liability reasons for a certain project, we have to provide specific times of when a project was built and when/where all its dependencies were retrieved at/from we have to ensure a sanitary build for all these JARs and a complete log of going from 0 to 100 for the build; so we are faced with either clearing out the .m2 each time I was wondering if there was a way to force this through maven I'd say there are two sides to your problem: one is how to control when third-party artifacts are downloaded from remote repositories and the other is to control when and from which sources your own artifacts are built. One way to tackle the first problem is to use a repository manager like nexus, but not its proxying capabilities. Instead third party artifacts could be added to a specific repository by hand. Using a repository is always a good idea. In practical terms, I am not sure if the source of the download is all that important in most cases since the come from Maven Central most of the time and you can not easily tell the client who actually put the jar file in Maven Central or even what company the person worked for. This may be a case where the client started out with a good idea (control who is building components that the "prime" contractor is using but as Maven gets more popular, Maven Central becomes an easy place to get things even if it is not the home of the author. The idea of setting up Nexus (or some other proxy) and only using the manual upload to feed it, will go a long way to giving the client a comfortable feeling that you do know where and when you got your components. You would not have to worry about individual .m2 contents since the downloads would all be distributed centrally from your repo. This would speed up the builds tremendously. For the second problem you could use a specifically tailored aggregate project that included all of the jars you need to build, so that none would be retrieved from repositories. If you are using Subversion for version control you could use svn:externals to automatically check out of your projects. We do this with our third party libraries and it ensures that developers build with the "right" version which is more important than the client knowing, in our case. We do have a set of versioned POM files that can be provided to anyone who wants to know what libraries (and their versions) were used to build any particular version of our application. We do not change the version of third-party software in the POMs within a version of our software so builds within a release are all built with the same set of dependencies. If we did need to change the version of a third-party package, that would trigger a new minor version of out application. We do not track the actual download from Maven Central or our manual uploads for artifacts not in Maven Central. That is only done once per artifact version. I am not sure if Nexus could report this activity if we did want to track it. There might be logs available. Once you stop individuals from accessing the dependencies directly without controls, it gets much easier to track dependencies to the level that your client wants. It also makes the POM of our artifacts very small since they only depend on a few aggregate projects. Cheers, Nicola Musatti - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Shan Syed wrote: no, this isn't in regard to our own published artifacts I regret starting this thread, I apologize I didn't mean this question to be an affront to maven conventions - I just need to figure out a better way to capture a full log they even want a log of how the build environment was downloaded and installed In my opinion you have nothing to apologize for. Your problem is just an example of how Maven's artifact-centric view is at least partly in contrast with the source centric view of "orthodox" configuration management. While in general I do appreciate Maven's strongly opinionated approach, as it helps ensure that little time is wasted making the same decisions over and over again, I believe that better support for a source centric approach would be a good thing. A first step in this direction could be to provide an explicit, official representation for artifact variants obtained by building different tags/branches of a same project. Cheers, Nicola Musatti - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Shan Syed wrote: ok, thanks basically for liability reasons for a certain project, we have to provide specific times of when a project was built and when/where all its dependencies were retrieved at/from we have to ensure a sanitary build for all these JARs and a complete log of going from 0 to 100 for the build; so we are faced with either clearing out the .m2 each time I was wondering if there was a way to force this through maven I'd say there are two sides to your problem: one is how to control when third-party artifacts are downloaded from remote repositories and the other is to control when and from which sources your own artifacts are built. One way to tackle the first problem is to use a repository manager like nexus, but not its proxying capabilities. Instead third party artifacts could be added to a specific repository by hand. For the second problem you could use a specifically tailored aggregate project that included all of the jars you need to build, so that none would be retrieved from repositories. If you are using Subversion for version control you could use svn:externals to automatically check out of your projects. Cheers, Nicola Musatti - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
mvn package -U maybe? the -U parameter tell to maven to refresh all dependencies required by the artifact 2010/8/2 Arnaud Héritier > I see only one case where it could be useful, it is when we use staging > repositories and have to update our released binaries. > It is a shame to have to manually remove binaries previously downloaded > (and it is error prone). > I agree that never updating released binaries is a maven fundamental and > we'll never change that. > But we'll have to improve tooling around staging to easily allow to cleanup > the local repository (or a part of it) for QA teams and others involved in > staging process. > Cheers, > > Arnaud > > > On Jul 30, 2010, at 6:39 PM, Jason van Zyl wrote: > > > Maven won't do that, and we would never make that possible. If you > require this you have something seriously wrong with your project > infrastructure. Seriously bad project infrastructure smell. > > > > On Jul 30, 2010, at 12:01 PM, Shan Syed wrote: > > > >> is there a way to force a project to refresh certain dependencies every > >> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > >> > >> S > > > > Thanks, > > > > Jason > > > > -- > > Jason van Zyl > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > - > > > > > > > > > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > -- Cesar De la Cruz Rojas * - * Sennior Software Engineer - Follow me in Facebook : http://www.facebook.com/aquiles.geo Twitter http://twitter.com/ageo Picture blog http://ageo.deviantart.com
Re: force maven to redownload/refresh "released" dependencies
I see only one case where it could be useful, it is when we use staging repositories and have to update our released binaries. It is a shame to have to manually remove binaries previously downloaded (and it is error prone). I agree that never updating released binaries is a maven fundamental and we'll never change that. But we'll have to improve tooling around staging to easily allow to cleanup the local repository (or a part of it) for QA teams and others involved in staging process. Cheers, Arnaud On Jul 30, 2010, at 6:39 PM, Jason van Zyl wrote: > Maven won't do that, and we would never make that possible. If you require > this you have something seriously wrong with your project infrastructure. > Seriously bad project infrastructure smell. > > On Jul 30, 2010, at 12:01 PM, Shan Syed wrote: > >> is there a way to force a project to refresh certain dependencies every >> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >> >> S > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On 30/07/2010 5:09 PM, Paul Benedict wrote: You can use -X for a debug log. Or you can funnel system out to a file. I believe tools like Continuum or Hudson do such things. Paul On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed wrote: no, this isn't in regard to our own published artifacts I regret starting this thread, I apologize Don 't be sorry. You are getting really good advice from some very knowledgeable people who just want to help you. You are not doing things in a way that make it easy for you to satisfy your client and your life is much harder than it needs to be. No need to apologize. That is what the forum is for. Take a close look at what is being proposed and ask the questions that you need to have answered. Everyone has clients to satisfy and sometimes they don't ask for what they really need in the most direct way but you can give them what they need to do their job in a better way than your current approach and you will have a lot less work to do as well. Ron I didn't mean this question to be an affront to maven conventions - I just need to figure out a better way to capture a full log they even want a log of how the build environment was downloaded and installed On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict wrote: There is a maxim to follow when deploying: "do not redeploy a version more than once". Once you deploy version X.Y.Z, it should never be updated, and those who download it never need to download it again. So, back to the original problem, are you guys doing that? On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: it only applies to our final release cuts, not our day-to-day just once for this project really; I wanted to insert such this switch (if existed) in our "delivery build" profile we use archiva for everything else, and actually only make use of public maven repositories when we up a version of our dependencies, which is rare because of change control it's all weird stuff, I know, but sometimes I just don't question it On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: deleting the m2 works, I was just curious to see if there was a switch in maven to force all downloads again This makes absolutely no sense, doesn't change your BOM, and is just wasteful. Consumes bandwidth unnecessarily from a resource that is being used by the whole Maven community. I'd think that if you had enough developers doing this on every machine on a consistent basis (eg every build), it might add up to enough traffic to get you on a blacklist somewhere... You really need to install Nexus or another MRM, this is just plain dumb. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
You can use -X for a debug log. Or you can funnel system out to a file. I believe tools like Continuum or Hudson do such things. Paul On Fri, Jul 30, 2010 at 4:07 PM, Shan Syed wrote: > no, this isn't in regard to our own published artifacts > > I regret starting this thread, I apologize > I didn't mean this question to be an affront to maven conventions - I just > need to figure out a better way to capture a full log > they even want a log of how the build environment was downloaded and > installed > > > On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict > wrote: > > > There is a maxim to follow when deploying: "do not redeploy a version > more > > than once". Once you deploy version X.Y.Z, it should never be updated, > and > > those who download it never need to download it again. So, back to the > > original problem, are you guys doing that? > > > > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: > > > > > it only applies to our final release cuts, not our day-to-day > > > just once for this project really; I wanted to insert such this switch > > (if > > > existed) in our "delivery build" profile > > > we use archiva for everything else, and actually only make use of > public > > > maven repositories when we up a version of our dependencies, which is > > rare > > > because of change control > > > > > > it's all weird stuff, I know, but sometimes I just don't question it > > > > > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > > > > > > > >> deleting the m2 works, I was just curious to see if there was a > > switch > > > > in > > > > >> maven to force all downloads again > > > > > > > > > > This makes absolutely no sense, doesn't change your BOM, and is > just > > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is > > > being > > > > > used by the whole Maven community. > > > > > > > > I'd think that if you had enough developers doing this on every > > > > machine on a consistent basis (eg every build), it might add up to > > > > enough traffic to get you on a blacklist somewhere... You really need > > > > to install Nexus or another MRM, this is just plain dumb. > > > > > > > > Wayne > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > > > > > > >
Re: force maven to redownload/refresh "released" dependencies
no, this isn't in regard to our own published artifacts I regret starting this thread, I apologize I didn't mean this question to be an affront to maven conventions - I just need to figure out a better way to capture a full log they even want a log of how the build environment was downloaded and installed On Fri, Jul 30, 2010 at 5:04 PM, Paul Benedict wrote: > There is a maxim to follow when deploying: "do not redeploy a version more > than once". Once you deploy version X.Y.Z, it should never be updated, and > those who download it never need to download it again. So, back to the > original problem, are you guys doing that? > > On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: > > > it only applies to our final release cuts, not our day-to-day > > just once for this project really; I wanted to insert such this switch > (if > > existed) in our "delivery build" profile > > we use archiva for everything else, and actually only make use of public > > maven repositories when we up a version of our dependencies, which is > rare > > because of change control > > > > it's all weird stuff, I know, but sometimes I just don't question it > > > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > > > > > >> deleting the m2 works, I was just curious to see if there was a > switch > > > in > > > >> maven to force all downloads again > > > > > > > > This makes absolutely no sense, doesn't change your BOM, and is just > > > > wasteful. Consumes bandwidth unnecessarily from a resource that is > > being > > > > used by the whole Maven community. > > > > > > I'd think that if you had enough developers doing this on every > > > machine on a consistent basis (eg every build), it might add up to > > > enough traffic to get you on a blacklist somewhere... You really need > > > to install Nexus or another MRM, this is just plain dumb. > > > > > > Wayne > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > > For additional commands, e-mail: users-h...@maven.apache.org > > > > > > > > >
Re: force maven to redownload/refresh "released" dependencies
There is a maxim to follow when deploying: "do not redeploy a version more than once". Once you deploy version X.Y.Z, it should never be updated, and those who download it never need to download it again. So, back to the original problem, are you guys doing that? On Fri, Jul 30, 2010 at 3:57 PM, Shan Syed wrote: > it only applies to our final release cuts, not our day-to-day > just once for this project really; I wanted to insert such this switch (if > existed) in our "delivery build" profile > we use archiva for everything else, and actually only make use of public > maven repositories when we up a version of our dependencies, which is rare > because of change control > > it's all weird stuff, I know, but sometimes I just don't question it > > On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > > > >> deleting the m2 works, I was just curious to see if there was a switch > > in > > >> maven to force all downloads again > > > > > > This makes absolutely no sense, doesn't change your BOM, and is just > > > wasteful. Consumes bandwidth unnecessarily from a resource that is > being > > > used by the whole Maven community. > > > > I'd think that if you had enough developers doing this on every > > machine on a consistent basis (eg every build), it might add up to > > enough traffic to get you on a blacklist somewhere... You really need > > to install Nexus or another MRM, this is just plain dumb. > > > > Wayne > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: force maven to redownload/refresh "released" dependencies
it only applies to our final release cuts, not our day-to-day just once for this project really; I wanted to insert such this switch (if existed) in our "delivery build" profile we use archiva for everything else, and actually only make use of public maven repositories when we up a version of our dependencies, which is rare because of change control it's all weird stuff, I know, but sometimes I just don't question it On Fri, Jul 30, 2010 at 4:51 PM, Wayne Fay wrote: > >> deleting the m2 works, I was just curious to see if there was a switch > in > >> maven to force all downloads again > > > > This makes absolutely no sense, doesn't change your BOM, and is just > > wasteful. Consumes bandwidth unnecessarily from a resource that is being > > used by the whole Maven community. > > I'd think that if you had enough developers doing this on every > machine on a consistent basis (eg every build), it might add up to > enough traffic to get you on a blacklist somewhere... You really need > to install Nexus or another MRM, this is just plain dumb. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: force maven to redownload/refresh "released" dependencies
>> deleting the m2 works, I was just curious to see if there was a switch in >> maven to force all downloads again > > This makes absolutely no sense, doesn't change your BOM, and is just > wasteful. Consumes bandwidth unnecessarily from a resource that is being > used by the whole Maven community. I'd think that if you had enough developers doing this on every machine on a consistent basis (eg every build), it might add up to enough traffic to get you on a blacklist somewhere... You really need to install Nexus or another MRM, this is just plain dumb. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
On Jul 30, 2010, at 3:45 PM, Shan Syed wrote: > not my organization - our client wants a log of everything that came down > the pipe to create this build, that's all > it's not a matter of "worry" or "concern", so no need to be overly dramatic > some companies just want a complete audit trail of what they paid for, which > is fine by me > I'm looking for technical solutions because I'm in a technical role, not > policy advice; sometimes in this business you delivery what you're paid to > deliver regardless of whether it makes sense to you > we cannot respond to our clients saying "the guys on the maven list told us > that your request is stupid" Sounds like you're being paid to deliver an accurate bill of materials (BOM) which is perfectly reasonable. Not download things over and over again which frankly isn't very sensible. In that the BOM, containing released artifacts, will not be different whether you download 1 or 100 times. You'll have "what came down the pipe." And that you might want to explain this to your client that the BOM is not any more accurate if they are, in fact, asking you to explicitly download the released artifacts on each build. > > deleting the m2 works, I was just curious to see if there was a switch in > maven to force all downloads again This makes absolutely no sense, doesn't change your BOM, and is just wasteful. Consumes bandwidth unnecessarily from a resource that is being used by the whole Maven community. > > On Fri, Jul 30, 2010 at 2:47 PM, Jason van Zyl wrote: > >> >> On Jul 30, 2010, at 2:21 PM, Shan Syed wrote: >> >>> ok, thanks >>> basically for liability reasons for a certain project, we have to provide >>> specific times of when a project was built and when/where all its >>> dependencies were retrieved at/from >>> we have to ensure a sanitary build for all these JARs and a complete log >> of >>> going from 0 to 100 for the build; so we are faced with either clearing >> out >>> the .m2 each time >>> I was wondering if there was a way to force this through maven >>> >> >> Put the artifacts in a repository manager where you download the released >> artifact once and then manage it from your infrastructure. Once the artifact >> is within your infrastructure the released artifact is not going to change >> unless someone from within your organization changes it. They shouldn't, and >> can't if your permissions are setup correctly, and so the requirement of >> using the same artifacts and their origin becomes moot. If your organization >> cares that much about liability concerns then you absolutely should not be >> connecting to the outside world every time you build. >> >>> On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis >>> wrote: >>> On 07/30/2010 07:16 PM, Wayne Fay wrote: > is there a way to force a project to refresh certain dependencies every >> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >> > > Absolutely not. Released artifacts MUST NOT CHANGE. > +1, never ever ;-) Released artifact versioning is supposed to guarantee consistency. Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org >> >> Thanks, >> >> Jason >> >> -- >> Jason van Zyl >> Founder, Apache Maven >> http://twitter.com/jvanzyl >> - >> >> believe nothing, no matter where you read it, >> or who has said it, >> not even if i have said it, >> unless it agrees with your own reason >> and your own common sense. >> >> -- Buddha >> >> >> >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - What matters is not ideas, but the people who have them. Good people can fix bad ideas, but good ideas can't save bad people. -- Paul Graham
Re: force maven to redownload/refresh "released" dependencies
not my organization - our client wants a log of everything that came down the pipe to create this build, that's all it's not a matter of "worry" or "concern", so no need to be overly dramatic some companies just want a complete audit trail of what they paid for, which is fine by me I'm looking for technical solutions because I'm in a technical role, not policy advice; sometimes in this business you delivery what you're paid to deliver regardless of whether it makes sense to you we cannot respond to our clients saying "the guys on the maven list told us that your request is stupid" deleting the m2 works, I was just curious to see if there was a switch in maven to force all downloads again On Fri, Jul 30, 2010 at 2:47 PM, Jason van Zyl wrote: > > On Jul 30, 2010, at 2:21 PM, Shan Syed wrote: > > > ok, thanks > > basically for liability reasons for a certain project, we have to provide > > specific times of when a project was built and when/where all its > > dependencies were retrieved at/from > > we have to ensure a sanitary build for all these JARs and a complete log > of > > going from 0 to 100 for the build; so we are faced with either clearing > out > > the .m2 each time > > I was wondering if there was a way to force this through maven > > > > Put the artifacts in a repository manager where you download the released > artifact once and then manage it from your infrastructure. Once the artifact > is within your infrastructure the released artifact is not going to change > unless someone from within your organization changes it. They shouldn't, and > can't if your permissions are setup correctly, and so the requirement of > using the same artifacts and their origin becomes moot. If your organization > cares that much about liability concerns then you absolutely should not be > connecting to the outside world every time you build. > > > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis > > wrote: > > > >> On 07/30/2010 07:16 PM, Wayne Fay wrote: > >> > >>> is there a way to force a project to refresh certain dependencies every > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > > >>> > >>> Absolutely not. Released artifacts MUST NOT CHANGE. > >>> > >> > >> +1, never ever ;-) > >> > >> Released artifact versioning is supposed to guarantee consistency. > >> > >> Manos > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > >> For additional commands, e-mail: users-h...@maven.apache.org > >> > >> > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > believe nothing, no matter where you read it, > or who has said it, > not even if i have said it, > unless it agrees with your own reason > and your own common sense. > > -- Buddha > > > >
RE: force maven to redownload/refresh "released" dependencies
You could try changing the repository location property on the command line to a fresh empty directory. That will force the download and logging of all SNAPSHOT and release dependencies. >mvn ... -Dmaven.repo.local= To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: force maven to redownload/refresh "released" dependencies
On Jul 30, 2010, at 2:21 PM, Shan Syed wrote: > ok, thanks > basically for liability reasons for a certain project, we have to provide > specific times of when a project was built and when/where all its > dependencies were retrieved at/from > we have to ensure a sanitary build for all these JARs and a complete log of > going from 0 to 100 for the build; so we are faced with either clearing out > the .m2 each time > I was wondering if there was a way to force this through maven > Put the artifacts in a repository manager where you download the released artifact once and then manage it from your infrastructure. Once the artifact is within your infrastructure the released artifact is not going to change unless someone from within your organization changes it. They shouldn't, and can't if your permissions are setup correctly, and so the requirement of using the same artifacts and their origin becomes moot. If your organization cares that much about liability concerns then you absolutely should not be connecting to the outside world every time you build. > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis > wrote: > >> On 07/30/2010 07:16 PM, Wayne Fay wrote: >> >>> is there a way to force a project to refresh certain dependencies every build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >>> >>> Absolutely not. Released artifacts MUST NOT CHANGE. >>> >> >> +1, never ever ;-) >> >> Released artifact versioning is supposed to guarantee consistency. >> >> Manos >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - believe nothing, no matter where you read it, or who has said it, not even if i have said it, unless it agrees with your own reason and your own common sense. -- Buddha
Re: force maven to redownload/refresh "released" dependencies
Wouldn't you be better off implementing such mechanism in an SCM package? Audit can be done with scripts either sitting on top of SCM or Unix/Linux machine. Added logging layer from hosting it on Linux/Unix would benefit you far more and provide better flexibility. Hope it helps, Dave On Fri, Jul 30, 2010 at 1:21 PM, Shan Syed wrote: > ok, thanks > basically for liability reasons for a certain project, we have to provide > specific times of when a project was built and when/where all its > dependencies were retrieved at/from > we have to ensure a sanitary build for all these JARs and a complete log of > going from 0 to 100 for the build; so we are faced with either clearing out > the .m2 each time > I was wondering if there was a way to force this through maven > > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis > wrote: > > > On 07/30/2010 07:16 PM, Wayne Fay wrote: > > > >> is there a way to force a project to refresh certain dependencies every > >>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > >>> > >> > >> Absolutely not. Released artifacts MUST NOT CHANGE. > >> > > > > +1, never ever ;-) > > > > Released artifact versioning is supposed to guarantee consistency. > > > > Manos > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: force maven to redownload/refresh "released" dependencies
On 30/07/2010 12:57 PM, Manos Batsis wrote: On 07/30/2010 07:16 PM, Wayne Fay wrote: is there a way to force a project to refresh certain dependencies every build? i.e. replicate SNAPSHOT behaviour with "released" artifacts Absolutely not. Released artifacts MUST NOT CHANGE. +1, never ever ;-) Released artifact versioning is supposed to guarantee consistency. Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org +1 I have been the victim of an Apache project that rereleased its artifacts. This led to great difficulty in controlling builds to ensure that the correct version of the release was used. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Replacing a SNAPSHOT with a non-SNAPSHOT version is equivalent to upgrading. Jason is right in that this should never be automatically done by Maven. Maven cannot guess or determine when you are ready to give up SNAPSHOT versions. However, perhaps you need an external batch process that discovers new versions and automatically upgrades POMs. Paul On Fri, Jul 30, 2010 at 1:21 PM, Shan Syed wrote: > ok, thanks > basically for liability reasons for a certain project, we have to provide > specific times of when a project was built and when/where all its > dependencies were retrieved at/from > we have to ensure a sanitary build for all these JARs and a complete log of > going from 0 to 100 for the build; so we are faced with either clearing out > the .m2 each time > I was wondering if there was a way to force this through maven > > On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis > wrote: > > > On 07/30/2010 07:16 PM, Wayne Fay wrote: > > > >> is there a way to force a project to refresh certain dependencies every > >>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > >>> > >> > >> Absolutely not. Released artifacts MUST NOT CHANGE. > >> > > > > +1, never ever ;-) > > > > Released artifact versioning is supposed to guarantee consistency. > > > > Manos > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: force maven to redownload/refresh "released" dependencies
ok, thanks basically for liability reasons for a certain project, we have to provide specific times of when a project was built and when/where all its dependencies were retrieved at/from we have to ensure a sanitary build for all these JARs and a complete log of going from 0 to 100 for the build; so we are faced with either clearing out the .m2 each time I was wondering if there was a way to force this through maven On Fri, Jul 30, 2010 at 12:57 PM, Manos Batsis wrote: > On 07/30/2010 07:16 PM, Wayne Fay wrote: > >> is there a way to force a project to refresh certain dependencies every >>> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >>> >> >> Absolutely not. Released artifacts MUST NOT CHANGE. >> > > +1, never ever ;-) > > Released artifact versioning is supposed to guarantee consistency. > > Manos > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: force maven to redownload/refresh "released" dependencies
On 07/30/2010 07:16 PM, Wayne Fay wrote: is there a way to force a project to refresh certain dependencies every build? i.e. replicate SNAPSHOT behaviour with "released" artifacts Absolutely not. Released artifacts MUST NOT CHANGE. +1, never ever ;-) Released artifact versioning is supposed to guarantee consistency. Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
I was actually under the impression you could do this like this: always Although I've never tried this because it's a terrible idea. If this doesn't work, someone should probably remove the corresponding section from http://maven.apache.org/settings.html#Repositories and http://maven.apache.org/settings.html#Repositories (yes, those pages show the repository being disabled, but it is still configured with an updatePolicy). Justin On 7/30/10 12:39 PM, Jason van Zyl wrote: > Maven won't do that, and we would never make that possible. If you require > this you have something seriously wrong with your project infrastructure. > Seriously bad project infrastructure smell. > > On Jul 30, 2010, at 12:01 PM, Shan Syed wrote: > >> is there a way to force a project to refresh certain dependencies every >> build? i.e. replicate SNAPSHOT behaviour with "released" artifacts >> >> S > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > > > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh "released" dependencies
Shan, Maven has a policy how often it checks for updated snapshots. Is that what you are looking for? Paul On Fri, Jul 30, 2010 at 11:39 AM, Jason van Zyl wrote: > Maven won't do that, and we would never make that possible. If you require > this you have something seriously wrong with your project infrastructure. > Seriously bad project infrastructure smell. > > On Jul 30, 2010, at 12:01 PM, Shan Syed wrote: > > > is there a way to force a project to refresh certain dependencies every > > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > > > > S > > Thanks, > > Jason > > -- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > - > > > > >
Re: force maven to redownload/refresh "released" dependencies
Maven won't do that, and we would never make that possible. If you require this you have something seriously wrong with your project infrastructure. Seriously bad project infrastructure smell. On Jul 30, 2010, at 12:01 PM, Shan Syed wrote: > is there a way to force a project to refresh certain dependencies every > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts > > S Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -
Re: force maven to redownload/refresh "released" dependencies
> is there a way to force a project to refresh certain dependencies every > build? i.e. replicate SNAPSHOT behaviour with "released" artifacts Absolutely not. Released artifacts MUST NOT CHANGE. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
