[jira] Updated: (COCOON-2007) cocoon-block-deployer plugin falis to build war file

[Felix Knecht (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COCOON-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Knecht updated COCOON-2007:
-

Attachment: deployer-pom.diff

patch for cocoon-block-deployer pom.xml

> cocoon-block-deployer plugin falis to build war file
> 
>
> Key: COCOON-2007
> URL: https://issues.apache.org/jira/browse/COCOON-2007
> Project: Cocoon
>  Issue Type: Bug
>  Components: * Cocoon Core
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Felix Knecht
>Priority: Critical
> Fix For: 2.2-dev (Current SVN)
>
> Attachments: deployer-pom.diff
>
>
> cocoon-block-deployer plugin can't build war file probably because of version 
> mismatch of dependency in cocoon-block-deployer pom (2.0.1) and root pom 
> pluginManagement (2.0.2).
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Internal error in the plugin manager executing goal 
> 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the 
> mojo 'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 
> 'org.apache.maven.plugins:maven-war-plugin'
> Component descriptor cannot be found in the component repository: 
> org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-war-plugin:2.0.1:war.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (COCOON-2007) cocoon-block-deployer plugin falis to build war file

[Felix Knecht (JIRA)]

cocoon-block-deployer plugin falis to build war file


 Key: COCOON-2007
 URL: https://issues.apache.org/jira/browse/COCOON-2007
 Project: Cocoon
  Issue Type: Bug
  Components: * Cocoon Core
Affects Versions: 2.2-dev (Current SVN)
Reporter: Felix Knecht
Priority: Critical
 Fix For: 2.2-dev (Current SVN)


cocoon-block-deployer plugin can't build war file probably because of version 
mismatch of dependency in cocoon-block-deployer pom (2.0.1) and root pom 
pluginManagement (2.0.2).

[ERROR] BUILD ERROR
[INFO] 
[INFO] Internal error in the plugin manager executing goal 
'org.apache.maven.plugins:maven-war-plugin:2.0.1:war': Unable to find the mojo 
'org.apache.maven.plugins:maven-war-plugin:2.0.1:war' in the plugin 
'org.apache.maven.plugins:maven-war-plugin'
Component descriptor cannot be found in the component repository: 
org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-war-plugin:2.0.1:war.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Releasing from trunk

[Jorg Heymans]

Vadim Gritsenko wrote:



#!/bin/bash
rm -fr ~/.m2/repository


Or:
  rm -rf ~/.m2/repository/org/apache/cocoon


possibly yes. I'm still debating the usefulness of downloading 
everything new each time. It was useful back in the days where existing 
poms were updated, they seem to have this under control now.



cd src/cocoon-trunk
svn update
mvn clean install > ~/cocoon-build.log 2>&1
if [ "$?" -ne "0" ]; then
  some_mail_foo_to_send_the_file_to_dev@


It's actually simple...

MAILFILE=/home/vadim/cocoon-test-mail-`date '+%Y%m%d'`.txt
echo "From: Vadim Gritsenko <[EMAIL PROTECTED]>"  >  
$MAILFILE
echo Subject: Cocoon-2.1.X Tests Failure `date '+%m/%d/%y'` >> 
$MAILFILE

...
mail -t dev@cocoon.apache.org < $MAILFILE


fi


Thanks!


Jorg

Re: Releasing from trunk

[Vadim Gritsenko]

Jorg Heymans wrote:
So for me, currently, the best solution ATM for CI would be to cron 
something like this:


#!/bin/bash
rm -fr ~/.m2/repository


Or:
  rm -rf ~/.m2/repository/org/apache/cocoon


cd src/cocoon-trunk
svn update
mvn clean install > ~/cocoon-build.log 2>&1
if [ "$?" -ne "0" ]; then
  some_mail_foo_to_send_the_file_to_dev@


It's actually simple...

MAILFILE=/home/vadim/cocoon-test-mail-`date '+%Y%m%d'`.txt
echo "From: Vadim Gritsenko <[EMAIL PROTECTED]>"  >  $MAILFILE
echo Subject: Cocoon-2.1.X Tests Failure `date '+%m/%d/%y'` >> $MAILFILE
...
mail -t dev@cocoon.apache.org < $MAILFILE


fi


Vadim, didn't you have something similar running for Cocoon 2.1 ?


I did but it was largely ignored. :) hm. :(

I also had clover reports on top.

Vadim


Regards
Jorg

[1] https://hudson.dev.java.net/
[2] 
http://weblogs.java.net/blog/kohsuke/archive/2007/02/maven_2_integra.html

Re: Releasing from trunk

[Jorg Heymans]

Vadim Gritsenko wrote:

Continuum was stopped because I started to flatten the POM hierarchy 
in trunk. This will hopefully save me a lot of time during the release 
process.


Do I understand it correctly - it should be turned off to simplify 
release process? Sounds Ok to me if that's the case.


Continuum is a nice-to-have but by no means a requirement for any 
release of cocoon. The general idea, as i'm sure i don't have to 
explain, is only to have something flag when someone checks in code that 
breaks the build.



-o0o-

At the time, Continuum seemed like an obvious choice for CI, mainly 
because it was built by the maven developers and promised/claimed good 
integration with m2. However now that we've learned the tricks and 
quirks of building an m2 project i can honestly not say anymore if 
Continuum is the best tool for the job ATM.


The problem with Continuum is that it doesn't build your project as a 
whole anymore, but rather the modules in relative isolation. The fact 
that it doesn't pick up pom changes and barfs when you do module 
refactoring (move, adding, removing, changing name etc) makes it more of 
a nuisance than anything else. A CI system is no good if you have to 
take care of it each time you change the structure of your system.


I've heard good things about Hudson [1], which has a more traditional 
approach in that it does a build from the top level (eg mvn clean 
install from the root) each time. This is more time and resource 
consuming but ATM more accurate for us. However its native m2 support is 
still in its infancy [2].


So for me, currently, the best solution ATM for CI would be to cron 
something like this:


#!/bin/bash
rm -fr ~/.m2/repository
cd src/cocoon-trunk
svn update
mvn clean install > ~/cocoon-build.log 2>&1
if [ "$?" -ne "0" ]; then
  some_mail_foo_to_send_the_file_to_dev@
fi


Vadim, didn't you have something similar running for Cocoon 2.1 ?

Regards
Jorg

[1] https://hudson.dev.java.net/
[2] 
http://weblogs.java.net/blog/kohsuke/archive/2007/02/maven_2_integra.html

Re: continuum put offline

[Jorg Heymans]

Reinhard Poetz wrote:

Jorg Heymans wrote:

Hi,

I've killed off the instance as obviously it can't cope with 
Reinhard's recent structural refactorings. I'll see about rebuilding 
in the next few weeks unless someone beats me to it.


What needs to be done for a rebuild? I would remove all projects and 
create the new ones based on the root pom. This create all our sub 
modules as Continuum projects again, doesn't it?




Normally it should yes. See my other mail in the "Releasing from trunk" 
thread.



Jorg

[jira] Closed: (COCOON-2005) Cocoon's build broken due to invalid parent in cocoon-samples-style-default's pom

[Reinhard Poetz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COCOON-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz closed COCOON-2005.
--

Resolution: Fixed

should work now. please crosscheck. thanks!

> Cocoon's build broken due to invalid parent in cocoon-samples-style-default's 
> pom
> -
>
> Key: COCOON-2005
> URL: https://issues.apache.org/jira/browse/COCOON-2005
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski (aka g[R]eK)
> Assigned To: Reinhard Poetz
>Priority: Blocker
> Fix For: 2.2-dev (Current SVN)
>
> Attachments: cocoon-samples-style-broken-pom.patch
>
>
> While flattening poms it was missed to change parent pom of 
> cocoon-samples-style-default module.
> Attached patch fixes this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (COCOON-2005) Cocoon's build broken due to invalid parent in cocoon-samples-style-default's pom

[Reinhard Poetz (JIRA)]

 [ 
https://issues.apache.org/jira/browse/COCOON-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Reinhard Poetz reassigned COCOON-2005:
--

Assignee: Reinhard Poetz

> Cocoon's build broken due to invalid parent in cocoon-samples-style-default's 
> pom
> -
>
> Key: COCOON-2005
> URL: https://issues.apache.org/jira/browse/COCOON-2005
> Project: Cocoon
>  Issue Type: Bug
>  Components: - Build System: Maven
>Affects Versions: 2.2-dev (Current SVN)
>Reporter: Grzegorz Kossakowski (aka g[R]eK)
> Assigned To: Reinhard Poetz
>Priority: Blocker
> Fix For: 2.2-dev (Current SVN)
>
> Attachments: cocoon-samples-style-broken-pom.patch
>
>
> While flattening poms it was missed to change parent pom of 
> cocoon-samples-style-default module.
> Attached patch fixes this problem.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Releasing from trunk

[Vadim Gritsenko]

Carsten Ziegeler wrote:

Reinhard Poetz wrote:

Carsten Ziegeler wrote:


Anyways, I'm a little bit clueless how to continue. Some of us say,
let's call it RC, some say no as "things are missing". 
Since writing more mails would take longer than releasing another series of core 
milestone releases, I will release cocoon-core-2.2 as M3.



:) It would be great, if we could at least release the configurator as
final (as proposed).


+1 here.

Vadim

Re: Releasing from trunk

[Vadim Gritsenko]

Reinhard Poetz wrote:

Vadim Gritsenko wrote:
Regardless of download presence, at the very least there should be a 
2.2 site set up and running.

  http://cocoon.apache.org/2.2/


IMNSHO we don't have http://cocoon.apache.org/2.2/ anymore. Information 
about the core will be available at 
http://cocoon.apache.org/core-modules/core/2.2/
(see http://cocoon.zones.apache.org/dev-docs/core-modules/core/2.2/ to 
get an idea of the big picture)


Actually... About the big picture, I'm not sure I'm getting it. The current site 
structure is:


  /  - Cocoon Project (PMC) site
  /1.x   - Cocoon 1.x site
  /2.0   - ...
  /2.1

So from the POV of top level site, what is Cocoon 2.2 - where should it be in 
the list of "Projects". Is it "Cocoon NG" project?


Does it mean there is no "root" path for Cocoon 2.2 docs - they are all 
scattered around PMC site? (I'm assuming here that /core-modules is not the only 
path element used in 2.2 docs).


Where would (radically different, hypothetical) Cocoon 3.0 go if Cocoon 2.2 will 
take unversioned http://cocoon.apache.org/core-modules/ space? Keep in mind that 
copy of 2.2.Last docs will have to be accessible after 3.0 goes gold.


Vadim

[jira] Subscription: COCOON-open-with-patch

[jira]

Issue Subscription
Filter: COCOON-open-with-patch (97 issues)
Subscriber: cocoon


Key Summary
COCOON-2005 Cocoon's build broken due to invalid parent in 
cocoon-samples-style-default's pom
https://issues.apache.org/jira/browse/COCOON-2005
COCOON-2002 HTML transformer  only works with latin-1 characters
https://issues.apache.org/jira/browse/COCOON-2002
COCOON-1997 Configure servlet: links rewriting
https://issues.apache.org/jira/browse/COCOON-1997
COCOON-1996 New input module: StringConcatMetaModule
https://issues.apache.org/jira/browse/COCOON-1996
COCOON-1994 Make Forms resources loaded directly
https://issues.apache.org/jira/browse/COCOON-1994
COCOON-1993 Make Forms resources loaded directly
https://issues.apache.org/jira/browse/COCOON-1993
COCOON-1992 Make Ajax resourced loaded directly from cocoon-ajax-impl
https://issues.apache.org/jira/browse/COCOON-1992
COCOON-1974 Donating ContextAttributeInputModule
https://issues.apache.org/jira/browse/COCOON-1974
COCOON-1973 CaptchaValidator: allow case-insensitive matching
https://issues.apache.org/jira/browse/COCOON-1973
COCOON-1964 Redirects inside a block called via the blocks protocol fail
https://issues.apache.org/jira/browse/COCOON-1964
COCOON-1963 Add a redirect action to the browser update handler
https://issues.apache.org/jira/browse/COCOON-1963
COCOON-1960 Pipeline errors for "generator/reader already set" should provide 
more information
https://issues.apache.org/jira/browse/COCOON-1960
COCOON-1955 [Patch] Allow shielded class loading for a single block
https://issues.apache.org/jira/browse/COCOON-1955
COCOON-1954 [Patch] RequestProcessor swallows exceptions in blocks case
https://issues.apache.org/jira/browse/COCOON-1954
COCOON-1949 [PATCH] load flowscript from file into specified Rhino context 
object
https://issues.apache.org/jira/browse/COCOON-1949
COCOON-1946 [PATCH] - Javaflow Sample errors trying to enhance Javaflow classes 
and showing cform templates
https://issues.apache.org/jira/browse/COCOON-1946
COCOON-1932 [PATCH] correct styling of disabled suggestion lists
https://issues.apache.org/jira/browse/COCOON-1932
COCOON-1929 [PATCH] Reloading classloader in Cocoon 2.2
https://issues.apache.org/jira/browse/COCOON-1929
COCOON-1917 Request Encoding problem: multipart/form vs. url encoded
https://issues.apache.org/jira/browse/COCOON-1917
COCOON-1915 Nullable value with additional String or XMLizable in 
JavaSelectionList
https://issues.apache.org/jira/browse/COCOON-1915
COCOON-1914 Text as XMLizable in EmptySelectionList
https://issues.apache.org/jira/browse/COCOON-1914
COCOON-1899 [PATCH] Cocoon XML:DB Implementation should not depend on Xindice
https://issues.apache.org/jira/browse/COCOON-1899
COCOON-1898 [PATCH] XPatch support for maven-cocoon-deployer-plugin
https://issues.apache.org/jira/browse/COCOON-1898
COCOON-1893 XML-Binding: Problem creating a new element
https://issues.apache.org/jira/browse/COCOON-1893
COCOON-1887 Host selector should be case insensitive
https://issues.apache.org/jira/browse/COCOON-1887
COCOON-1877 [PATCH] Pageable Repeater
https://issues.apache.org/jira/browse/COCOON-1877
COCOON-1870 Lucene block does not store attributes when instructed so
https://issues.apache.org/jira/browse/COCOON-1870
COCOON-1846 [PATCH] BooleanField and radio do not send on-value-changed at the 
rigth time with IE
https://issues.apache.org/jira/browse/COCOON-1846
COCOON-1843 LDAPTransformer: add-entry tag doesn't work
https://issues.apache.org/jira/browse/COCOON-1843
COCOON-1842 LDAPTransformer: ClassCastException with Binary fields
https://issues.apache.org/jira/browse/COCOON-1842
COCOON-1838 Always use 3-digit version number
https://issues.apache.org/jira/browse/COCOON-1838
COCOON-1810 [PATCH] JMSEventMessageListener does not work
https://issues.apache.org/jira/browse/COCOON-1810
COCOON-1807 Workaround for IE Bug in 
https://issues.apache.org/jira/browse/COCOON-1807
COCOON-1794 [PATCH] Propagation of namespaces to a repeaters child bindings and 
implementation of a move-node binding
https://issues.apache.org/jira/browse/COCOON-1794
COCOON-1738 double-listbox problem in repeaters
https://issues.apache.org/jira/browse/COCOON-1738
COCOON-1726 Implementation of Source that supports conditional GETs
https://issues.apache.org/jira/browse/COCOON-1726
COCOON-1717 Use custom cache keys for caching uri coplets using input modules.
https://issues.apache.org/jira/browse/COCOON-1717
COCOON-1703 A patch for caching fonts (fixes GDI issues), vertical text 
orientation, color code fix, prefered unit for margins an

Re: Block Docs

[Vadim Gritsenko]

Reinhard Poetz wrote:

Vadim Gritsenko wrote:

Simone Gianni wrote:

Can someone point me to the right documentation branch where I should
update documentation?


I'd guess it should be "cdocs: Profiler Block", but it is not listed on:

Not sure how easy/hard it is to add it there... Reinhard?


It takes you about 15 minutes ...


Thanks. Simone - you can edit/add profiler docos here:

  http://cocoon.zones.apache.org/daisy/cdocs-profiler/g1/1322.html

Vadim

Re: Releasing from trunk

[Carsten Ziegeler]

Reinhard Poetz wrote:
> Carsten Ziegeler wrote:
> 
> [...]
> 
>> Anyways, I'm a little bit clueless how to continue. Some of us say,
>> let's call it RC, some say no as "things are missing". 
> 
> Since writing more mails would take longer than releasing another series of 
> core 
> milestone releases, I will release cocoon-core-2.2 as M3.
> 
:) It would be great, if we could at least release the configurator as
final (as proposed).

Carsten

-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

Re: [graphics] New version of masthead - update

[hepabolu]

Vadim Gritsenko said the following on 7/2/07 16:11:

hepabolu wrote:

Awesome! Looks good ... but ... is that a page curl beside "What is
Apache Cocoon" ? *shudder*


I suppose it is. I think it's very well done, no tackiness about it.
What makes you shudder?


I'm not crazy about this page curl as well... Would it perhaps be better 
to move both "What is Apache Cocoon?" and next one to the separate 
"About" page?


The page curl: I'll leave that to Thien.

The content of the box: I think you need to have it there, maybe not in 
full but as a first time visitor I want to know what I'm looking at and 
if it's on the front page, I get my questions solved in seconds which 
gives me a good impression of the project.


Bye, Helma

Re: Releasing from trunk

[Reinhard Poetz]

Vadim Gritsenko wrote:

Reinhard Poetz wrote:

Vadim Gritsenko wrote:


It is a bit different for 2.2 though: there were no "real" 
downloadable release yet, 


And maybe there will never be one. Don't know. There doesn't seem to 
be much energy in this community to provide it - especially if you use 
Maven 2 you don't need it.


If using maven 2, might be, yes.

Regardless of download presence, at the very least there should be a 2.2 
site set up and running.

  http://cocoon.apache.org/2.2/


IMNSHO we don't have http://cocoon.apache.org/2.2/ anymore. Information about 
the core will be available at http://cocoon.apache.org/core-modules/core/2.2/
(see http://cocoon.zones.apache.org/dev-docs/core-modules/core/2.2/ to get an 
idea of the big picture)


Next, announcements has to be sent out. It should go out to [EMAIL PROTECTED] 
as well.

  http://marc.theaimsgroup.com/?l=xml-apache-announce&m=105161222423468

How else people would know about new release if it is not mentioned 
anywhere?


ok

so there is really no easy way to download 2.2 and give it a spin on 
existing 2.1 project.


That's not true. What's missing is a guide how to do it. Technically 
it shouldn't be too difficult.


It's not difficult if you know it all. It is not trivial for users, 
especially with no Spring exposure.




  * have CC working and not failing over,


Continuum was stopped because I started to flatten the POM hierarchy 
in trunk. This will hopefully save me a lot of time during the release 
process.


Do I understand it correctly - it should be turned off to simplify 
release process? Sounds Ok to me if that's the case.


No. I removed about 7 modules from our repository (see the commit messages with 
a "flatten pom hierarchy" description) and Continuum still tried to build them. 
It has to be reconfigured but anybody hasn't had time to do it yet.


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


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

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

Re: Releasing from trunk

[Andrew Savory]

Hi,

On 7 Feb 2007, at 14:01, Carsten Ziegeler wrote:
Now, I will ask the open question right away: who will work on the  
missing parts?


FX: TUMBLEWEED

Gosh, no rush of people to say "I will!" ;-)


On 7 Feb 2007, at 14:49, Reinhard Poetz wrote:

From my experience over the last months, I'd say that there isn't  
much energy for actual work, especially nobody wants to work on the  
documentation.


If you have noclue what to write, you could start to write a  
migration guide. Or look at the existing documentation and continue  
with the docs migration.


FYI, I'm working on just such a document now, outlining what's  
changed, how to migrate, all the relevant stuff for the end user.


I'm still trying to figure out what's best practice for things like  
application-specific sitemaps, where to put things etc. I hope to get  
a first draft in Daisy by the end of the weekend. But if we get as  
much snow as predicted, it may be delayed by igloo-building :-)



