On Tue, Jul 24, 2012 at 1:50 PM, Weston M. Price <[email protected]> wrote: > On Jul 24, 2012, at 1:24 PM, Rafael Schloming wrote: > >> Sorry to jump in late on this thread. I'm totally for making proton as >> easy to consume as possible, so I definitely support making maven >> artifacts available, but I also had a very bad experience with maven >> last time I was exposed to it. >> >> As I recall there were two major issues, one being non repeatable builds >> due to a variety of reasons, some of which may have been addressed since >> then. >> >> The other big issue we had was with integration of the maven built >> software into other environments. I don't know if this has changed, but >> maven didn't really have a concept of configuration. Rather than >> adapting the software to build within the host environment, e.g. use >> supplied libraries and/or leave out optional portions of the build, >> maven takes the approach of adapting the host environment to fit the >> software, i.e. download whatever is necessary to build, even if that set >> of stuff is incompatible with the host environment. This actually makes >> it very difficult to integrate maven built software into controlled >> build environments, e.g. distros or release builds. >> >> Given that it's pretty straightforward to get ant to play well with >> others (including maven) and a core goal of proton is to be super easy >> to integrate, I'd be concerned that moving to a maven build might prove >> to be a barrier to broader integration. I'd certainly like to understand >> what it's impact will be e.g. on maintaining proton in distros or >> getting it to build in embedded environments. >> > +1 > My tentative endorsement for maven had more to do with being a good citizen > than any inherent approval. >> --Rafael
I've already stated my concerns as a developer. Let me also state a few concerns from the packaging/distribution side. The issue of repeatable builds and downloading updates from repositories that are outside of our control is really a big concern from a packaging pov. Certain customers/users who would want to build Qpid from source does not like to download bits from all over the internet for security reasons. In some ways moving to maven may infact be a barrier for adoption due to the above issue. Ant on the other hand can spit out maven artefacts. As long as we produce maven artefacts, projects that use maven could easily use proton and Qpid. That to me seems like a win-win situation. Regards, Rajith >> >> On Mon, 2012-07-23 at 16:47 -0400, Joseph Ottinger wrote: >>> Well, what I'll do then is convert proton's build to maven and submit that >>> as a patch attached to an issue, then I'll look into what it would take to >>> get qpid-java's build to maven, too. If those diffs pass inspection, good. >>> If not, we can fix them or ignore them as desired. >>> >>> On Monday, July 23, 2012, Robbie Gemmell <[email protected]> wrote: >>>> I wouldn't particularly be in favour of Ant+Ivy for proton. I did that for >>>> the main Qpid java stuff because it allowed a long overdue clean up of our >>>> repo and didn't involve changing the entire build system (if it had, I >>>> woudn't have done it), but if I was starting afresh I'd be using Maven for >>>> that too. >>>> >>>> Robbie >>>> >>>> On 23 July 2012 20:54, Weston M. Price <[email protected]> wrote: >>>> >>>>> >>>>> On Jul 23, 2012, at 3:22 PM, Robbie Gemmell wrote: >>>>> >>>>>> I think its safe to say Maven is a lot more mature now than it was back >>>>>> then, and is much more widely used. The issues that existed then >>>>> certainly >>>>>> don't seem to bother the massive numbers of large projects using it >>>>> today. >>>>>> >>>>>> Given how popular it is with other developers as a build system and as >>> a >>>>>> route for their projects to consume artifacts, I'd generally be in >>> favour >>>>>> of making the switch if only to be nice citizens to prospective users >>> of >>>>>> proton. >>>>> +1 >>>>> Notwithstanding my personal dislike of maven, it seems to have become the >>>>> de facto standard. Although, we could use Ivy+Ant like we do in the >>> current >>>>> code base. This would be my personal preference but the maven thing has >>>>> truly become a 'if you can't beat them, join them' thing for me so I >>> would >>>>> be fine either way. >>>>> >>>>> Weston >>>>> >>>>>> >>>>>> Robbie >>>>>> On 23 Jul 2012 20:00, "Rajith Attapattu" <[email protected]> wrote: >>>>>> >>>>>>> I personally prefer the simple ant based system. >>>>>>> The last time Qpid used maven it was horrible :) .. it downloaded the >>>>>>> entire universe into my computer. >>>>>>> We also had trouble doing repeatable builds. >>>>>>> Now I don't know if it was due to the way Maven was used or if it was >>>>>>> an issue with Maven itself. >>>>>>> I've never had issues with ant before --- it always worked for me :) >>>>>>> With Maven it wasn't particularly a pleasant experience. >>>>>>> So I'm biased there and please don't blame me for that. >>>>>>> >>>>>>> Having said that, I'm not going to make a fuss, if the majority wants >>>>>>> Maven ! >>>>>>> >>>>>>> One more thing. Converting the build system to maven is fine, but who >>>>>>> ever does that should also take the responsibility of maintaining it >>>>>>> as well :) >>>>>>> To a certain extent that was also an issue with the previous attempt >>>>>>> at using maven. >>>>>>> >>>>>>> Rajith >>>>>>> >>>>>>> On Mon, Jul 23, 2012 at 2:38 PM, Oleksandr Rudyy <[email protected]> >>>>> wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I completely support Joseph's proposal to use maven as building >>> system >>>>>>>> for j-poton module. >>>>>>>> >>>>>>>> Kind Regards, >>>>>>>> Alex >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> 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] >>>>> >>>>> >>>> >>> >> >> >> >> --------------------------------------------------------------------- >> 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]
