So my 2 cents.. If your goal is to produce libraries which get published to maven central, then it's much easier to use maven than to use Ivy. Several project at the ASF have mastered that art of releasing using maven, so if Qpid feels timid about how to best set it up / use it, then reach out.
Maven release builds are always reproducible to for me. Recent maven releases have helped in this respect. The new releases warn you when you do things which could lead to non-reproducible builds. A good example is making sure you specify versions for your maven plugins. Also I don't mind the long initial download times maven has. It's only the first time you use a project and I'd rather maven download all the build tools need to do a reproducible build than me figuring out what I need to install and setup. Usually maven can download the internet faster than it takes folks to setup all the build requirements in a complex builds. Thats why I use maven. The fact is that the proton build is about as vanilla as a build gets. There's no code generation, and no extra tools to post-process stuff. This guy will only need a small pom to get it working properly. Since the Apache wide parent pom configures all the ASF standard plugins, your release builds will: deploy the jar, a source jar, asc sigs for the artifacts, and md5s. Plus it will be deploying to the ASF nexus instance. Nexus handles staging and locking down build for voting. Finally, once the vote passes, it's a couple of clicks in nexus to release it to maven central. Then the rest of the world can enjoy downloading your part of the internet :) Regards, Hiram On Tue, Jul 24, 2012 at 6:09 PM, 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 > > > 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] > > -- ** *Hiram Chirino* *Software Fellow | FuseSource Corp.* *[email protected] | fusesource.com* *skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino> * *blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>* * * * *