Thanks,

Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Sourcesense: http://www.sourcesense.com/

Re: Releasing from trunk

[Vadim Gritsenko]

Reinhard Poetz wrote:

Vadim Gritsenko wrote:


It is a bit 
different for 2.2 though: there were no "real" downloadable release yet, 


And maybe there will never be one. Don't know. There doesn't seem to be 
much energy in this community to provide it - especially if you use 
Maven 2 you don't need it.


If using maven 2, might be, yes.

Regardless of download presence, at the very least there should be a 2.2 site 
set up and running.

  http://cocoon.apache.org/2.2/

Next, announcements has to be sent out. It should go out to [EMAIL PROTECTED] 
as well.
  http://marc.theaimsgroup.com/?l=xml-apache-announce&m=105161222423468

How else people would know about new release if it is not mentioned anywhere?


so there is really no easy way to download 2.2 and give it a spin on 
existing 2.1 project.


That's not true. What's missing is a guide how to do it. Technically it 
shouldn't be too difficult.


It's not difficult if you know it all. It is not trivial for users, especially 
with no Spring exposure.




  * have CC working and not failing over,


Continuum was stopped because I started to flatten the POM hierarchy in 
trunk. This will hopefully save me a lot of time during the release 
process.


Do I understand it correctly - it should be turned off to simplify release 
process? Sounds Ok to me if that's the case.


