Re: gump + centipede + cc

[Nicola Ken Barozzi <ni...@apache.org>]

Nicola Ken Barozzi wrote, On 16/05/2003 9.29:
> 
> Alexander Lichius wrote, On 16/05/2003 10.14:
...
>> Now going back to centipede I am a bit confused what improvements have 
>> been
>> made since my last visit ...
>> I have read some mails on the gump mailing list which make me think 
>> more in
>> adapting gump to build my cc code. 
> 
> Hmmm...

Now I've thought more about it. And more, and more...

And I am starting to see a pattern here. For example, take Forrest. It's 
an autonomous tool, it's not an Ant task.
Why? Because it's coarse grained.

We used to have cents to run Forrest, and now we are using the installed 
version.
Why? It's too big, and users want to install it themselves.

So it could simply be that Gump should be used with these coarse-grained 
components to generate artifacts.

For example, I've always found it cumbersome to have Gump call Ant call 
Forrest call ?!Ant?! call Cocoon...

Imagine that we can add more tags to Gump, as <ant>, and have also 
<forrest>, <alexandria>, etc... since these don't need to be run 
together in the same script, they can be easily run by Gump one after 
the other.

So we would have Centipede cents that would help the build of Ant files, 
but Gump could run also other systems other than Ant.

I need docs? Run Forrest
I need a build? Run Ant
I need code docs? Run Alexandria

Problem though: if I need to use Gump for building my jars, will it also 
run all other builders like Forrest and Alexandria?
Nope, as long as I use them as Gump "builders"

so we would have:

  build [-w workspace] project|* [builder|-*] [stuff_to_pass_builder]

so I need to run forrest?

  build cocoon2 forrest

I need to run Ant?

  build cocoon2 ant

I need to generically build?

  build cocoon2

I need to run all:

  build cocoon2 *

I need to run target Y on ant?

  build cocoon2 ant Y

>> This brought me to the point to generate my ant build files from gump 
>> and not
>> by an ant encapsulated XSLT transformation (like the former 
>> getdepend.xsl in centipede for example). This is far more faster 
>> because the GOM is alright in memory and I can access it easily from 
>> python. So I added a minimalistic plugin interface that could have a 
>> "handler" like attribute/tag which will cope with the specific build 
>> system a single module/project requires. 
> 
> 
> Hey, this is what I need! Plugins for Gump that handle the build systems!

Could you please send us the code? :-D

...
> The Gump plugins are IMHO the Gump nirvana. If I want to use Maven, I 
> add the Maven plugin, Ant, the Ant plugin, Alexandria, the Alexandria 
> plugin.
> 
> So yes, I'm definately interested, as it really completes the scenario 
> about Gump being a "driver" for building each project.
> 
> What I find more difficult is the other problem you pose, about making 
> the GOM accessible to the underlying build system that is called. What 
> you propose, the Gump "cents", would make Gump actually build instead of 
> calling the build system.
> 
> To keep the vire consistent without changing what you propose, imagine 
> that we make PYcent, which is Centipede in Python. Gump could call that 
> *and* pass the GOM to it, thus making you use it in Pyton code to build 
> your source.
> 
> If you want to use this system for CC code, I'm fine conceptually, but 
> practically you will not be able to use other cents, as they depend on 
> Ant (which could not necessarly be a big problem).
> 
> It also poses another question: how will GUMP pass the GOM to other 
> builders that are not written in Python, and specifically for un Ant?
> My take is that Ant/Centipede would read the XML dump of the GOM and use 
> that as a ViProm, Virtual Project Object Module. That was how it was 
> thought out before.

Now that I think of it, it needs only to serialize the project stuff, 
which is quite small.

> So the alternative scenario is to make the new centipede use the 
> serialized GOM as the viprom, and act as it does now; the only 
> difference is that Gump handles all the dependencies.

And we should ensure that Centipede can run such a project alone if Gump 
has already run it at least once.

This could make all Centipede-based projects dependent on Gump, and have 
to be run by Gump, we'll have to see.

> What do you think?

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------

RE: gump + centipede + cc

[Adam Jack <aj...@TrySybase.com>]

I didn't follow all that (although I've tried) so I've <snipped> 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