On Jul 24, 2012, at 5:19 PM, Rajith Attapattu wrote: > 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. +1 > > 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] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