Vadim

Re: [graphics] New version of masthead - update

[Vadim Gritsenko]

hepabolu wrote:

Awesome! Looks good ... but ... is that a page curl beside "What is
Apache Cocoon" ? *shudder*


I suppose it is. I think it's very well done, no tackiness about it.
What makes you shudder?


I'm not crazy about this page curl as well... Would it perhaps be better to move 
both "What is Apache Cocoon?" and next one to the separate "About" page?


Vadim


Also, how would it look with Cocoon 2.1 somewhere in the top menubar
too?


True, that needs to be added.

Bye, Helma

Re: Releasing from trunk

[Reinhard Poetz]

Carsten Ziegeler wrote:

[...]


Anyways, I'm a little bit clueless how to continue. Some of us say,
let's call it RC, some say no as "things are missing". 


Since writing more mails would take longer than releasing another series of core 
milestone releases, I will release cocoon-core-2.2 as M3.



Now, I will ask
the open question right away: who will work on the missing parts?


From my experience over the last months, I'd say that there isn't much energy 
for actual work, especially nobody wants to work on the documentation.


If you have noclue what to write, you could start to write a migration guide. Or 
look at the existing documentation and continue with the docs migration.


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


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

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

Re: Releasing from trunk

[Reinhard Poetz]

Vadim Gritsenko wrote:

