qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Weston M. Price" <wpr...@redhat.com>
Subject Re: Maven build?
Date Wed, 25 Jul 2012 14:05:08 GMT

On Jul 24, 2012, at 5:19 PM, Rajith Attapattu wrote:

> On Tue, Jul 24, 2012 at 4:56 PM, Joseph Ottinger <joeo@enigmastation.com> 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.
+1 
> 
> 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 <me@mattgillen.net> 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: dev-unsubscribe@qpid.apache.org
>>> For additional commands, e-mail: dev-help@qpid.apache.org
>>> 
>> 
>> 
>> 
>> --
>> Joseph B. Ottinger
>> http://enigmastation.com
>> Ça en vaut la peine.
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: dev-help@qpid.apache.org
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
> For additional commands, e-mail: dev-help@qpid.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message