On 24 July 2012 23:09, Rajith Attapattu <[email protected]> wrote: > 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 >
I think saying the current system 'just works' is overlooking the extensive amount of tweaking that has to be done to it in order to get even simple things working. For example, look at all the cruft present in it to alow things like running Findbugs, Cobertura etc. Things like can literally be checkbox additions on a Jenkins/Sonar job for people using maven, but which we instead have to manually put together in our Ant build via tens or hundreds of lines in the build, up to and including custom downloads before I finally bit the bullet and introduced Ivy. It is increasingly annoying missing out on easy addition of useful tools and having to maintain that kind of stuff (and if you look at the commits to the build system, I'm fairly sure I will have the majority of them in the last 2-3 years). Our (generated) maven artifacts are often broken between each release and require manual fixing, because we have that wonderful break between the Ant build and the custom generation of those poms. I am the only person who has ever bothered to maintain them or publish them (hands up how many people genuinely know how to even do those things without going and figuring it out now?) after a user contributed a patch [which itself rotted on JIRA for months] to fix some of the issues with them since they had been left to rot after the generation script was added to settle a discussion and then never used. I imagine some reading this could be surprised at this point to know that out of all of my colleagues (who I note are mostly steering clear of this discussion, despite how much they like maven and want us to switch wholesale...) I am usually the one who most downplays any desire to actually switch the main qpid java build over to maven. I think maven has too many advantages not to use if starting something fresh now, but I can see that even the numerous benefits are a hard sell again the time required to make the change and the fact so many of the Qpid developers seem to hate it with a passion. At least some of those points don't apply to proton though, which is why I would like to see us have a maven build for it. Robbie > > > 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] > >