Carsten Ziegeler wrote:


[...]


We need to get a 2.2 out; imho it is more important to have something
out after so many years than having a 115% bug free version.


You are missing a point. It's not about a bug free version. It is about 
a version which seen more than like 4 hours of testing after major surgery.




In addition, there is no guarantee that releasing a milestone will bring
us more users testing, more documentation etc. And I personally doubt
that people will start trying a milestone release.


Counterpoint:
  http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=117024037825843

They are not even trying, they are using it in production. It is a bit 
different for 2.2 though: there were no "real" downloadable release yet, 


And maybe there will never be one. Don't know. There doesn't seem to be much 
energy in this community to provide it - especially if you use Maven 2 you don't 
need it.


so there is really no easy way to download 2.2 and give it a spin on 
existing 2.1 project.


That's not true. What's missing is a guide how to do it. Technically it 
shouldn't be too difficult.


High entry point would hamper wider adoption of 2.2, not the label on 
its release.




And what will be the exit criteria? When do we have enough confidence
(if it is really missing today) that we are stable enough for switching
from milestone to rc? We only have indicators and feelings. I think that
the current code base is stable and the work we are doing with is a
proof for this (for me).


When there is a consensus in the community that version is ready for RC 
or Final release. Given the responses so far, you already can see that 
to reach consensus we'd have to:


  * have some more testing done (not 4h or 1d as now),
  * have unit tests working,
  * have CC working and not failing over,


Continuum was stopped because I started to flatten the POM hierarchy in trunk. 
This will hopefully save me a lot of time during the release process.


[...]

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


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

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

Re: Block Docs

[Reinhard Poetz]

Vadim Gritsenko wrote:

Simone Gianni wrote:

Can someone point me to the right documentation branch where I should
update documentation?


I'd guess it should be "cdocs: Profiler Block", but it is not listed on:

  http://cocoon.zones.apache.org/daisy/

Not sure how easy/hard it is to add it there... Reinhard?


It takes you about 15 minutes and you need to be part of the suduers list of our 
zone, see http://cocoon.zones.apache.org/daisy/cdocs/g3/1223.html


If you want to be able to build the docs locally, see 
http://cocoon.zones.apache.org/daisy/cdocs/g3/1256.html. Takes you another 5 
minutes and about 8 minutes for the actual build process.


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


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

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

Re: Releasing from trunk

[Carsten Ziegeler]

Vadim Gritsenko wrote:
> You are missing a point. It's not about a bug free version. It is about a 
> version which seen more than like 4 hours of testing after major surgery.
> 
Sorry, but that's not fair. There were no code or api changes to the
core in the last weeks (apart from bug fixes). There were some
structural changes and continued work on the servlet-fw, but that is not
part of the things we want to release as rcs.

> 
>> In addition, there is no guarantee that releasing a milestone will bring
>> us more users testing, more documentation etc. And I personally doubt
>> that people will start trying a milestone release.
> 
> Counterpoint:
>http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=117024037825843
> 
> They are not even trying, they are using it in production. It is a bit 
> different 
> for 2.2 though: there were no "real" downloadable release yet, so there is 
> really no easy way to download 2.2 and give it a spin on existing 2.1 project.
> 
> High entry point would hamper wider adoption of 2.2, not the label on its 
> release.
Agreed.

> When there is a consensus in the community that version is ready for RC or 
> Final 
> release. Given the responses so far, you already can see that to reach 
> consensus 
> we'd have to:
> 
>* have some more testing done (not 4h or 1d as now),
>* have unit tests working,
>* have CC working and not failing over,
> 
Unit tests work.

> Do you mean to say you can't stop doing major refactoring and start polishing 
> unless it bears RC badge? What happened to good old-fashioned discipline and 
> self control? :)
"self control?" - what's that? :)

I meant that marking something RC has more or less the same effect as a
code freeze. So it "prevents" from changing and should streamline all
effort into getting that thing out of the door.

Anyways, I'm a little bit clueless how to continue. Some of us say,
let's call it RC, some say no as "things are missing". Now, I will ask
the open question right away: who will work on the missing parts?

Carsten
-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

[jira] Created: (COCOON-2006) ClassCastException in Rhino when creating a continuation in a catch block

[Rob Berens (JIRA)]

ClassCastException in Rhino when creating a continuation in a catch block
-

 Key: COCOON-2006
 URL: https://issues.apache.org/jira/browse/COCOON-2006
 Project: Cocoon
  Issue Type: Bug
  Components: - Flowscript
Affects Versions: 2.1.10
Reporter: Rob Berens


In our example we use a dialog from within a catch block in javascript e.g. to 
ask for confirmation if a file already exists. It looks like this:

