Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45E97942.7010907@apache.org>
Date: Sat, 03 Mar 2007 14:33:54 +0100
From: Reinhard Poetz <reinhard@apache.org>
User-Agent: Thunderbird 2.0b2 (Windows/20070116)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Reloading Classloader Plugin
References: <45E7DF15.1000001@apache.org> <45E83371.5050708@tuffmail.com>
 <45E83594.3070601@apache.org> <45E86FB9.1030805@gmx.de>
 <45E88989.9000406@apache.org> <45E8B8E4.4080304@tuffmail.com>
 <45E94460.4010207@apache.org> <45E974AB.5050901@tuffmail.com>
In-Reply-To: <45E974AB.5050901@tuffmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Grzegorz Kossakowski wrote:
>>
>>> 5. Finally, fifth step. Should clean and package goals be omitted 
>>> while calling jetty:run goal?
>>
>> don't call clean. It would remove the RCL web application again. 
>> Calling package would be useless.
>>
>> mvn jetty:run is enough.
>>
>>>
>>> I tried to guess the answers but did not managed to make it working.
>>
>> I'm going to update the document in Daisy.
>>
> 
> Thanks. I've managed to test it.
> Maybe it's only me, but it was not obvious what rcl plugin does and why 
> this has nothing to do with our webapp archetype. I think it would 
> really helpful stating that rcl plug-in creates special webapp for the 
> block you want to work with and that's why you do not need webapp 
> created by archetype while developing, anymore.
> I also wonder why adding rcl plugin and jetty plugin to the block's pom 
> is broken into two separate steps, and more importantly why we just do 
> not ask user to uncomment already provided configuration? ;)
> I do not want to look it like carping, I just want to simplify the 
> process as much as possible.

hey, that's what I was asking for ;-)

> Everything (reloading of flowscript, updating templates etc) seems to 
> work fine except reloading classes. I've started jetty from eclipse as 
> suggested and classes started to reload. However, when I change 
> visibility of class's field (e.g. from public to private) Eclipse gives 
> me following error:
> "Hot code replace failed - Scheme change not implemented"
> Is it known limitation? If so, should be mentioned in the docs.

that's a limitation of the *Eclipse Jetty* plugin AFAICT. IIRC, if you ignore 
it, everything still works.

I hope that with Torsten's help I can find out why one has to run the app in 
debug mode from within Eclipse.

> When we are at public vs private. I think message field in MyBean.java 
> should be private because now getter is not used while reading from 
> flowscript.

Can be your firest commit ;-)

> I've done all the testing on Windows XP with Java 1.6.0 and Eclipse 3.2.1.
> 
> Thanks for all the good work. I'm going to use your plug-in in all 
> Cocoon developing activities so will give it more serious testing.

Thanks for testing! Further feedback is much appreciated.

BTW, where did you get the commons-jci dependency from? Did you build it from SVN?

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

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

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