Gump Integration

[Stefano Mazzocchi <st...@apache.org>]

Sam Ruby wrote:
> 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="alice@myblock.com"/>
   <author name="Bob" email="bob@myblock.com"/>
   <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                               <st...@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------

Re: Gump Integration

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

Stefano Mazzocchi wrote, On 28/02/2003 17.41:
...
> 
> 
> 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.

Well, Jenny takes all the descriptors and merges them... se below...

> So, I believe that the best thing we can do is to expose two different 
> projects to gump:
> 
>  - cocoon core
>  - cocoon blocks

+1

Each Gump module is a coherent set of <project>s

> 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.

Gump builds *defined* projects, not "generic" ones. Direct dependencies 
are good, because they are an *explicit* contract. IMHO making the gump 
descriptor generated from our descriptors, is a good KISS solution.

"Indirect" dependencies are done in Java via interfaces. I don't see how 
  it can be a problem, as long as we have blocks depend on "interface" 
blocks.

No?

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