try {
write file
catch (ex if ex.javaexception instanceof MyFileAlreadyExistsException) {
if (overwriteDialog("Overwrite")) {
overwrite file
 }
}

function overwriteDialog(message) {
var form = new Form("path/to/dialog.fd");
var formWidget = form.form;

formWidget.lookupWidget("message").setValue(message);
form.showForm("/flow/path/to/dialog.html");
return "ok".equals(form.submitId);
}

In the overwrite dialog a form is created and shown thereby effectively 
creating a continuation. Formerly when using 2.1.8 this worked fine. In 2.1.10 
we get a ClassCastException with the stack shown below.

When changing the code like this, there is no problem:

var exists = false;
try {
write file
catch (ex if ex.javaexception instanceof MyFileAlreadyExistsException) {
exists = true;
}

if (exists && overwriteDialog("Overwrite")) {
overwrite file
}

I did some investigation in Rhino and found out that the enterFrames as 
referred in org.mozilla.javascript.Interpreter at line 2407 contain a frame 
that has a scope of class NativeWith which in the end leads to the 
ClassCastException.


Thread [PoolThread-3] (Suspended (exception java.lang.ClassCastException))  

org.mozilla.javascript.ScriptRuntime.enterActivationFunction(org.mozilla.javascript.Context,
 org.mozilla.javascript.Scriptable) line: 2847  

org.mozilla.javascript.Interpreter.enterFrame(org.mozilla.javascript.Context, 
org.mozilla.javascript.Interpreter$CallFrame, java.lang.Object[]) line: 3855
  

org.mozilla.javascript.Interpreter.interpretLoop(org.mozilla.javascript.Context,
 org.mozilla.javascript.Interpreter$CallFrame, java.lang.Object) line: 2408 

org.mozilla.javascript.Interpreter.interpret(org.mozilla.javascript.InterpretedFunction,
 org.mozilla.javascript.Context, org.mozilla.javascript.Scriptable, 
org.mozilla.javascript.Scriptable, java.lang.Object[]) line: 2251   

org.mozilla.javascript.InterpretedFunction.call(org.mozilla.javascript.Context, 
org.mozilla.javascript.Scriptable, org.mozilla.javascript.Scriptable, 
java.lang.Object[]) line: 161 

org.mozilla.javascript.ContextFactory.doTopCall(org.mozilla.javascript.Callable,
 org.mozilla.javascript.Context, org.mozilla.javascript.Scriptable, 
org.mozilla.javascript.Scriptable, java.lang.Object[]) line: 340

org.mozilla.javascript.ScriptRuntime.doTopCall(org.mozilla.javascript.Callable, 
org.mozilla.javascript.Context, org.mozilla.javascript.Scriptable, 
org.mozilla.javascript.Scriptable, java.lang.Object[]) line: 2758

org.mozilla.javascript.InterpretedFunction.call(org.mozilla.javascript.Context, 
org.mozilla.javascript.Scriptable, org.mozilla.javascript.Scriptable, 
java.lang.Object[]) line: 159 

org.mozilla.javascript.Context.call(org.mozilla.javascript.ContextFactory, 
org.mozilla.javascript.Callable, org.mozilla.javascript.Scriptable, 
org.mozilla.javascript.Scriptable, java.lang.Object[]) line: 489 

org.mozilla.javascript.ScriptableObject.callMethod(org.mozilla.javascript.Context,
 org.mozilla.javascript.Scriptable, java.lang.String, java.lang.Object[]) line: 
1556  

org.mozilla.javascript.ScriptableObject.callMethod(org.mozilla.javascript.Scriptable,
 java.lang.String, java.lang.Object[]) line: 1526  

org.apache.cocoon.components.flow.javascript.fom.FOM_JavaScriptInterpreter.handleContinuation(java.lang.String,
 java.util.List, org.apache.cocoon.environment.Redirector) line: 842 

org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(org.apache.cocoon.environment.Environment,
 org.apache.cocoon.components.treeprocessor.InvokeContext) line: 124   

org.apache.cocoon.components.treeprocessor.sitemap.SelectNode(org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode).invokeNodes(org.apache.cocoon.components.treeprocessor.ProcessingNode[],
 org.apache.cocoon.environment.Environment, 
org.apache.cocoon.components.treeprocessor.InvokeContext) line: 69   

org.apache.cocoon.components.treeprocessor.sitemap.SelectNode.invoke(org.apache.cocoon.environment.Environment,
 org.apache.cocoon.components.treeprocessor.InvokeContext) line: 103 

org.apache.cocoon.components.treeprocessor.sitemap.MatchNode(org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode).invokeNodes(org.apac

Block Docs, Re: svn commit: r503964 - in /cocoon/trunk/blocks/cocoon-profiler/cocoon-profiler-impl/src/main: java/org/apache/cocoon/components/profiler/ resources/META-INF/cocoon/avalon/

[Vadim Gritsenko]

Simone Gianni wrote:

Hi all,
I was playing with the profiler when I noticed the way the
ProfilingXMLPipe works. Every component is given the opportunity to
stream its sax events, they are buffered in a DOM, the DOM is then used
(to display the intermediate XML and) to stream SAX events to the next
component. This behavior is different from how a pipeline normally
works, and can cause strange errors (or mask errors that will appear
when the profiler is removed).

So I implemented another class, the ProfilingSAXPipe, that does all the
ProfilingXMLPipe does, but stream the sax events directly, without
storing them in a DOM and doing it step by step. Time calculation is
obviously more complicated, and I'm not yet sure it's precise enough,
but seems to be consistent with the default implementation.

To activate it pass a sax-stream="true" on the pipeline definition, or
use the profile-caching-sax and profile-noncaching-sax pipeline types.

Can someone point me to the right documentation branch where I should
update documentation?


I'd guess it should be "cdocs: Profiler Block", but it is not listed on:

  http://cocoon.zones.apache.org/daisy/

Not sure how easy/hard it is to add it there... Reinhard?

Vadim


Simone

[EMAIL PROTECTED] wrote:

Author: simoneg
Date: Mon Feb  5 18:46:03 2007
New Revision: 503964

URL: http://svn.apache.org/viewvc?view=rev&rev=503964
Log:
Added another implemetation of profiling pipe respecting the sax streaming 
contract

Re: Releasing from trunk

[Vadim Gritsenko]

Reinhard Poetz wrote:
What we need now is more people 
who use/try it and in this sense it doesn't help to ship more milestone 
releases.


Make it easy to try it and people will come.

  http://cocoon.apache.org/mirror.cgi
  http://cocoon.apache.org/2.2/

Contrast and compare with 2.1 milestones:

  http://archive.apache.org/dist/cocoon/SOURCES/
  http://cocoon.apache.org/2.1/changes.html#N11DF5


There were *no* single 2.2M release shipped yet.

Vadim

Re: Releasing from trunk

[Vadim Gritsenko]

Carsten Ziegeler wrote:

Andrew Savory wrote:

Hi,


Not wishing to spread FUD and rain on the parade, but ... I think 2.2  
is *massively* less tested than 2.1.x. The main reason 2.1.x goes out  
with not much testing is because it's been used in production by a  
very large number of people. How many are actually using 2.2 in  
production right now? Carsten, Daniel, Giacomo, Reinhard ... I guess  
at most < 10 sites?


I'd love to see 2.2 out the door and more people using it, but I'd  
also hate to see people's first experience of 2.2 be a buggy one.


Given that we're still seeing changes enough to kill Cruisecontrol,  
I'd suggest an 'M' is more suitable than an 'RC'.


+1


And yes, I'm putting my money where my mouth is and trying to use 2.2  
to build a site ;-)



Great :)

We need to get a 2.2 out; imho it is more important to have something
out after so many years than having a 115% bug free version.


You are missing a point. It's not about a bug free version. It is about a 
version which seen more than like 4 hours of testing after major surgery.




In addition, there is no guarantee that releasing a milestone will bring
us more users testing, more documentation etc. And I personally doubt
that people will start trying a milestone release.


Counterpoint:
  http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=117024037825843

They are not even trying, they are using it in production. It is a bit different 
for 2.2 though: there were no "real" downloadable release yet, so there is 
really no easy way to download 2.2 and give it a spin on existing 2.1 project.


High entry point would hamper wider adoption of 2.2, not the label on its 
release.



And what will be the exit criteria? When do we have enough confidence
(if it is really missing today) that we are stable enough for switching
from milestone to rc? We only have indicators and feelings. I think that
the current code base is stable and the work we are doing with is a
proof for this (for me).


When there is a consensus in the community that version is ready for RC or Final 
release. Given the responses so far, you already can see that to reach consensus 
we'd have to:


  * have some more testing done (not 4h or 1d as now),
  * have unit tests working,
  * have CC working and not failing over,



On the other hand, a RC does not mean bug free - it means stable from
the api and implementation pov. If we would be sure that it's bug free
we could release a final right way.


Agree.



Yes, we had several changes in the last days/weeks, but doing a RC gives
ourselves the responsibility to not change these things until we have a
final version out (or create a branch).


Do you mean to say you can't stop doing major refactoring and start polishing 
unless it bears RC badge? What happened to good old-fashioned discipline and 
self control? :)


