cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sam Ruby <ru...@apache.org>
Subject Re: Gump Integration
Date Fri, 28 Feb 2003 19:05:47 GMT
Stefano Mazzocchi wrote:
>> 
>> My two cents: what you just did was significantly reduce the number of 
>> people who can keep this updated.  My experience in the past has been 
>> that this always is a bad thing, but perhaps Cocoon will prove me wrong.
> 
> I'm aware of the fact that it significantly reduced the number of 
> people, but I believe that keeping project descriptors in gump is 
> against the concept of continous integration itself.

I disagree, but I won't pursue this.

> Gump nags if there is a failed build, but doesn't nag if dependencies 
> are broken. Fair enough.

What gump nags on is matches on a regular expression?  Want a nag for 
dependencies, or even just specific dependencies?  Let me know (or 
simply commit the change).

> The problem is that Gump was designed to expect *all* projects to be 
> equally generated from source. I think this is a mistake.

False.  Gump builds today includes dependencies on a large number of 
installed packages.  And on a large number of jars found in cvs.

The profile I happen to run includes perhaps a bit more 
built-from-source definitions than a profile you might choose to run. 
That's OK too.

> Gump should nag if a dependend library is not found because that's a 
> problem with the project build and it's the project's concern to keep it 
> up-to-date.

Want me to change the cocoon descriptor for you?

> in the past, several non-cocoon people and a few cocoon developers cared 
> about gump descriptors, I want that reversed: all cocoon developers care 
> and a few non-cocoon developers nag us if there is something wrong.

I want both.

>> First, my feeling is that if there is a better syntax, I would like to 
>> simply adopt it.  I don't care what the definition of better is: 
>> technical, community, whatever.
> 
> It's not a matter of syntax, Sam. It's a matter of concepts.
> 
> Gump has no notion of polymorphic behaviors, nor I think it should.
> 
[snip]
> 
> There are multiple and extremely important reasons for this additional 
> complexity but I don't think Gump will ever benefit from this since 
> projects are generally directly dependant.

Agreed.  This is even needed for something as simple as JAXP.  Currently 
each project descriptor specifically identifies which version of which 
parser.

> On the other hand, it doesn't surprise me that the projects that are 
> most difficult to automate with Gump are Cocoon Blocks and Avalon 
> Excalibur, both containers of COP-oriented components.

I disagree.  IMHO, it comes down to the question about who cares that 
you raised above.  But I do agree with what you say below:

>> Second, I care very deeply that the process is bootstrapable.
> 
> Fair enough.
> 
>> I don't want the dynamic generation of a descriptor to depend on the 
>  > building of
>> a generator which is described by a descriptor which is generated 
>> dynamically by that generator...
> 
> There are two solutions on the table:
> 
> 1) Cocoon exposes itself and its blocks as Gump projects
> 
> 2) Cocoon exposes its entire self as one project to Gump

[snip]

> So, I believe that the best thing we can do is to expose two different 
> projects to gump:
> 
>   - cocoon core
>   - cocoon blocks
> 
> the first will be a normal project, with the usual direct dependencies.
> 
> the second will be a different type of project, where the project 
> descriptor will have to be dynamically generated by the analysis of the 
> indirect dependency graph of the cocoon blocks.

Works for me.  As long as the dynamic dependency analyzer is, itself, 
bootstrapped statically, I'm happy.

- Sam Ruby


Mime
View raw message