cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [New build system] Status of samples
Date Fri, 28 Feb 2003 14:19:21 GMT
Carsten Ziegeler wrote:
> Stefano Mazzocchi wrote:
> 
>> >
>> > 1) Refactor the project-info.xml to split in several files contained >
>> > in the blocks themselves.
>> > Just like Eclipse plugin.xml files in their plugins, a plugin is
>> > installed by just dropping it in the plugins dir. Usecase: This will
>> > make it easy for me to maintain my JavadocSource block (or any
>> > (external) block for that matter), now I need to sync each time when
>> > project-info.xml changes ;-)
>>
>>This is called for, I totally agree. I was going to tackle that problem
>>today, anybody against this?
>>
>>is anything using that project-info.xml file or is just a left-over from
>>the old build system?
>>
> 
> The build mechanism uses it to generate the build file; but I guess you
> know this

yes :)

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

> 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?)

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

Suggestions?

-- 
Stefano Mazzocchi                               <stefano@apache.org>
    Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------



Mime
View raw message