Vadim


So, in short: a RC is an indication to *everyone* that this is the a
stable version from the api pov and that we think (or hope if you like)
that this version is stable as well. It's more likely that people will
try out an RC than a milestone. So if we get feedback back at all, this
will happen for an RC but never for a milestone.

Carsten

CForms: dojo drag-and-drop repeater sample not working in IE

[Bart Molenkamp]

Hi,

The dojo drag-and-drop repeater isn't working with IE (checked with IE 6 
and IE 7). Both Cocoon 2.1 and 2.2 have the same problem (as expected...)


Somehow Dojo isn't capable of drag-and-drop, where  elements are 
used. The problem was reported, and I also found a sulution here [1]. 
However, this solution didn't work for me. Changing from a table to a 
list did work.


Is there anybody using this repeater with IE, and making use of tables?

Bart.

A sidenote for anyone working with IE7: you have to clean your cache, 
otherwise changes in JavaScript won't be loaded. This has to be done 
with a command line option, because cleaning your temporary internet 
files trough IE won't remove .js files... See [2].


[1]http://dojotoolkit.org/pipermail/dojo-interest/2006-July/011700.html
[2]http://drnicwilliams.com/2006/11/22/debugging-javascript-in-ie7-how-to-clear-your-javascript-cache/

Re: Dojo paths problem

[Grzegorz Kossakowski]

Jeremy Quinn napisał(a):


On 6 Feb 2007, at 13:06, Grzegorz Kossakowski wrote:


Jeremy Quinn napisał(a):
The point is, while using servlet-service-fw there is *no* root sitemap
handling all request. Request are handled by dispatcher servlet,
instead.


This is all news to me as I am not in a position ATM to even run 2.2
It's really easy. I would even hazard a guess that it's easier to play 
with Cocoon in 2.2 version...

Given that, resources of forms should be absolutely separated
from ajax's ones.


They are separated ATM.

However the Forms block depends on the Ajax Block in terms of 
client-side resources.


There are two types of resource path :

Actual files (js, gif, css etc) that are served by a reader :
_cocoon/resources/[namespace]/[file path]

And system resources that run a sitemap, accessing flowscript etc. :
_cocoon/system/[namespace]/[url path]
I wasn't really clear here. I meant that resources of two blocks are 
*completely* separated in terms of paths they are available from. I'll 
give you an example, in 2.2 it's completely valid to have following root 
path (mount paths) for forms and ajax blocks:

