Stefano Mazzocchi wrote:
- apart from that, I don't think so. Isn't this a gump descriptor?
I just made it became so. Previously it was just a copy and the real descriptor was in the jakarta-gump repository. Now, Gump picks it up from here so this means we have to keep it updated.
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.
Gump nags if there is a failed build, but doesn't nag if dependencies are broken. Fair enough.
The problem is that Gump was designed to expect *all* projects to be equally generated from source. I think this is a mistake.
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.
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.
we need more continous integration and this is done only if more people *here* care about the process, not on gump-land.
For me it looks totally confusing anyway.
I totally agree, even if the choice of separating blocks into their own gump projects makes it easier to obtain a clean cocoon run in Gump by lowering the dependency needs for the core (Sam, did we ever get a clean Cocoon2 gump build?)
We have gotten close, but we have never to my knowledge gotten a clean gump build of cocoon.
which shows pretty evidently we have a problem.
So I'm +1 on removing it and replacing it with per block-versions that use a better XML syntax. For pluggable blocks we need this anyway.
Yes, completely.
Sam, is it possible to have Gump obtain a dynamically generated project descriptor? what would allow us to keep our block descriptors as we like and generate a gump descriptor dynamically.
Yes, I know that it doesn't change that often and that we could file it into the jakarta-gump repository at need, but I'm sure that people will forget to do it, or, even worse, update it by hand.
There are a number of answers to this question, each of them fairly lengthy. I'll give short answers and will expand on each if there is interest.
ok
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.
Here is a potential descriptor for our blocks
<block xmlns="http://apache.org/cocoon/block";>
<name>My Stuff</name>
<identifier>http://myblock.com/block/mystuff</identifier>
<version>2.3</version>
<creator>
<author name="Alice" email="[EMAIL PROTECTED]"/>
<author name="Bob" email="[EMAIL PROTECTED]"/>
<affiliation>MyBlock Corp.</affiliation>
</creator>
<description>This is my stuff</description>
<location url="http://myblock.com/block/mystuff-2.3.cob"; latest="http://myblock.com/block/mystuff.cob"/>
<license url="http://myblock.com/legal/license"/>
<roles>
<implements uri="http://apache.org/cocoon/block/whatever"/>
</roles>
<dependencies>
<requires uri="http://apache.org/cocoon/block/something"/>
<requires uri="http://apache.org/cocoon/block/and-something-else"/>
</dependencies>
<extends uri="http://http://myblock.com/block/myolderstuff"; version="2.x+"/>
</block>
as you can see, there is no information included in this descriptor about "what" implementation of the required dependencies this block will use.
The information can be inferred *only* after crawling all block descriptors and creating a topological map of the dependencies.
While Gump has a much simpler 'direct' concept of dependency, Cocoon COBs will have an indirect dependency concept, as for Component-Oriented Programming polymorphic practices.
Gump does
xml-forrest -> xml-cocoon2
while Cocoon will need
block1 -(requires behavior)-> behavior <-(implements behavior)- block2
thus
block1 -(in this particular setup depends on)-> block2
It's a two step process.
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.
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.
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
In the past we had 2), then we moved to 1)... despite polluting the gump result table with *-block projects who don't really indicate they belong to cocoon (unless one looks at the dependencies), they provide the advantage of reducing the dependencies needed by the cocoon core to be built.
the fact that even with 1) cocoon never got to compile indicates the point is pretty moot anyway. the problem might well reside on how excalibur works with gump.
Cocoon will (sooner or later) move to an indirect dependency graph. This will require a special build system, probably with special ant tasks. I think we'll make an effort to make these tasks bootstrappable with basic Ant and JAXP dependencies. This will keep everybody happy and will make developing the ant tasks easier.
How can this be reflected in gump? It is algorithmically possible to generate a directed dependency graph from an indirected dependency one. So it will be possible to generate a gump-digestible project descriptor, but only dynamically: doing it by hand will be a horrible task.
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.
The last alternative is to include indirect dependencies on gump itself, but i don't think this is worth the effort.
Comments?
-- Stefano Mazzocchi <[EMAIL PROTECTED]> Pluralitas non est ponenda sine necessitate [William of Ockham] --------------------------------------------------------------------
