You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Reinhard Poetz <re...@apache.org> on 2007/03/02 09:23:49 UTC
Preparing Cocoon 2.2RC1
What are our plans for the next series of releases? I want to see it happen in
the last week of March.
For my part I will work on getting the documentation published which will
include a proper release (alpha, beta or whatever the Daisy community prefers)
of the daisy-maven plugin.
What else needs to be done by then? What are your plans?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Preparing Cocoon 2.2RC1
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 3/2/07, Carsten Ziegeler <cz...@apache.org> wrote:
> ...I would like to have a 2.1.11 release by the end of march as well...
I should be able to help testing that one.
-Bertrand
Re: Preparing Cocoon 2.2RC1
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
>
> What are your plans for 1.0.1? Your recent additions (default values, bean-map)
> are already part of 1.0.0.
>
Ups, didn't notice that while testing. If they're already part of 1.0.0
there is currently no need (= no plans) for 1.0.1
Apart from that, I'll try to finish the portal block during march, so
hopefully we can release a milestone by the end of march as well.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: Preparing Cocoon 2.2RC1
Posted by Reinhard Poetz <re...@apache.org>.
Carsten Ziegeler wrote:
> Reinhard Poetz wrote:
>> What are our plans for the next series of releases? I want to see it happen in
>> the last week of March.
>>
>> For my part I will work on getting the documentation published which will
>> include a proper release (alpha, beta or whatever the Daisy community prefers)
>> of the daisy-maven plugin.
>>
>> What else needs to be done by then? What are your plans?
>>
> +1 for end of march. What about an earlier spring-configurator 1.0.1
> release?
What are your plans for 1.0.1? Your recent additions (default values, bean-map)
are already part of 1.0.0.
>
> I would like to have a 2.1.11 release by the end of march as well.
+0 (means that I can't help with it)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Preparing Cocoon 2.2RC1
Posted by Carsten Ziegeler <cz...@apache.org>.
Reinhard Poetz wrote:
> What are our plans for the next series of releases? I want to see it happen in
> the last week of March.
>
> For my part I will work on getting the documentation published which will
> include a proper release (alpha, beta or whatever the Daisy community prefers)
> of the daisy-maven plugin.
>
> What else needs to be done by then? What are your plans?
>
+1 for end of march. What about an earlier spring-configurator 1.0.1
release?
I would like to have a 2.1.11 release by the end of march as well.
Carsten
--
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/
Re: Sharing blocks between trunk and branch_2.1
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz skrev:
> Grzegorz Kossakowski wrote:
>
>> I fear that the most difficult task will be encouraging you to stop
>> sharing forms and ajax blocks between trunk and 2.1.x branch. On the
>> other hand, I can live with that stuff in patches/whiteboard if you wish.
>
> I propose that we stop sharing blocks between 2.1 and trunk with the
> upcoming 2.1.11 release.
>
> We only have to ensure that the samples blocks (e.g.
> cocoon-forms-samples) works with the reloading classloader plugin so
> that cforms developers can easily continue their work.
>
> WDOT?
+1
/Daniel
Re: Reloading Classloader Plugin
Posted by Torsten Curdt <tc...@apache.org>.
On 02.03.2007, at 21:31, Reinhard Poetz wrote:
> Joerg Heinicke wrote:
>
>>> We only have to ensure that the samples blocks (e.g. cocoon-forms-
>>> samples) works with the reloading classloader plugin so that
>>> cforms developers can easily continue their work.
>> ??
>
> Using the reloading-classloader-plugin you can run a block as the
> plugin creates a default Cocoon webapp and deploys the block into
> it. And, as the blocks name conveys, it takes care that you can
> work on Cocoon resources and Java sources while they get reloaded
> transparently. (http://cocoon.zones.apache.org/daisy/cdocs-rcl-
> plugin/g1/1295.html)
>
> I would also be interested in some feedback as I want to release it
> as soon as Torsten has finished a Commons JCI release.
Some news from this side: all the last API changes are in. So it
would be well worth also getting the Cocoon part adjusted.
so I can slip in last changes if required. The 1.0 release should
feature support for eclipse, janino and groovy.
Just recently I've added support for javac and javascript
compilation. Both are still very new and probably need some more
testing though.
More compilers plugins in the works - but no promises yet :)
cheers
--
Torsten
Re: Reloading Classloader Plugin
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Torsten Curdt napisał(a):
>
> What filesystem?
>
Forgot about file system in previous mail. I have NTFS partitions.
--
Grzegorz Kossakowski
Re: Reloading Classloader Plugin
Posted by Torsten Curdt <tc...@apache.org>.
>> Well, "broken" ;) ...as the groupId is now using the maven2 scheme
>> the commons is already included in there.
>> But I will bring that up on commons dev to see how we will handle
>> this.
> I agree but now eveywhere else "commons-" prefix is used in
> artifact ids so you have to change it everywhere or nowhere.
The reason for that is that we inherited the group id for the
projects in proper. This should not be *required* for new project
getting released. But I would really prefer to use the maven2 group
scheme. Again - that's a topic for commmons-dev and not cocoon-dev.
..plus changing this that is probably the least work that is still to
be done ;)
> Now build is just broken because jci-core cannot find parent pom...
Works just fine for me. Did you check out the whole sandbox? (Or
checkout the parent pom and "mvn install" it)
>> All tests work for me.
>>
>> What (sub)projects are failing?
>> What operating system are you using?
>> What filesystem?
>> Can you send me the outputs?
>>
> I attach full Maven output so you can gather from it answers to
> most of your questions:
Well, some of them ...could you please send me (off list) the test
outputs from the "target" dir?
> G:\asf\commons-jci>mvn clean install
Windows - I somehow expected to see some problem there ;)
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.apache.commons.jci.CompilingClassLoaderTestCase
> Exception in thread "Thread-1" java.lang.RuntimeException: cannot
> handle resource jci\Extended.java
OK ...that needs to be "jci/Extended.java". Easy to fix.
> Everything tested on WinXP SP2 with Java 1.6.0 installed and ran
> with Maven 2.0.4.
OK
> Is FilesystemAlterationMonitorTestCase supposed to take so long
> (about 1 minute)?
Yes, that's expected. Unfortunately the resolution for last-modified
information differs from filesystem to filesystem. So we have to use
some sleeps to make it work across platforms. This is just a testing
issue though.
cheers
--
Torsten
Re: Reloading Classloader Plugin
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Torsten Curdt napisał(a):
>
> On 03.03.2007, at 19:53, Grzegorz Kossakowski wrote:
>
>> Torsten Curdt napisał(a):
>>>
>>> Definitely! ...please use latest trunk!
>>>
>> No problem. Howver, root pom of commons-jci is broken, you have "jci"
>> as artifactId but it should be "commons-jci".
>
> Well, "broken" ;) ...as the groupId is now using the maven2 scheme the
> commons is already included in there.
> But I will bring that up on commons dev to see how we will handle this.
I agree but now eveywhere else "commons-" prefix is used in artifact ids
so you have to change it everywhere or nowhere. Now build is just broken
because jci-core cannot find parent pom...
>
> All tests work for me.
>
> What (sub)projects are failing?
> What operating system are you using?
> What filesystem?
> Can you send me the outputs?
>
I attach full Maven output so you can gather from it answers to most of
your questions:
G:\asf\commons-jci>mvn clean install
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Commons JCI
[INFO] fam
[INFO] core
[INFO] compiler-eclipse
[INFO] compiler-janino
[INFO] compiler-groovy
[INFO] compiler-javac
[INFO] examples
[INFO]
----------------------------------------------------------------------------
[INFO] Building Commons JCI
[INFO] task-segment: [clean, install]
[INFO]
----------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory G:\asf\commons-jci\target
[INFO] Deleting directory G:\asf\commons-jci\target\classes
[INFO] Deleting directory G:\asf\commons-jci\target\test-classes
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[copy] Copying 2 files to G:\asf\commons-jci\target\classes\META-INF
[INFO] Executed tasks
[INFO] [site:attach-descriptor]
[WARNING] Unable to load parent project from repository: Could not find
the model file 'G:\asf\commons-jci\..\pom.xml'.
[INFO] [install:install]
[INFO] Installing G:\asf\commons-jci\pom.xml to C:\Documents and
Settings\gReK\.m2\repository\org\apache\commons\commons-jci\1.0-SNAPSHOT\commons-jci-1.0-SNA
PSHOT.pom
[INFO]
----------------------------------------------------------------------------
[INFO] Building fam
[INFO] task-segment: [clean, install]
[INFO]
----------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory G:\asf\commons-jci\fam\target
[INFO] Deleting directory G:\asf\commons-jci\fam\target\classes
[INFO] Deleting directory G:\asf\commons-jci\fam\target\test-classes
Downloading:
http://repo1.maven.org/maven2/commons-logging/commons-logging-api/1.1/commons-logging-api-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 5 source files to G:\asf\commons-jci\fam\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 1 source file to G:\asf\commons-jci\fam\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
G:\asf\commons-jci\fam\target\surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.apache.commons.jci.monitor.FilesystemAlterationMonitorTestCase
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 51.281 sec
Results :
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar]
[INFO] Building jar:
G:\asf\commons-jci\fam\target\commons-jci-fam-1.0-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing
G:\asf\commons-jci\fam\target\commons-jci-fam-1.0-SNAPSHOT.jar to
C:\Documents and Settings\gReK\.m2\repository\org\apache\commons\commons-
jci-fam\1.0-SNAPSHOT\commons-jci-fam-1.0-SNAPSHOT.jar
[INFO]
----------------------------------------------------------------------------
[INFO] Building core
[INFO] task-segment: [clean, install]
[INFO]
----------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] Deleting directory G:\asf\commons-jci\core\target
[INFO] Deleting directory G:\asf\commons-jci\core\target\classes
[INFO] Deleting directory G:\asf\commons-jci\core\target\test-classes
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[INFO] Executed tasks
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 22 source files to G:\asf\commons-jci\core\target\classes
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
Compiling 8 source files to G:\asf\commons-jci\core\target\test-classes
[INFO] [surefire:test]
[INFO] Surefire report directory:
G:\asf\commons-jci\core\target\surefire-reports
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.apache.commons.jci.CompilingClassLoaderTestCase
Exception in thread "Thread-1" java.lang.RuntimeException: cannot handle
resource jci\Extended.java
at
org.apache.commons.jci.CompilingClassLoaderTestCase$MockJavaCompiler.compile(CompilingClassLoaderTestCase.java:71)
at
org.apache.commons.jci.CompilingClassLoaderTestCase$MockJavaCompiler.compile(CompilingClassLoaderTestCase.java:84)
at
org.apache.commons.jci.listeners.CompilingListener.isReloadRequired(CompilingListener.java:135)
at
org.apache.commons.jci.listeners.ReloadingListener.onStop(ReloadingListener.java:128)
at
org.apache.commons.jci.monitor.FilesystemAlterationObserverImpl.notifyOnStop(FilesystemAlterationObserverImpl.java:265)
at
org.apache.commons.jci.monitor.FilesystemAlterationObserverImpl.checkAndNotify(FilesystemAlterationObserverImpl.java:331)
at
org.apache.commons.jci.monitor.FilesystemAlterationMonitor.run(FilesystemAlterationMonitor.java:121)
at java.lang.Thread.run(Unknown Source)
2007-03-04 18:47:16
org.apache.commons.jci.listeners.AbstractFilesystemAlterationListener
waitForSignal
SEVERE: timeout after 10s
Exception in thread "Thread-2" java.lang.RuntimeException: cannot handle
resource jci\Extended.java
at
org.apache.commons.jci.CompilingClassLoaderTestCase$MockJavaCompiler.compile(CompilingClassLoaderTestCase.java:71)
at
org.apache.commons.jci.CompilingClassLoaderTestCase$MockJavaCompiler.compile(CompilingClassLoaderTestCase.java:84)
at
org.apache.commons.jci.listeners.CompilingListener.isReloadRequired(CompilingListener.java:135)
at
org.apache.commons.jci.listeners.ReloadingListener.onStop(ReloadingListener.java:128)
at
org.apache.commons.jci.monitor.FilesystemAlterationObserverImpl.notifyOnStop(FilesystemAlterationObserverImpl.java:265)
at
org.apache.commons.jci.monitor.FilesystemAlterationObserverImpl.checkAndNotify(FilesystemAlterationObserverImpl.java:331)
at
org.apache.commons.jci.monitor.FilesystemAlterationMonitor.run(FilesystemAlterationMonitor.java:121)
at java.lang.Thread.run(Unknown Source)
2007-03-04 18:47:27
org.apache.commons.jci.listeners.AbstractFilesystemAlterationListener
waitForSignal
SEVERE: timeout after 10s
Exception in thread "Thread-3" java.lang.RuntimeException: cannot handle
resource jci\Extended.java
at
org.apache.commons.jci.CompilingClassLoaderTestCase$MockJavaCompiler.compile(CompilingClassLoaderTestCase.java:71)
at
org.apache.commons.jci.CompilingClassLoaderTestCase$MockJavaCompiler.compile(CompilingClassLoaderTestCase.java:84)
at
org.apache.commons.jci.listeners.CompilingListener.isReloadRequired(CompilingListener.java:135)
at
org.apache.commons.jci.listeners.ReloadingListener.onStop(ReloadingListener.java:128)
at
org.apache.commons.jci.monitor.FilesystemAlterationObserverImpl.notifyOnStop(FilesystemAlterationObserverImpl.java:265)
at
org.apache.commons.jci.monitor.FilesystemAlterationObserverImpl.checkAndNotify(FilesystemAlterationObserverImpl.java:331)
at
org.apache.commons.jci.monitor.FilesystemAlterationMonitor.run(FilesystemAlterationMonitor.java:121)
at java.lang.Thread.run(Unknown Source)
2007-03-04 18:47:38
org.apache.commons.jci.listeners.AbstractFilesystemAlterationListener
waitForSignal
SEVERE: timeout after 10s
Exception in thread "Thread-4" java.lang.RuntimeException: cannot handle
resource jci\Extended.java
at
org.apache.commons.jci.CompilingClassLoaderTestCase$MockJavaCompiler.compile(CompilingClassLoaderTestCase.java:71)
at
org.apache.commons.jci.CompilingClassLoaderTestCase$MockJavaCompiler.compile(CompilingClassLoaderTestCase.java:84)
at
org.apache.commons.jci.listeners.CompilingListener.isReloadRequired(CompilingListener.java:135)
at
org.apache.commons.jci.listeners.ReloadingListener.onStop(ReloadingListener.java:128)
at
org.apache.commons.jci.monitor.FilesystemAlterationObserverImpl.notifyOnStop(FilesystemAlterationObserverImpl.java:265)
at
org.apache.commons.jci.monitor.FilesystemAlterationObserverImpl.checkAndNotify(FilesystemAlterationObserverImpl.java:331)
at
org.apache.commons.jci.monitor.FilesystemAlterationMonitor.run(FilesystemAlterationMonitor.java:121)
at java.lang.Thread.run(Unknown Source)
2007-03-04 18:47:49
org.apache.commons.jci.listeners.AbstractFilesystemAlterationListener
waitForSignal
SEVERE: timeout after 10s
Tests run: 4, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 44.156
sec <<< FAILURE!
Running org.apache.commons.jci.ReloadingClassLoaderTestCase
2007-03-04 18:48:13 org.apache.commons.jci.ReloadingClassLoaderTestCase
testClassNotFound
INFO: bla
Tests run: 6, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 27.047
sec <<< FAILURE!
Running org.apache.commons.jci.stores.ResourceStoreTestCase
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.032 sec
Running org.apache.commons.jci.readers.ResourceReaderTestCase
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0 sec
Results :
Tests run: 15, Failures: 0, Errors: 8, Skipped: 0
Everything tested on WinXP SP2 with Java 1.6.0 installed and ran with
Maven 2.0.4.
Is FilesystemAlterationMonitorTestCase supposed to take so long (about 1
minute)?
Re: Reloading Classloader Plugin
Posted by Torsten Curdt <tc...@apache.org>.
On 03.03.2007, at 19:53, Grzegorz Kossakowski wrote:
> Torsten Curdt napisał(a):
>>
>> Definitely! ...please use latest trunk!
>>
> No problem. Howver, root pom of commons-jci is broken, you have
> "jci" as artifactId but it should be "commons-jci".
Well, "broken" ;) ...as the groupId is now using the maven2 scheme
the commons is already included in there.
But I will bring that up on commons dev to see how we will handle this.
> I had to disable tests because many of them fail. Is it known issue?
All tests work for me.
What (sub)projects are failing?
What operating system are you using?
What filesystem?
Can you send me the outputs?
cheers
--
Torsten
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>
> On 08.03.2007, at 07:48, Reinhard Poetz wrote:
>
>> Reinhard Poetz wrote:
>>> Yesterday I did a svn up on commons-jci and get errors of type
>>> ClassDefNotFoundError. After reloading it again, the error
>>> disappears. After testing commons-jci built on Sunday afternoon,
>>> everything works as expected.
>>
>> Once again ;-)
>>
>> Yesterday I did a svn up on commons-jci and now I get errors of type
>> ClassDefNotFoundError when the reloading classloader is used (-> doing
>> a page refresh) right after a change. After a second page refresh, the
>> error is gone.
>
> Uh! That is weird! ClassDefNotFoundError of what? Can you give me log
> output for that (having "org.apache.commons.jci" on DEBUG)?
"unfortunatly" I can't reproduce this behaviour today
> I just did a
>
> svn diff -r {2007-03-03}:HEAD
> https://svn.apache.org/repos/asf/jakarta/commons/sandbox/jci/trunk
>
> and really the only bigger change is properly closing InputStreams and
> handling paths correctly. Windows was complaining.
>
>> After reverting to commons-jci which was built on Sunday afternoon,
>> everything works as expected (except that I still need to run it in
>> debug mode which causes problems because the hot code replace
>> mechanism of Eclipse interfers.)
>
> Yeah ...we need to look into that debug problem.
>
>> Any clue?
>>
>>> Maybe I'm doing something wrong in
>>> http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/src/main/java/org/apache/cocoon/servlet/ReloadingClassloaderManager.java?
>>>
>
> That code looks fine to me.
thanks
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading Classloader Plugin
Posted by Torsten Curdt <tc...@apache.org>.
On 08.03.2007, at 07:48, Reinhard Poetz wrote:
> Reinhard Poetz wrote:
>> Yesterday I did a svn up on commons-jci and get errors of type
>> ClassDefNotFoundError. After reloading it again, the error
>> disappears. After testing commons-jci built on Sunday afternoon,
>> everything works as expected.
>
> Once again ;-)
>
> Yesterday I did a svn up on commons-jci and now I get errors of
> type ClassDefNotFoundError when the reloading classloader is used (-
> > doing a page refresh) right after a change. After a second page
> refresh, the error is gone.
Uh! That is weird! ClassDefNotFoundError of what? Can you give me log
output for that (having "org.apache.commons.jci" on DEBUG)?
I just did a
svn diff -r {2007-03-03}:HEAD https://svn.apache.org/repos/asf/
jakarta/commons/sandbox/jci/trunk
and really the only bigger change is properly closing InputStreams
and handling paths correctly. Windows was complaining.
> After reverting to commons-jci which was built on Sunday afternoon,
> everything works as expected (except that I still need to run it in
> debug mode which causes problems because the hot code replace
> mechanism of Eclipse interfers.)
Yeah ...we need to look into that debug problem.
> Any clue?
>
>> Maybe I'm doing something wrong in http://svn.apache.org/repos/asf/
>> cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/src/main/
>> java/org/apache/cocoon/servlet/ReloadingClassloaderManager.java?
That code looks fine to me.
cheers
--
Torsten
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Reinhard Poetz wrote:
>
> Yesterday I did a svn up on commons-jci and get errors of type
> ClassDefNotFoundError. After reloading it again, the error disappears.
> After testing commons-jci built on Sunday afternoon, everything works as
> expected.
Once again ;-)
Yesterday I did a svn up on commons-jci and now I get errors of type
ClassDefNotFoundError when the reloading classloader is used (-> doing a page
refresh) right after a change. After a second page refresh, the error is gone.
After reverting to commons-jci which was built on Sunday afternoon, everything
works as expected (except that I still need to run it in debug mode which causes
problems because the hot code replace mechanism of Eclipse interfers.)
Any clue?
> Maybe I'm doing something wrong in
> http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/src/main/java/org/apache/cocoon/servlet/ReloadingClassloaderManager.java?
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Yesterday I did a svn up on commons-jci and get errors of type
ClassDefNotFoundError. After reloading it again, the error disappears. After
testing commons-jci built on Sunday afternoon, everything works as expected.
Maybe I'm doing something wrong in
http://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-rcl/cocoon-rcl-webapp-wrapper/src/main/java/org/apache/cocoon/servlet/ReloadingClassloaderManager.java.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading Classloader Plugin
Posted by Torsten Curdt <tc...@apache.org>.
On 05.03.2007, at 07:31, Reinhard Poetz wrote:
> Torsten Curdt wrote:
>> On 04.03.2007, at 18:40, Reinhard Poetz wrote:
>>> Torsten Curdt wrote:
>>>> On 04.03.2007, at 17:59, Reinhard Poetz wrote:
>>>>> Grzegorz Kossakowski wrote:
>>>>>> Reinhard Poetz napisał(a):
>>>>>>>
>>>>>>> Just a warning, AFAICS it's not a "drop-in replacement"
>>>>>>> because of some API changes.
>>>>>> Thanks for fixing this. Unfortunately, nothing changed after
>>>>>> replacing jci with the current trunk. Still class reloading
>>>>>> does not work while running outside the Eclipse and still
>>>>>> there is problem with "Scheme change not implemented".
>>>>>
>>>>> I hope that Torsten will find some time to help us as soon as
>>>>> jci got released.
>>>> Sure will try ...actually adopting to the API changes would be
>>>> good to do before the release of jci.
>>>
>>> already done
>> Seriously? That would be awesome! :)
>
> It wasn't that difficult because the API became cleaner and much
> easier to understand :-)
Cool :)
cheers
--
Torsten
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>
> On 04.03.2007, at 18:40, Reinhard Poetz wrote:
>
>> Torsten Curdt wrote:
>>> On 04.03.2007, at 17:59, Reinhard Poetz wrote:
>>>> Grzegorz Kossakowski wrote:
>>>>> Reinhard Poetz napisał(a):
>>>>>>
>>>>>> Just a warning, AFAICS it's not a "drop-in replacement" because of
>>>>>> some API changes.
>>>>> Thanks for fixing this. Unfortunately, nothing changed after
>>>>> replacing jci with the current trunk. Still class reloading does
>>>>> not work while running outside the Eclipse and still there is
>>>>> problem with "Scheme change not implemented".
>>>>
>>>> I hope that Torsten will find some time to help us as soon as jci
>>>> got released.
>>> Sure will try ...actually adopting to the API changes would be good
>>> to do before the release of jci.
>>
>> already done
>
> Seriously? That would be awesome! :)
It wasn't that difficult because the API became cleaner and much easier to
understand :-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Reloading Classloader Plugin
Posted by Torsten Curdt <tc...@apache.org>.
On 04.03.2007, at 18:40, Reinhard Poetz wrote:
> Torsten Curdt wrote:
>> On 04.03.2007, at 17:59, Reinhard Poetz wrote:
>>> Grzegorz Kossakowski wrote:
>>>> Reinhard Poetz napisał(a):
>>>>>
>>>>> Just a warning, AFAICS it's not a "drop-in replacement" because
>>>>> of some API changes.
>>>> Thanks for fixing this. Unfortunately, nothing changed after
>>>> replacing jci with the current trunk. Still class reloading does
>>>> not work while running outside the Eclipse and still there is
>>>> problem with "Scheme change not implemented".
>>>
>>> I hope that Torsten will find some time to help us as soon as jci
>>> got released.
>> Sure will try ...actually adopting to the API changes would be
>> good to do before the release of jci.
>
> already done
Seriously? That would be awesome! :)
cheers
--
Torsten
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>
> On 04.03.2007, at 17:59, Reinhard Poetz wrote:
>
>> Grzegorz Kossakowski wrote:
>>> Reinhard Poetz napisał(a):
>>>>
>>>> Just a warning, AFAICS it's not a "drop-in replacement" because of
>>>> some API changes.
>>> Thanks for fixing this. Unfortunately, nothing changed after
>>> replacing jci with the current trunk. Still class reloading does not
>>> work while running outside the Eclipse and still there is problem
>>> with "Scheme change not implemented".
>>
>> I hope that Torsten will find some time to help us as soon as jci got
>> released.
>
> Sure will try ...actually adopting to the API changes would be good to
> do before the release of jci.
already done
--
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
Re: Reloading Classloader Plugin
Posted by Torsten Curdt <tc...@apache.org>.
On 04.03.2007, at 17:59, Reinhard Poetz wrote:
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz napisał(a):
>>>
>>> Just a warning, AFAICS it's not a "drop-in replacement" because
>>> of some API changes.
>> Thanks for fixing this. Unfortunately, nothing changed after
>> replacing jci with the current trunk. Still class reloading does
>> not work while running outside the Eclipse and still there is
>> problem with "Scheme change not implemented".
>
> I hope that Torsten will find some time to help us as soon as jci
> got released.
Sure will try ...actually adopting to the API changes would be good
to do before the release of jci.
cheers
--
Torsten
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>>
>> Just a warning, AFAICS it's not a "drop-in replacement" because of
>> some API changes.
> Thanks for fixing this. Unfortunately, nothing changed after replacing
> jci with the current trunk. Still class reloading does not work while
> running outside the Eclipse and still there is problem with "Scheme
> change not implemented".
I hope that Torsten will find some time to help us as soon as jci got released.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Reloading Classloader Plugin
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz napisał(a):
>
> Just a warning, AFAICS it's not a "drop-in replacement" because of
> some API changes.
Thanks for fixing this. Unfortunately, nothing changed after replacing
jci with the current trunk. Still class reloading does not work while
running outside the Eclipse and still there is problem with "Scheme
change not implemented".
--
Grzegorz Kossakowski
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Torsten Curdt napisał(a):
>>
>> Definitely! ...please use latest trunk!
>>
> No problem. Howver, root pom of commons-jci is broken, you have "jci" as
> artifactId but it should be "commons-jci".
> I had to disable tests because many of them fail. Is it known issue?
>
> Now going to test it...
Just a warning, AFAICS it's not a "drop-in replacement" because of some API changes.
--
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
Re: Reloading Classloader Plugin
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Torsten Curdt napisał(a):
>
> Definitely! ...please use latest trunk!
>
No problem. Howver, root pom of commons-jci is broken, you have "jci" as
artifactId but it should be "commons-jci".
I had to disable tests because many of them fail. Is it known issue?
Now going to test it...
--
Grzegorz Kossakowski
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Torsten Curdt wrote:
>>> BTW, where did you get the commons-jci dependency from? Did you build
>>> it from SVN?
>>>
>> Huh? Am I supposed to do this?
>>
>> I just fired mvn install and got this:
>>
>> Downloading:
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci-core-1.0-20061102.202514-6.pom
>>
>> Downloading:
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci/1.0-SNAPSHOT/commons-jci-1.0-20061102.202514-6.pom
>>
>> Downloading:
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci-fam-1.0-20061102.202514-4.pom
>>
>> Downloading:
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci-core-1.0-20061102.202514-6.jar
>>
>> Downloading:
>> http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci-fam-1.0-20061102.202514-4.jar
>>
>>
>> Should I use newer version?
>
> Definitely! ...please use latest trunk!
I've put the tests with the latest SVN snapshot on my todo list for the next days.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Reloading Classloader Plugin
Posted by Torsten Curdt <tc...@apache.org>.
>> BTW, where did you get the commons-jci dependency from? Did you
>> build it from SVN?
>>
> Huh? Am I supposed to do this?
>
> I just fired mvn install and got this:
>
> Downloading: http://people.apache.org/repo/m2-snapshot-repository/
> org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci-
> core-1.0-20061102.202514-6.pom
> Downloading: http://people.apache.org/repo/m2-snapshot-repository/
> org/apache/commons/commons-jci/1.0-SNAPSHOT/commons-
> jci-1.0-20061102.202514-6.pom
> Downloading: http://people.apache.org/repo/m2-snapshot-repository/
> org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci-
> fam-1.0-20061102.202514-4.pom
> Downloading: http://people.apache.org/repo/m2-snapshot-repository/
> org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci-
> core-1.0-20061102.202514-6.jar
> Downloading: http://people.apache.org/repo/m2-snapshot-repository/
> org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci-
> fam-1.0-20061102.202514-4.jar
>
> Should I use newer version?
Definitely! ...please use latest trunk!
cheers
--
Torsten
Re: Reloading Classloader Plugin
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz napisał(a):
> 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.
>
Ehkm, I don't use Eclipse Jetty plugin. I use Jetty 6 configured as
explained here:
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g4/g1/1301.html
and if I click on the "Continue" button changes do not take effect. I
have to restart.
>> 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 ;-)
Yeah, but my CLA has been faxed only few minutes ago so I guess will
have to wait couple of days to have commit rights.
>
> BTW, where did you get the commons-jci dependency from? Did you build
> it from SVN?
>
Huh? Am I supposed to do this?
I just fired mvn install and got this:
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci-core-1.0-20061102.202514-6.pom
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci/1.0-SNAPSHOT/commons-jci-1.0-20061102.202514-6.pom
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci-fam-1.0-20061102.202514-4.pom
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-core/1.0-SNAPSHOT/commons-jci-core-1.0-20061102.202514-6.jar
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/commons/commons-jci-fam/1.0-SNAPSHOT/commons-jci-fam-1.0-20061102.202514-4.jar
Should I use newer version?
--
Grzegorz Kossakowski
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
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
--------------------------------------------------------------------
Re: Reloading Classloader Plugin
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
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.
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.
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.
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.
--
Grzegorz Kossakowski
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Using the reloading-classloader-plugin you can run a block as the
>> plugin creates a default Cocoon webapp and deploys the block into it.
>> And, as the blocks name conveys, it takes care that you can work on
>> Cocoon resources and Java sources while they get reloaded
>> transparently.
>> (http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1295.html)
>>
> Instructions you gave are pretty unclear.
> 1. You assume that directory structure is as described here:
> http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1159.html but
> you don't mention it anywhere in your instructions.
ok. will add it
> 2. In second step where this plug-in information should be added? To the
> block's pom or webapp's pom?
to the block's pom.
> 3. Should third step be under some circumstances?
You only need to run it when you change the pom.xml or the rcl.properties.
> 4. In fourth two projects will be created. Which one to import (as you
> use singular form here)
again the block
> 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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Reloading Classloader Plugin
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz napisał(a):
> Using the reloading-classloader-plugin you can run a block as the
> plugin creates a default Cocoon webapp and deploys the block into it.
> And, as the blocks name conveys, it takes care that you can work on
> Cocoon resources and Java sources while they get reloaded
> transparently.
> (http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1295.html)
>
Instructions you gave are pretty unclear.
1. You assume that directory structure is as described here:
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1159.html but
you don't mention it anywhere in your instructions.
2. In second step where this plug-in information should be added? To the
block's pom or webapp's pom?
3. Should third step be under some circumstances?
4. In fourth two projects will be created. Which one to import (as you
use singular form here)
5. Finally, fifth step. Should clean and package goals be omitted while
calling jetty:run goal?
I tried to guess the answers but did not managed to make it working.
--
Grzegorz Kossakowski
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Reinhard Poetz wrote:
>> Giacomo Pati wrote:
>>
>>> How is the rcl-plugin related/overlapping with the deployer-plugin?
>>>
>>> I've put some work making the deployer-plugin usable for block
>>> development and now I'm asking
>>> whether that work is becoming obsolete and I should migrate ev.
>>> missing features into the rcl-plugin
>> I've started from scratch because the deployer-plugin contains some (a
>> lot of?) unused stuff and I want to clean up when we merge them.
>>
>> What features of the deployer-plugin do you use?
>
> applying xpatches
> the ability to configure a custom log4j.xml
> and probably others I cannot remember now.
and the optional use of the shielding classloader should complete the list.
- o -
The reloading classloader stuff becomes useful if you want to run a block, the
deployer if you want to create a web application. I propose that we start from
the reloading classloader stuff and merge the missing functionality from the
deployer modules into it.
The perfekt solution would even go one step further and abstract the deployer
from Maven so that somebody could write an Ant task. I'm not sure if I will have
time for this extra round.
As already said, I plan to have a first milestone release by the end of March,
provided that commons-jci will be propertly relased by then.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Reloading Classloader Plugin
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reinhard Poetz wrote:
> Giacomo Pati wrote:
>
>> How is the rcl-plugin related/overlapping with the deployer-plugin?
>>
>> I've put some work making the deployer-plugin usable for block
>> development and now I'm asking
>> whether that work is becoming obsolete and I should migrate ev.
>> missing features into the rcl-plugin
>
> I've started from scratch because the deployer-plugin contains some (a
> lot of?) unused stuff and I want to clean up when we merge them.
>
> What features of the deployer-plugin do you use?
applying xpatches
the ability to configure a custom log4j.xml
and probably others I cannot remember now.
Ciao
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)
iD8DBQFF68hOLNdJvZjjVZARAp3+AKCy4RkbpahjJbPZtKX1gbRg6g6NtwCdEQNv
21eyG9inKJ7LDiXpTcR0/ZE=
=v+5e
-----END PGP SIGNATURE-----
Re: Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Giacomo Pati wrote:
> How is the rcl-plugin related/overlapping with the deployer-plugin?
>
> I've put some work making the deployer-plugin usable for block development and now I'm asking
> whether that work is becoming obsolete and I should migrate ev. missing features into the rcl-plugin
I've started from scratch because the deployer-plugin contains some (a lot of?)
unused stuff and I want to clean up when we merge them.
What features of the deployer-plugin do you use?
--
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
Re: Reloading Classloader Plugin
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Reinhard Poetz wrote:
> Joerg Heinicke wrote:
>
>>> We only have to ensure that the samples blocks (e.g.
>>> cocoon-forms-samples) works with the reloading classloader plugin so
>>> that cforms developers can easily continue their work.
>>
>> ??
>
> Using the reloading-classloader-plugin you can run a block as the plugin
> creates a default Cocoon webapp and deploys the block into it. And, as
> the blocks name conveys, it takes care that you can work on Cocoon
> resources and Java sources while they get reloaded transparently.
> (http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1295.html)
How is the rcl-plugin related/overlapping with the deployer-plugin?
I've put some work making the deployer-plugin usable for block development and now I'm asking
whether that work is becoming obsolete and I should migrate ev. missing features into the rcl-plugin
>
> I would also be interested in some feedback as I want to release it as
> soon as Torsten has finished a Commons JCI release.
>
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (GNU/Linux)
iD8DBQFF6flPLNdJvZjjVZARAqfnAKCCRYC4VvL1/0NHADwnmmHXlsjDVQCgnFdN
kJc0ry3q+UY4dHTF8QKuy4g=
=lZl0
-----END PGP SIGNATURE-----
Reloading Classloader Plugin
Posted by Reinhard Poetz <re...@apache.org>.
Joerg Heinicke wrote:
>> We only have to ensure that the samples blocks (e.g.
>> cocoon-forms-samples) works with the reloading classloader plugin so
>> that cforms developers can easily continue their work.
>
> ??
Using the reloading-classloader-plugin you can run a block as the plugin creates
a default Cocoon webapp and deploys the block into it. And, as the blocks name
conveys, it takes care that you can work on Cocoon resources and Java sources
while they get reloaded transparently.
(http://cocoon.zones.apache.org/daisy/cdocs-rcl-plugin/g1/1295.html)
I would also be interested in some feedback as I want to release it as soon as
Torsten has finished a Commons JCI release.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Sharing blocks between trunk and branch_2.1
Posted by Joerg Heinicke <jo...@gmx.de>.
On 02.03.2007 15:32, Reinhard Poetz wrote:
>> I fear that the most difficult task will be encouraging you to stop
>> sharing forms and ajax blocks between trunk and 2.1.x branch. On the
>> other hand, I can live with that stuff in patches/whiteboard if you wish.
>
> I propose that we stop sharing blocks between 2.1 and trunk with the
> upcoming 2.1.11 release.
+1 (finally)
> We only have to ensure that the samples blocks (e.g.
> cocoon-forms-samples) works with the reloading classloader plugin so
> that cforms developers can easily continue their work.
??
Jörg
Re: Sharing blocks between trunk and branch_2.1
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
>
>
> Reinhard Poetz wrote:
>> I propose that we stop sharing blocks between 2.1 and trunk with the
>> upcoming 2.1.11 release.
>>
>> We only have to ensure that the samples blocks (e.g.
>> cocoon-forms-samples) works with the reloading classloader plugin so
>> that cforms developers can easily continue their work.
>>
>> WDOT?
>>
> Heck, I always thought it was a bad idea.
I don't think that anybody was really fond of using svn:externals because it
makes tagging a tedious work and slows down all svn commands.
On the other hand it saved us a lot of work ...
All in all it was the best available alternative
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Sharing blocks between trunk and branch_2.1
Posted by Ralph Goers <Ra...@dslextreme.com>.
Reinhard Poetz wrote:
> I propose that we stop sharing blocks between 2.1 and trunk with the
> upcoming 2.1.11 release.
>
> We only have to ensure that the samples blocks (e.g.
> cocoon-forms-samples) works with the reloading classloader plugin so
> that cforms developers can easily continue their work.
>
> WDOT?
>
Heck, I always thought it was a bad idea. But since I don't typically
work on any of those blocks I've always abstained.
So +0
Ralph
Sharing blocks between trunk and branch_2.1
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> I fear that the most difficult task will be encouraging you to stop
> sharing forms and ajax blocks between trunk and 2.1.x branch. On the
> other hand, I can live with that stuff in patches/whiteboard if you wish.
I propose that we stop sharing blocks between 2.1 and trunk with the upcoming
2.1.11 release.
We only have to ensure that the samples blocks (e.g. cocoon-forms-samples) works
with the reloading classloader plugin so that cforms developers can easily
continue their work.
WDOT?
--
Reinhard
Re: Preparing Cocoon 2.2RC1
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Reinhard Poetz napisał(a):
>
> What are our plans for the next series of releases? I want to see it
> happen in the last week of March.
>
> For my part I will work on getting the documentation published which
> will include a proper release (alpha, beta or whatever the Daisy
> community prefers) of the daisy-maven plugin.
>
> What else needs to be done by then? What are your plans?
>
I was planning to work on the servlet service stuff, especially
implementing postable source. I would like also to present all the
functionality on the forms+ajax+flowscript+templates example by
converting all the samples. In the meantime, I was planning to write the
tutorial that I've promised to write.
To sum up, if I will be able to give Cocoon enough time I will touch
only core modules and blocks that I've mentioned earlier.
I fear that the most difficult task will be encouraging you to stop
sharing forms and ajax blocks between trunk and 2.1.x branch. On the
other hand, I can live with that stuff in patches/whiteboard if you wish.
--
Grzegorz Kossakowski