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 <[email protected]> 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 >>> <[email protected]>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: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> 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
