RE: Compilation of Cocoon / Binary Distribution / Different Confi gurations,

[Tim Holloway <TH...@firstalliancebank.com>]

> Dependencies between blocks are a relatively new thing - at the moment 
> we've just dealt with it with comments in the blocks.properties file, 
> which is not ideal, but better than not telling anyone at all.

Well, this is Cocoon. Would it be presumptuous to suggest that the core
block relationships be mapped in an *XML* file?

Something like this:

  blocks
    |
    +---- block
            |
            +-- description
            |
            +-- version
            |
            +-- requires-block (mandatory prerequisite)
            |      |
            |      +--- block-reference
            |               |
            |               +-- block-name (and version???)
            |
            +-- integrates-with (optional prerequisite)*
            |      |
            |      +-- block-reference ... 
            |
            +-- requires-jar
            |      |
           ???     +-- jar-name**
                   |
                   +-- jar-version  

* May be impratical, but it seemed like a good idea to have a context where
a build could collaborate blocks

** Probably should reference a formal jar definition section that maps
logical jar names/versios to their actual filenames/locations.

Just a thought. If one were really clever, it would even be possible to have
cocoon use the above to generate build configurations.

   Tim Holloway

  This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom it is addressed.  If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error, and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited.

 If you received this e-mail in error, please return the e-mail to the sender and delete it from your computer. Although our company attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org

Re: Compilation of Cocoon / Binary Distribution / Different Confi

[Upayavira <uv...@upaya.co.uk>]

Check out:
 http://wiki.cocoondev.org/Wiki.jsp?page=Blocks
for a description of what is planned. You'll see a lot of useful 
functionality is planned.

Regards, Upayavira

Tim Holloway wrote:

>  
>
>>Dependencies between blocks are a relatively new thing - at the moment 
>>we've just dealt with it with comments in the blocks.properties file, 
>>which is not ideal, but better than not telling anyone at all.
>>    
>>
>
>Well, this is Cocoon. Would it be presumptuous to suggest that the core
>block relationships be mapped in an *XML* file?
>
>Something like this:
>
>  blocks
>    |
>    +---- block
>            |
>            +-- description
>            |
>            +-- version
>            |
>            +-- requires-block (mandatory prerequisite)
>            |      |
>            |      +--- block-reference
>            |               |
>            |               +-- block-name (and version???)
>            |
>            +-- integrates-with (optional prerequisite)*
>            |      |
>            |      +-- block-reference ... 
>            |
>            +-- requires-jar
>            |      |
>           ???     +-- jar-name**
>                   |
>                   +-- jar-version  
>
>* May be impratical, but it seemed like a good idea to have a context where
>a build could collaborate blocks
>
>** Probably should reference a formal jar definition section that maps
>logical jar names/versios to their actual filenames/locations.
>
>Just a thought. If one were really clever, it would even be possible to have
>cocoon use the above to generate build configurations.
>
>   Tim Holloway
>
>  This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom it is addressed.  If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error, and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited.
>
> If you received this e-mail in error, please return the e-mail to the sender and delete it from your computer. Although our company attempts to sweep e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>  
>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org