You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gk...@apache.org> on 2007/05/01 18:07:40 UTC

Re: Cocoon Maven plugin - Merging deployer & rcl

Reinhard Poetz napisał(a):
> Giacomo Pati wrote:
>> BTW: Can we have a released deployer plugin as well.
> 
> I think that Cocoon should only have one Maven plugin with as many goals
> as needed. Hence I propose that we merge the deployer and the reloading
> classloader plugin into a single one:
>  cocoon:deploy ..... provides shielding and *.xpatch support for "war"
>                      proejcts

Why we need cocoon:deploy at all? I remember that deployer was needed to do some assembly work but it's not needed
anymore because everything is performed at runtime, right?
What's that *.xpatch support? Functionality for patching web.xml file or something else?

>  cocoon:rcl ........ provides a minimal web environment for blocks
>                      ("jar") amd complete reloading of all resources
>                      (Cocoon resources, Java files, Spring context)
> 
> I'm sure that other goals will follow in the future (scaffolding,
> upgrade support, etc.).

It would be great if Cocoon had mechanisms to could make upgrading easier but to be honest I can hardly imagine such
tool. Can you elaborate a little bit?
Oh, and what's "scaffolding" thing? (here, probably my poor English is showing off)

All in all, as usual your proposal is great and go ahead. I hope this changes will be straightforward and lead to quick
release of Cocoon plug-in ;-)

-- 
Grzegorz Kossakowski

Re: Cocoon Maven plugin - Merging deployer & rcl

Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Giacomo Pati wrote:
>>> BTW: Can we have a released deployer plugin as well.
>> I think that Cocoon should only have one Maven plugin with as many goals
>> as needed. Hence I propose that we merge the deployer and the reloading
>> classloader plugin into a single one:
>>  cocoon:deploy ..... provides shielding and *.xpatch support for "war"
>>                      proejcts
> 
> Why we need cocoon:deploy at all? I remember that deployer was needed to do some assembly work but it's not needed
> anymore because everything is performed at runtime, right?
> What's that *.xpatch support? Functionality for patching web.xml file or something else?

no, you can patch your web.xml by some xml snippets.

> 
>>  cocoon:rcl ........ provides a minimal web environment for blocks
>>                      ("jar") amd complete reloading of all resources
>>                      (Cocoon resources, Java files, Spring context)
>>
>> I'm sure that other goals will follow in the future (scaffolding,
>> upgrade support, etc.).
> 
> It would be great if Cocoon had mechanisms to could make upgrading easier but to be honest I can hardly imagine such
> tool. Can you elaborate a little bit?

Once we had the situation that we deprecated some element in cforms definitions. 
We provided an Ant task for that purpose but nowadays we could provide an Maven 
goal for this purpose.

> Oh, and what's "scaffolding" thing? (here, probably my poor English is showing off)

think of a Maven archetype but you can use it on an already existing project. 
the term "scaffolding" became popular by RubyOnRails which uses it to generate 
everything which is necessary for a web application based on IIRC a table name.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------



	
		
___________________________________________________________ 
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de