www.yourserver.com/some/long/path/forms
www.yourserver.com/ajax
Then path to dojo resources become:
www.yourserver.com/ajax/resources/js/dojo/**
But forms extension to dojo (forms namespace) is avaiable on:
www.yourserver.com/some/long/path/forms/resources/js/forms/** (or sth 
like this)
As you see, dojo's "haunting" mechanism will fail as long as we don't 
provide it base-paths for *each block*. In terms of one block, all 
resources path will follow conventions so Dojo will find all js files 
without any problems.



We should not assume there is some root context path
and we can calculate all relative paths against it.


Dojo makes that assumption for you.
All paths in Dojo and 3rd party namespaces are relative to the 
location of dojo.js
That will not work in 2.2. As explained above, paths cannot be 
calculated as relative to dojo.js for resources from other blocks.
This is going to be pretty complicated to work around, I suggest that 
you do not try as it will break at least 2.1.
If I'm not doing something entirely stupid it wasn't that hard. We just 
have to call dojo.registerModulePath several times (each one for each 
block). For example, manifest.js from Forms block will become:


dojo.registerModulePath("cocoon.ajax", "servlet:ajax:/resources/ajax/js"); // 
cocoon.forms has a dependency on the cocoon.ajax module libraries
dojo.registerModulePath("cocoon.forms", "servlet:forms/resources/forms/js");

Instead of:
dojo.registerModulePath("cocoon.ajax", "../ajax/js"); // cocoon.forms has a 
dependency on the cocoon.ajax module libraries
dojo.registerModulePath("cocoon.forms", "../forms/js");

I personally don't think it's complicated change, of course if it's valid from 
design point of view.


2.2 and 2.1 may serve dojo.js from different paths, but all other 
resources must be /relative/ to those paths.
No way to do it in 2.2 (of course we all the time speaking about 
situation when servlet-service-fw is used)
As you probably know, the client-side code for Forms and Ajax are 
shared between 2.1 and 2.2. Messing about with how Dojo generates 
paths for 2.2 will definitely break the client-side code for 2.1.
Yes, I'm aware of this problem. That was also a reason that I started to 
ask to stop sharing forms/ajax between 2.1 and 2.2. It will happen 
sooner, or later. My biased opinion is that it should happen sooner than 
later.
If you run FireBug while browsing the samples, you can easily see what 
paths are being requested.
If Dojo cannot find a resource the first time, it will start 'hunting' 
for it using some basic rules (documented at their site). We ALWAYS 
want to supply a resource at the first location Dojo will look.
Yes, I saw this a little confusing feature and I agree we should supply 
resource at first location. If it wasn't a case, it would lead to 
debugging nightmare...

I am sorry, but I have not had the time to review your patches.
Ok, I'll continue my work. Almost all changes in code are done now and I 
going to focus on writing documentation that will give others a chance 
to get my patches fitted in bigger picture.
We should also provide the same mechanism for allowing local overrides 
of dojo, forms and ajax libs, as this is important during both 
development, testing and deployment.

Thanks for reminder. It's possible but I'll take care of documenting this.



Good Luck :)

Thanks! :)


--
Grzegorz Kossakowski

Re: Dojo paths problem

[Jeremy Quinn]

On 6 Feb 2007, at 13:06, Grzegorz Kossakowski wrote:


Jeremy Quinn napisał(a):

I think part of the problem is that I was unable to get the proper
sitemap glue working for Cocoon 2.2 as I was unable to run the  
samples.


This section in the root sitemap (same mechanism in 2.1.n) is  
designed

to handle dojo resources, allow you to register and serve your own
namespaces and override built-in libraries :



The point is, while using servlet-service-fw there is *no* root  
sitemap

handling all request. Request are handled by dispatcher servlet,
instead.


This is all news to me as I am not in a position ATM to even run 2.2


Given that, resources of forms should be absolutely separated
from ajax's ones.


They are separated ATM.

However the Forms block depends on the Ajax Block in terms of client- 
side resources.


There are two types of resource path :

Actual files (js, gif, css etc) that are served by a reader :
_cocoon/resources/[namespace]/[file path]

And system resources that run a sitemap, accessing flowscript etc. :
_cocoon/system/[namespace]/[url path]



We should not assume there is some root context path
and we can calculate all relative paths against it.


Dojo makes that assumption for you.
All paths in Dojo and 3rd party namespaces are relative to the  
location of dojo.js
This is going to be pretty complicated to work around, I suggest that  
you do not try as it will break at least 2.1.


2.2 and 2.1 may serve dojo.js from different paths, but all other  
resources must be /relative/ to those paths.


As you probably know, the client-side code for Forms and Ajax are  
shared between 2.1 and 2.2. Messing about with how Dojo generates  
paths for 2.2 will definitely break the client-side code for 2.1.


If you run FireBug while browsing the samples, you can easily see  
what paths are being requested.
If Dojo cannot find a resource the first time, it will start  
'hunting' for it using some basic rules (documented at their site).  
We ALWAYS want to supply a resource at the first location Dojo will  
look.



My latest patches remove this assumption but obviously breaks C2.1.
Jemery, could you take a look at it and give your opinion if that
changes could be incorporated into forms/ajax blocks and would not  
break

2.1 somehow?
Thanks.

PS. Latest changes to servlet-service-fw break my patches (they  
will not

work anymore) but it could be easily fixed. I'm going to do it as soon
as my Subclipse stops hanging on synchronization :(


I am sorry, but I have not had the time to review your patches.

That sitemap snippet I sent you hopefully gives you an idea about  
what paths need to be matched.

We should avoid changing the matched paths.
We should also provide the same mechanism for allowing local  
overrides of dojo, forms and ajax libs, as this is important during  
both development, testing and deployment.



Good Luck :)

regards Jeremy

smime.p7s
Description: S/MIME cryptographic signature

What should "context://" be changed to in src attribute in 2.2 version (servlet service version)?

[Rice Yeh]

Hi,
 What should "context://" be changed to in src attribute in a block like
cocoon-forms-sample in 2.2 version (servlet service)? For example, how
should I rewrite the following statement in th cocoon-forms-sample?

 

 

Rice

Re: Releasing from trunk

[Carsten Ziegeler]

Andrew Savory wrote:
> Hi,

> 
> Not wishing to spread FUD and rain on the parade, but ... I think 2.2  
> is *massively* less tested than 2.1.x. The main reason 2.1.x goes out  
> with not much testing is because it's been used in production by a  
> very large number of people. How many are actually using 2.2 in  
> production right now? Carsten, Daniel, Giacomo, Reinhard ... I guess  
> at most < 10 sites?
> 
> I'd love to see 2.2 out the door and more people using it, but I'd  
> also hate to see people's first experience of 2.2 be a buggy one.
> 
> Given that we're still seeing changes enough to kill Cruisecontrol,  
> I'd suggest an 'M' is more suitable than an 'RC'.
> 
> And yes, I'm putting my money where my mouth is and trying to use 2.2  
> to build a site ;-)
> 
Great :)

We need to get a 2.2 out; imho it is more important to have something
out after so many years than having a 115% bug free version.
In addition, there is no guarantee that releasing a milestone will bring
us more users testing, more documentation etc. And I personally doubt
that people will start trying a milestone release.
And what will be the exit criteria? When do we have enough confidence
(if it is really missing today) that we are stable enough for switching
from milestone to rc? We only have indicators and feelings. I think that
the current code base is stable and the work we are doing with is a
proof for this (for me).

On the other hand, a RC does not mean bug free - it means stable from
the api and implementation pov. If we would be sure that it's bug free
we could release a final right way.
Yes, we had several changes in the last days/weeks, but doing a RC gives
ourselves the responsibility to not change these things until we have a
final version out (or create a branch).

So, in short: a RC is an indication to *everyone* that this is the a
stable version from the api pov and that we think (or hope if you like)
that this version is stable as well. It's more likely that people will
try out an RC than a milestone. So if we get feedback back at all, this
will happen for an RC but never for a milestone.

Carsten
-- 
Carsten Ziegeler
http://www.osoco.org/weblogs/rael/

[off-topic] Index path in patch files from Subclipse

[Grzegorz Kossakowski]

Hello,

It's little bit off-topic but my question is related to my patches I've
recently sent on JIRA. I've seen that all my patches produced by
Subclipse contain absolute path of Index: field. I think it's not
desired and these patches will cause problems to the others. Could
someone using Subclipse confirm this situation? Or maybe someone knows
how to fix that?

I ask here because I know that lots of developers use Eclipse. Thanks
for any tips.

-- 
Grzegorz Kossakowski

Re: Releasing from trunk

[Andrew Savory]

Hi,

On 7 Feb 2007, at 07:13, Carsten Ziegeler wrote:


I really doubt that most of the code for final releases (or rc) is
tested better than what we currently have in trunk. We do releases for
2.1.x without real tests for most of the code base. We rely on user
experience/tests. The version from trunk is used by several of us
already in production, several people have tried it out and it seems
that most of the problems have been fixed. So I really think that this
qualifies for an RC release.


Not wishing to spread FUD and rain on the parade, but ... I think 2.2  
is *massively* less tested than 2.1.x. The main reason 2.1.x goes out  
with not much testing is because it's been used in production by a  
very large number of people. How many are actually using 2.2 in  
production right now? Carsten, Daniel, Giacomo, Reinhard ... I guess  
at most < 10 sites?


I'd love to see 2.2 out the door and more people using it, but I'd  
also hate to see people's first experience of 2.2 be a buggy one.


Given that we're still seeing changes enough to kill Cruisecontrol,  
I'd suggest an 'M' is more suitable than an 'RC'.


And yes, I'm putting my money where my mouth is and trying to use 2.2  
to build a site ;-)



Thanks,

Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658  Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Sourcesense: http://www.sourcesense.com/

Re: Releasing from trunk

[Daniel Fagerstrom]

Reinhard Poetz skrev:

Carsten Ziegeler wrote:

Vadim Gritsenko wrote:
RC has a meaning of "release candidate", which to most people means 
"well tested almost production quality code". Going through recent 
commits I noticed a lot of refactoring, new code, untested code, and 
so on. This hardly qualifies as RC material.


IMHO, it should be labeled as M(n+1). -1 on RC since code is not 
went through enough testing yet.



I really doubt that most of the code for final releases (or rc) is
tested better than what we currently have in trunk. We do releases for
2.1.x without real tests for most of the code base. We rely on user
experience/tests. The version from trunk is used by several of us
already in production, several people have tried it out and it seems
that most of the problems have been fixed. So I really think that this
qualifies for an RC release.


Just wanted to write something similar. What we need now is more 
people who use/try it and in this sense it doesn't help to ship more 
milestone releases.


I also think that it is an *important signal to us*: 2.2 is complete, 
the contracts are stable and they can't be changed. The rest of the 
work is polishing and writing documentation.


Yes guys, after almost 3 1/2 years we will ship something that isn't a 
patch release!!!



+1

/Daniel

Re: Error creating bean with name 'javax.servlet.http.HttpServletRequest/callstack'

[Daniel Fagerstrom]

Ok. In the trunk version of Spring framework, one can also use ordinary 
Java (interface based) proxies, so I guess it is better to wait with 
this functionality until the next minor version of Spring is released. I 
turned it off in our trunk.


In Cocoon we use a call stack for handling some environment data (like 
the current sitemap and servlet context, request and response). There is 
such a call stack both in Cocoon core and in the servlet service 
framework. These call stacks are currently used through calling static 
functions - EnvironmentHelper.getCurrentEnvironment() in core and 
CallStack.getCurrentFrame() in the servlet service fw. The drawback with 
this is that it is much harder to reuse components that depend on static 
calls outside Cocoon. It is also harder to follow the code and to do 
unit testing.


What I work on now is to create a custom "call scope" for Spring (see 
http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes) 
that makes it possible to mark beans as having call scope. These beans 
are like ordinary beans and can be dependency injected, but internally 
they use the current call stack. The scoped proxy make sure that a user 
always gets the current value of the bean.


If it works well we could use a the same stack for both th sitemap and 
for the servlet services and replace all the static calls in the code 
with ordinary dependency injection.


I'll continue to develop the stuff but it seem like we need to wait for 
the next Spring release before we can turn it on in Cocoon.


/Daniel

Rice Yeh skrev:
No. But I think this is a bug in the method setBeanFactory(..) of 
class org.springframework.aop.scope.ScopedProxyFactoryBean in 
springframeowrk 2.0.2. In the last line of this method, it is

 this.proxy = pf.getProxy();
,where getProxy() is not passed a classloader. In the latest CVS 
version,  the last line of the same method is
this.proxy 
= pf.getProxy(cbf.getBeanClassLoader());

, where classloader is passed.

Regards,
Rice

On 2/6/07, *Daniel Fagerstrom* <[EMAIL PROTECTED] 
> wrote:


Any suggestion about what to do about it?

/Daniel

Rice Yeh skrev:
> I do have cglib-2.1_3.jar  in the WEB/lib directory. By tracing the
> code, I find the classloader used in Enhancer is the classloder of
> javax.servlet.http.HttpServletRequest, which is an instance of
> org.codehaus.classworlds.RealmClassLoader . RealmClassLoader
just include
> class path used in jetty, not include path in WEB/lib. Hence, an
> exception java.lang.NoClassDefFoundError:
org/springframework/aop/scope
> /ScopedObject is thrown.
>
> Rice
>
> On 2/6/07, *Daniel Fagerstrom* < [EMAIL PROTECTED]

> >> wrote:
>
> It looks like you are lacking the cglib. It is (since yesterday)
> part of
> the dependencies for cocoon-servlet-service-impl. It should be
> included
> in your cocoon-webapp dependencies by transitive dependency
> handling. It
> works for me. It might be that you need to clean and rebuild
your
> cocoon-webapp or something.
>
> /Daniel
>
> Rice Yeh skrev:
> > Hi,
> >   Running the latest code from trunk, I get an error as
the title
> > described.
> > The following is the exception stack:
> >
> > Caused by:
org.springframework.beans.factory.BeanCreationException:
> > Error creati
> > ng bean with name ' javax.servlet.http.HttpServletRequest
> /callstack':
> > Initializat
> > ion of bean failed; nested exception is
> > org.springframework.aop.framework.AopCon
> > figException: Couldn't generate CGLIB subclass of class
[interface
> > javax.servlet
> > .http.HttpServletRequest]: Common causes of this problem
include
> using
> > a final c
> > lass or a non-visible class; nested exception is
> > net.sf.cglib.core.CodeGeneratio
> > nException: java.lang.reflect.InvocationTargetException--
>null
> >
> ...
>
>

Re: Releasing from trunk

[Bertrand Delacretaz]

On 2/7/07, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:


...The version from trunk is used by several of us
already in production, several people have tried it out and it seems
that most of the problems have been fixed. So I really think that this
qualifies for an RC release...


Excuse the silly question (I haven't followed 2.2 at all in the last
months), but are the automated tests of the core parts working?

If there are enough automated tests for people working on 2.2 to have
confidence in it, a release candidate is certainly a good option.

-Bertrand

Re: [graphics] New version of masthead - update

[Reinhard Poetz]

hepabolu wrote:

Guys,

Thien did it again:

- he changed the masthead, making it a bit smaller and darker.
- he also added a search box and changed the color of "apache cocoon" to 
be more prominent.

- he removed some tiles to make things look better at 800x600.
- the green blocks are now moved also to make things look better at 
800x600.

- the green blocks are also a bit darker.

- he added nice icons to the content.

In short, I'm very happy with this result.


My overall impression: I like it!

Let me offer two remarks:

- I think the page is a bit overloaded. I would like to see more white space, 
especially before  headlines (~15px) and at the left margin of the green 
boxes (~30px).


- I'm not really happy with the red border of the note paragraph, though I don't 
have a better alternative.


Thanks Thien!

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


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

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

Re: Releasing from trunk

[Reinhard Poetz]

Reinhard Poetz wrote:

I also think that it is an *important signal to us*: 2.2 is complete, 
the contracts are stable and they can't be changed


One thing to add: As Cocoon is modularized now, we can and _will_ have different 
release cycles for our modules, e.g. if we think it's useful we can release 
Cocoon Forms every month and if we change contracts there we can release 2.0. 
All this can happen without releasing core or other blocks again.


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


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

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