Fair enough. IMO, Maven is *the* build system for Java - people behind a security layer haven't proven to be impossible to serve with Maven, and the benefits in lifecycle are well worth it. But it's also not worth the pain if people are anti-Maven, when you *can* get what Maven gets you through the use of judicious scripting.
On Tue, Jul 24, 2012 at 5:19 PM, Rajith Attapattu <[email protected]> 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. > > 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] > -- Joseph B. Ottinger http://enigmastation.com Ça en vaut la peine. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
