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.
[snip]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.
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 ofa 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
