On Tue, Jul 24, 2012 at 5:32 PM, Joseph Ottinger <[email protected]> wrote: > 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.
I don't think it's a case of being anti-Maven. It appears there are some serious concerns (within the Qpid community and outside world in general) with not very convincing solutions. Even though I had a terrible experience the last time around, I clearly mentioned that I will go with what the majority wants. If everybody wants and loves Maven, then I'm not going to stick out like a sore thumb and say no :D My personal opinion is that it's a waste of time, as I'm not so convinced of the rewards that warrants a switch from the current build system that just works! If the current build system is sub optimal, then at least it's a different story. Rajith > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
