gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: maven, gump, developer effort
Date Fri, 08 Oct 2004 14:53:56 GMT
Leo Simons wrote:

> Disclaimer: it has been weeks/months since I last looked into all this.
> 
> Stefano Mazzocchi wrote:
> 
>> But the *most* serious concern is that we seem to have no way to build 
>> with Maven and, due to excalibur, this is holding up basically 15 
>> percent of our projects (including, yes, you guessed right, cocoon).
> 
> 
> actually, we do, but I think its buggy.
> 
>> The problem with maven is that I don't know how we can "inject" the 
>> gump-generated dependency jars into maven.
> 
> 
> that has been answered by others now :-D
> 
>> Does anybody have an idea?
> 
> 
> I will assert that maven is the root problem (no offense intended to the 
> maven people, I'm rather happy with maven recently otherwise). Maven is 
> not built to have other stuff control it, ie it is not very embeddable 
> (unlike ant). It is also not properly bootstrappable. It also has too 
> many complex dependencies itself.
> 
> I will assert as well that this problem goes away with maven2
> (http://cvs.apache.org/viewcvs.cgi/maven-components/ and
>  http://nagoya.apache.org/eyebrowse/SummarizeList?listId=254), being 
> built using an IoC container and all as it is.
> 
> There was/is a pretty aggressive schedule set for maven2 (IIRC the 
> original idea was to have it released by now), which made me want to 
> work on all this even less.
> 
> ---
> 
> Some general comments are no doubt still valid.
> 
> Taking even a short look at the CVS|SVN history of the excalibur 
> codebases (barring various experiments and other "noise") reveals that a 
> rather significant part of the time has been invested in build systems, 
> gump integration etc etc. For a supposedly mature and stable project, 
> much much more than makes sense.
> 
> That had to stop, and it has. The only healthy way to improve the 
> excalibur "FOG" factor is to make it easy and worthwhile for excalibur 
> and others to do just that.
> 
> I will assert that the most serious concern with gump is that it is too 
> hard to use, understand or improve for non-gump-gurus. If this were a 
> componay and I were the boss, the first thing I would tell people to 
> work on is a much more readable and enticing website. Ie "What is Gump? 
> Gump is a social experiment." is not very successful marketing-wise.
> 
> The second thing I would have my team do is to get in place a 
> double-click (and/or configure; make; make install) installer.
> 
> g'night!

Leo,

do you want to help making gump a better thing? fix that damn excalibur 
project!

Don't ask what gump can do for you, but what you can do for gump.

Everything we talked at FooCamp does *NOT* work if we don't reach 
equilibrium.

Do you want an easier Gump? a better documentation? better marketing? 
better ability to spot blame? a better way to edit the metadata and 
validate it?

Join the club.

Now, can we get to equilibrium first? please? can you help me help you?

-- 
Stefano.


Mime
View raw message