As others have indicated, many of the points being raised are basically solvable 'problems'. I really doubt we would be the first project in the world to use maven that might be included in a distro (or say twenty, for projects with more widespread reach).
I understand that it might not be the easiest for some of us (I include myself in that list, spending a good amount of time somewhere that accessing e.g. maven central doesn't fly, but that didn't stop me moving our main java build to use it) but that doesn't mean it isn't more beneficial to the majority of our users. Robbie On 24 July 2012 22:19, 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] > >
