Return-Path: Mailing-List: contact gump-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list gump@jakarta.apache.org Received: (qmail 54539 invoked from network); 16 May 2003 13:52:41 -0000 Received: from unknown (HELO mx1.trysybase.com) (63.102.81.233) by daedalus.apache.org with SMTP; 16 May 2003 13:52:41 -0000 Received: from mail.trysybase.com (mail.trysybase.com [172.20.0.10]) by mx1.trysybase.com (8.11.6/8.11.0) with ESMTP id h4GDqAA32696; Fri, 16 May 2003 07:52:10 -0600 Received: from wdn086 ([172.20.1.226]) by mail.trysybase.com (8.11.6/8.11.6) with SMTP id h4GDlFW05395; Fri, 16 May 2003 07:47:16 -0600 Reply-To: From: "Adam Jack" To: Cc: Subject: RE: gump + centipede + cc Date: Fri, 16 May 2003 07:53:44 -0600 Message-ID: <007001c31bb2$91485070$c0c5ea43@wdn086> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3EC4DC1A.5050904@apache.org> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N I didn't follow all that (although I've tried) so I've it and will state my thoughts. Software fails when it looses focus of it's sweet spot. I think we need to identify and recognize those sweet spots to avoid overlapping and/or loosing focus. Gump has (IMHO) historically succeeded because of it position as the coordinator amongst disparate projects. It uses the GOM (something I think is invaluable) to identify the "interaction points" (jars, etc.) between projects. I think Gump is "open" because it allows extension (primarily with ant) and doesn't get involved in the internal details of the build, only the outputs. Ant has (IMHO) historically succeeded because it is the "universal extension point glue" it allows disparate things (of whatever granularity, in whatever forked language) to communicate (through FileSets, properties, etc.) Like it or not, dependency builder or not, Ant is the new scripting language. Centipede has (IMHO) a sweet spot of being the "coordinator amongst 'scriptlets' -- or powerfully re-usable chunks of ant scripts". Ant is a thing of beauty in how powerful it is, but it is a pain in the butt as to how low level it is, and how much thinking/typing/testing/debugging needs to be done each time. Centipede provides higher level building blocks, to channel some of that power without limiting it, and remaining open. Centipede is open because you can insert any ant tasks you like. Centipede is Ant++ in that regard, less is more. Part of me say, it is more what these things don't do, as opposed to do, that makes them open... I would hate to see Gump try to become a script language and run all sorts of things, I think that is the purview of ant or (for basically standard higher-level builds Maven or Centipede, or for standard plus ant extensions Centipede). I think Gump would fail because it lacks the "glue" (properties, FileSets, etc.) to allow these things to communicate. So, long story short --- although I don't really know what cc wants (unless it is simple a c compiler, sorry for being ignorant) my view would be (1) build ant tasks (2) build centipede cents (to encapsulate standard processing) and allow folks to glue it in o things like Gump via either Ant form (ant proper, or ant in centipede). BTW: I love "GOM" -- the sound of the acronym and the images it conjures, but most importantly what it is trying to achieve. I think the GOM -- an open way to describe interactions amongst disparate and distributed projects is the power of Gump. I know this'll get much tougher as it strays from Java only to other (different outputs than jars), but I see it as the most valuable part to focus upon. Just my tuppence... regards, Adam