On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <[email protected]> wrote: > There *are* ways to turn that off - but the easiest is to run once
While this might solve the developer headaches, it still doesn't solve the issue with customers/users and release eng folks (at my employer). For some users/customers downloading even once (from unsecured repositories) is a definite no. This I believe is also an issue with the RPM package process. Trying to disable or setting up private repos seems more trouble than worth it. We want to further adoption and IMO Maven seems an unnecessary burden for some users. A simple build system that does the job seems the best solution. As Matthew points out, I wonder why we need to jump through so many hoops to make this work. I want to write code not meddle with my build system. Besides the current build system works and I'm not aware of any issues. So why are we trying to fix something that is not broken ? To be very blunt, this seems like a waste of time with little or no benefit. Perhaps adding the bits to make the ant system spit out maven artefacts for proton (like we have for Qpid) seems a better alternative. Rajith > (after which most of the downloads will be finished), and then manage > dependency versions accurately; it won't redownload stuff it already > has, so if you specify a given dependency, version 6.0.12, it's not > going to redownload that unless it actually needs to (in which case > you *want* it to.) > > You can say that you want dependencies with a given version range, but > again, these aren't actual "download the world" mechanisms, especially > if the libraries don't revise often - they'll check the dependency if > they need to, then be done. > > And maven 2 is no longer in common usage; I don't think we need to > compensate for it. > > On Tue, Jul 24, 2012 at 4:02 PM, Matthew Gillen <[email protected]> wrote: >> On 07/24/2012 01:41 PM, Gordon Sim wrote: >>> On 07/23/2012 09:38 PM, Robbie Gemmell wrote: >>>> I wouldn't particularly be in favour of Ant+Ivy for proton. >>> >>> Any particular reason? >>> >>> I must be old or stupid (or both!) because I can't understand why people >>> like maven. Admittedly I haven't used it for a long time and the >>> usability may have improved. However my recollection is of more >>> frustration than I have ever experienced with a 'build system'. >>> >>> Even philosophically it seemed wrong to me - I want to compile my >>> changes and it goes off looking for any updates to jar files the project >>> or the tool itself might use. That sort of system update seems to me >>> like it should be an entirely separate step. >> >> There are ways to turn all that stuff off (e.g. force offline mode, >> instead distribute all the maven-supplied dependencies as a zip file >> that can be used to populate a local-cache repository, etc). >> >> The the "non-repeatable build" can be solved either by the zip file or >> by hosting your own nexus server (which mirrors anything it fetches for >> you, thereby ensuring that you have access to it later even if the >> upstream goes away). >> >> But yes, that's all a lot of overhead to just get going compiling code; >> it's painful, and IMO not worth it. Oh, and you get strange errors if >> you try to build a maven2 project with maven3 (i.e., nothing in the >> error mentions that maybe maven3 doesn't grok the old-style config). >> I've used maven (involuntarily) for a while now, and will avoid it at >> all costs in the future. >> >> Full disclosure: I'm old enough to wish everything was just done with >> gmake... >> >> Matt >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Joseph B. Ottinger > http://enigmastation.com > Ça en vaut la peine. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
