Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On 12/18/06, Antonio Gallardo [EMAIL PROTECTED] wrote: ...Seems like all us is too busy. :).. Exactly - and I think it's better to be realistic than to pretend supporting something without having the resources to actually do it. (BTW it's good to hear that you're busy for good reasons like Benjamin ;-) -Bertrand
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Niclas Hedhman wrote: If we have made a prior commitment of keeping the 2.1.x compatible with JDK1.3, then that should stand. It should not be a matter of what a handful developers think. They are usually on the curring edge anyway, but what the user community are depending on. It is these type of inconcistencies that drives users away from a project, and by now Cocoon I feel Cocoon has a rather low reputation and considered a niche and novel project that one can't use in 'real' projects. If we find it hard to maintain, then let that be it and stop evolving it. Saying that we keep evolving 2.1.11+ in JDK1.4 (assumingly backporting stuff from 2.2.x) and on top of that maintain a 2.1.10.x line for bug fixes seems even more work to me. I would be voting -1 in behalf of unheard users. Niclas, Thanks for bringing this up. I'm just surprised it wasn't raised earlier. I just took a look at http://cocoon.apache.org/versioning.html. Removing support for JDK 1.3 on 2.1.x seems to violate that document as all patch levels should be binary compatible. So it seems the only way to remove support for JDK 1.3 would be to move to a new minor version number. Again, it would also seem to me that the current 2.2 also doesn't conform to that document as the change from 2.1 to 2.2 seems to me to something more than minor given how much the core has changed. A change from 2.1 to 2.2 would imply that nearly all user written components will still work perhaps only requiring a recompile. While this may or may not be true - I certainly haven't tried - it is certain that how an end user application is integrated with Cocoon has completely changed. I'm also not sure how many existing sitemaps will require modification. So I would think trunk should be released as 3.0, if for no other reason than allow the next 2.1 release to be 2.2.0 without jdk 1.3 support. Ralph
[IMP] Code freeze for 2.1.x is over
I assembled the release candidate for 2.1.10 (vote mail will follow soon), so this ends the code freeze. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[Vote] Release 2.1.10
Please cast your votes on the 2.1.10 release. The release candidate can be downloaded from: http://people.apache.org/~cziegeler/cocoon/ The corresponding sources are under: https://svn.apache.org/repos/asf/cocoon/tags/RC_2_1_10/ The vote will be open for 72 hours. If the vote passes, I will rename the tag to RELEASE_2_1_10, rename the downloadable archives, sign them etc. and put them up for download. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
[2.2] Duplicate (and different) versions of batik on classpath
Hi, I found a problem with the cocoon-batik-impl block. When I add a dependency to this block, I end up with two different versions of Batik on my classpath. The first (and correct) one is batik-1.6-1. But due to a dependency to fop 0.20.5, batik-1.5-fop gets included (which is not compatible with batik-1.6-1). See the snippet below that I got when running maven with the -X option: batik:batik-squiggle:jar:1.6-1:compile (selected for compile) batik:batik-swing:jar:1.6-1:compile (selected for compile) batik:batik-transcoder:jar:1.6-1:compile (selected for compile) fop:fop:jar:0.20.5:compile (selected for compile) xml-apis:xml-apis:jar:1.0.b2:compile (removed - nearer found: 1.3.02) xerces:xercesImpl:jar:2.2.1:compile (removed - nearer found: 2.8.0) batik:batik-1.5-fop:jar:0.20-5:compile (selected for compile) When I run the webapp from the commandline, using the maven jetty plugin, everything seems to work fine. But when I run it in Eclipse (using the Jetty launcher plugin), I get classpath errors. First conflict I found was that of o.a.batik.dom.AbstractDocument.init (constructor signature changed in 1.6-1). After removing batik-1.5-fop jar from my classpath, I ran into another classpath problem. org.apache.cocoon.xml.dom.SVGBuilder accesses the protected member 'namespaces', which is of type org.apache.batik.dom.util.HashTableStack. The signature method 'put' has changed from 'put(String, Object)' to 'put(String, String)'. It looks like the cocoon-batik-impl block is built against batik-1.5-fop, and not batik-1.6-fop. When I exclude batik-1.5-fop as a dependency, everything seems to work fine (but I don't know what functionality of batik requires batik-1.5-fop). It worked either by excluding the dependency from cocoon-batik-impl's pom.xml (but I had to declare the exclusion several times), or when I exclude it from fop-0.20.5.pom (from my local repository). How can this problem be resolved? Anybody interested in the changed pom? Thanks, Bart.
Re: [Vote] Release 2.1.10
Carsten Ziegeler wrote: Please cast your votes on the 2.1.10 release. The release candidate can be downloaded from: http://people.apache.org/~cziegeler/cocoon/ The corresponding sources are under: https://svn.apache.org/repos/asf/cocoon/tags/RC_2_1_10/ +1 Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [Vote] Release 2.1.10
On 12/18/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...The release candidate can be downloaded from: http://people.apache.org/~cziegeler/cocoon/.. On my macosx system with either JDK 1.4.2 or 1.5, all the automated tests from org.apache.cocoon.forms.datatype fail (DynamicSelectionListTestCase,EnumSelectionListTestCase,FlowJXPathSelectionListTestCase). IIRC the same tests passed last week, anyone know what could have changed? -Bertrand
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 18 December 12:26 PM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2006-12-18 12:02:20 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Aug 08 23:50:13 GMT+00:00 2006 [get] ... [get] last modified = Wed Aug 09 09:07:08 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Mon Jul 17 11:50:10 GMT+00:00 2006 [get] Not modified - so not downloaded [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 file to
Re: [Vote] Release 2.1.10
Bertrand Delacretaz wrote: On 12/18/06, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...The release candidate can be downloaded from: http://people.apache.org/~cziegeler/cocoon/.. On my macosx system with either JDK 1.4.2 or 1.5, all the automated tests from org.apache.cocoon.forms.datatype fail (DynamicSelectionListTestCase,EnumSelectionListTestCase,FlowJXPathSelectionListTestCase). IIRC the same tests passed last week, anyone know what could have changed? Same here on windows...sigh...the question is now, are the test cases wrong or do we really have bugs? Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Monday 18 December 2006 16:26, Ralph Goers wrote: So I would think trunk should be released as 3.0, if for no other reason than allow the next 2.1 release to be 2.2.0 without jdk 1.3 support. I agree (and with Helma's elaboration). Personally, I don't understand the intense resistence of bumping the numbers in Cocoon community. A change in 3 digit in Cocoon could mean anything from a tiny bug fix to loads of new functionality, and now potentially incompatible with running system... Let the numbers tick... Cheers Niclas
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On 12/18/06, hepabolu [EMAIL PROTECTED] wrote: ...- rename the current branch to Cocoon 2.2 without the 1.3 compatibility.. Not 2.2, please...we've been talking about 2.2 for so long that releasing the 2.1 branch as 2.2 might be very confusing. I'm not against renumbering things, no problem with that. But Cocoon 2.2 means our current trunk for many people, and IMHO we shouldn't reuse that version number for anything else. -Bertrand
Cocoon 2.2 - Use a block for the root sitemap
As of my tests a block configured to handle root sitemap does only
strictly answer to / resource call. The rest of its context seems to be
inaccessible.
Thus, for instance, if a block testblock1 is configured to handle root
sitemap and should serve:
a welcome page at /
some content at /contact.html
some resources at /images/**
only the welcome page at / from this block testblock1 will be accessible
(with all references to resources,... failing).
Looking at the org.apache.cocoon.blocks.DispatcherServlet source, this
behaviour is due to the way the service() method chooses which block
(Servlet) to dispatch to:
Added
// HARDCODED for root sitemap could be made configurable !?
private static final String DEFAULT_SERVLET = /;
Added
protected void service(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
(...)
while (servlet == null index != -1) {
path = path.substring(0, index);
servlet = (Servlet)this.mountableServlets.get(path);
index = path.lastIndexOf('/');
}
Added
// If no servlet were found try to delegate call to DEFAULT_SERVLET
if (servlet == null) {
servlet = (Servlet)this.mountableServlets.get(DEFAULT_SERVLET);
}
Added
if (servlet == null) {
throw new ServletException(No block for + req.getPathInfo());
}
(...)
}
WDYT ? Any caveheat I overlook ?
Patrick
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
- stop the development of Cocoon 2.1 after the release of 2.1.10 - rename the current branch to Cocoon 2.2 without the 1.3 compatibility (and maybe other minor changes that are now prevented by the versioning contract) - rename the current trunk to Cocoon 3.0 My goal was not to open Pandora's box - especially not the one of Java 5 on trunk :-/ I only wanted a more explanatory message in status.xml and a new guideline for maintaining the branch regarding to Java 1.3 compatibility. If you think a renumbering is more appropriate I'm ok with it as well. But creating an already dead successor for 2.1 (however it is named) is a bit awkward. Just my 2c. Jörg -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: Cocoon 2.2 - Use a block for the root sitemap
The root servlet should be mounted at not /. Alexander had the same
problem. So even if I find the current behavior intuitive, no one else
seem to agree ;). So we should probably have special handling of / as
you suggest.
/Daniel
Patrick Refondini skrev:
As of my tests a block configured to handle root sitemap does only
strictly answer to / resource call. The rest of its context seems to
be inaccessible.
Thus, for instance, if a block testblock1 is configured to handle
root sitemap and should serve:
a welcome page at /
some content at /contact.html
some resources at /images/**
only the welcome page at / from this block testblock1 will be
accessible (with all references to resources,... failing).
Looking at the org.apache.cocoon.blocks.DispatcherServlet source, this
behaviour is due to the way the service() method chooses which block
(Servlet) to dispatch to:
Added
// HARDCODED for root sitemap could be made configurable !?
private static final String DEFAULT_SERVLET = /;
Added
protected void service(HttpServletRequest req, HttpServletResponse
res) throws ServletException, IOException {
(...)
while (servlet == null index != -1) {
path = path.substring(0, index);
servlet = (Servlet)this.mountableServlets.get(path);
index = path.lastIndexOf('/');
}
Added
// If no servlet were found try to delegate call to DEFAULT_SERVLET
if (servlet == null) {
servlet = (Servlet)this.mountableServlets.get(DEFAULT_SERVLET);
}
Added
if (servlet == null) {
throw new ServletException(No block for + req.getPathInfo());
}
(...)
}
WDYT ? Any caveheat I overlook ?
Patrick
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On 12/18/06, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 12/18/06, hepabolu [EMAIL PROTECTED] wrote: ...- rename the current branch to Cocoon 2.2 without the 1.3 compatibility.. Not 2.2, please...we've been talking about 2.2 for so long that releasing the 2.1 branch as 2.2 might be very confusing. I'm not against renumbering things, no problem with that. But Cocoon 2.2 means our current trunk for many people, and IMHO we shouldn't reuse that version number for anything else. I'd disagree; the current numbering scheme seems completely arbitrary and doesn't help clarify the major differences between 2.1 and 2.2. Yes there are users on the dev list, but I'd bet every single person that has actually downloaded Trunk and built it can cope with having it called 3.0 instead of 2.2. -- Peter Hunsberger
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On 12/18/06, Peter Hunsberger [EMAIL PROTECTED] wrote: I'd bet every single person that has actually downloaded Trunk and built it can cope with having it called 3.0 instead of 2.2... Agreed, my problem is not this one. What I fear is that, if we release an evolution of 2.1.x and name it 2.2, people will be confused. For example by searching our lists for 2.2 and finding lots of messages about Maven, while *that* 2.2 version would not use Maven. -Bertrand
JX or JPath without flowscript
Hi. Is any posibility to use jx generator or JPath logicsheets without flowscript. I mean how to acces request, context or session params. Greetings Piotr -- View this message in context: http://www.nabble.com/JX-or-JPath-without-flowscript-tf2840359.html#a7930025 Sent from the Cocoon - Dev mailing list archive at Nabble.com.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Bertrand Delacretaz wrote: What I fear is that, if we release an evolution of 2.1.x and name it 2.2, people will be confused. For example by searching our lists for 2.2 and finding lots of messages about Maven, while *that* 2.2 version would not use Maven. That is a valid concern. We kind of painted ourselves in a box by calling trunk 2.2 way before it was ready to be anything. However, even taking trunk in isolation and forgetting the JDK 1.3 issue, I think trunk is more deserving of 3.0 than 2.2. Ralph
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Ralph Goers wrote: Bertrand Delacretaz wrote: What I fear is that, if we release an evolution of 2.1.x and name it 2.2, people will be confused. For example by searching our lists for 2.2 and finding lots of messages about Maven, while *that* 2.2 version would not use Maven. That is a valid concern. We kind of painted ourselves in a box by calling trunk 2.2 way before it was ready to be anything. However, even taking trunk in isolation and forgetting the JDK 1.3 issue, I think trunk is more deserving of 3.0 than 2.2. Hmm, on of the main ideas of 2.2 is to be able to run existing applications without changes. Ok, we all know that this is plain theory, but currently you are able to run existing applications with minor tweaks. Most of these tweaks have to be done to your build system. If we open up the can of worms and call current trunk 3.0, we will start to refactor everything and will never release a 2.2 final (which is given the current situation very hard anyway). Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Carsten Ziegeler wrote:
Perhaps we should rethink this drop jdk1.3 support stuff, remove the
comment from the status file and get 2.1.10 out.
I agree.
--
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: [VOTE] Drop JDK1.3 support after 2.1.10 release
On 12/18/06, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On 12/18/06, Peter Hunsberger [EMAIL PROTECTED] wrote: I'd bet every single person that has actually downloaded Trunk and built it can cope with having it called 3.0 instead of 2.2... Agreed, my problem is not this one. What I fear is that, if we release an evolution of 2.1.x and name it 2.2, people will be confused. For example by searching our lists for 2.2 and finding lots of messages about Maven, while *that* 2.2 version would not use Maven. I guess I could see that as a bit of a potential problem. Let's call it 2.5.0 then ;-) -- Peter Hunsberger
Re: JX or JPath without flowscript
Hi Piotr, I'm afraid that questions like these should go to the cocoon user list instead of the developers list. To answer your question: Yes you can use the jx generator without flowscript. From the jx you can access: the request by using cocoon.request.someFunction(); the context by using cocoon.context.x the session by using cocoon.session.x Have a look at: http://cocoon.apache.org/2.1/userdocs/jx-generator.html and http://cocoon.apache.org/2.1/userdocs/flow/jxtemplate.html Kind regards, Jeroen Reijn falcorn wrote: Hi. Is any posibility to use jx generator or JPath logicsheets without flowscript. I mean how to acces request, context or session params. Greetings Piotr
Re: Cocoon 2.2 - Use a block for the root sitemap
Daniel Fagerstrom wrote:
The root servlet should be mounted at not /. Alexander had the same
problem. So even if I find the current behavior intuitive, no one else
seem to agree ;). So we should probably have special handling of / as
you suggest.
I just tested configuration and it does exactly what I was looking
for, uh ! Although having special handling of /, if found acceptable
in term of coding, could be valuable for dummy users like I :O) or those
who won't read the docs.
Talking about documentation, would this:
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1291.html
be the place where the block protocol and configurations like these
could be best described ?
Patrick
/Daniel
Patrick Refondini skrev:
As of my tests a block configured to handle root sitemap does only
strictly answer to / resource call. The rest of its context seems to
be inaccessible.
Thus, for instance, if a block testblock1 is configured to handle
root sitemap and should serve:
a welcome page at /
some content at /contact.html
some resources at /images/**
only the welcome page at / from this block testblock1 will be
accessible (with all references to resources,... failing).
Looking at the org.apache.cocoon.blocks.DispatcherServlet source, this
behaviour is due to the way the service() method chooses which block
(Servlet) to dispatch to:
Added
// HARDCODED for root sitemap could be made configurable !?
private static final String DEFAULT_SERVLET = /;
Added
protected void service(HttpServletRequest req, HttpServletResponse
res) throws ServletException, IOException {
(...)
while (servlet == null index != -1) {
path = path.substring(0, index);
servlet = (Servlet)this.mountableServlets.get(path);
index = path.lastIndexOf('/');
}
Added
// If no servlet were found try to delegate call to DEFAULT_SERVLET
if (servlet == null) {
servlet = (Servlet)this.mountableServlets.get(DEFAULT_SERVLET);
}
Added
if (servlet == null) {
throw new ServletException(No block for + req.getPathInfo());
}
(...)
}
WDYT ? Any caveheat I overlook ?
Patrick
Re: Cocoon 2.2 - Use a block for the root sitemap
Patrick Refondini wrote:
Daniel Fagerstrom wrote:
The root servlet should be mounted at not /. Alexander had the
same problem. So even if I find the current behavior intuitive, no one
else seem to agree ;). So we should probably have special handling of
/ as you suggest.
I just tested configuration and it does exactly what I was looking
for, uh ! Although having special handling of /, if found acceptable
in term of coding, could be valuable for dummy users like I :O) or those
who won't read the docs.
Talking about documentation, would this:
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1291.html
be the place where the block protocol and configurations like these
could be best described ?
The block documentation should go to
http://cocoon.zones.apache.org/daisy/cdocs-core/g5/1266.html or to one of its
siblings in the menu tree.
--
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: [VOTE] Drop JDK1.3 support after 2.1.10 release
Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. Vadim
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Vadim Gritsenko skrev: Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. +1 /Daniel
Re: Cocoon 2.2 - Use a block for the root sitemap
Reinhard Poetz wrote:
Patrick Refondini wrote:
Daniel Fagerstrom wrote:
The root servlet should be mounted at not /. Alexander had the
same problem. So even if I find the current behavior intuitive, no
one else seem to agree ;). So we should probably have special
handling of / as you suggest.
I just tested configuration and it does exactly what I was looking
for, uh ! Although having special handling of /, if found acceptable
in term of coding, could be valuable for dummy users like I :O) or
those who won't read the docs.
Talking about documentation, would this:
http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1291.html
be the place where the block protocol and configurations like these
could be best described ?
The block documentation should go to
http://cocoon.zones.apache.org/daisy/cdocs-core/g5/1266.html or to one
of its siblings in the menu tree.
The document that you refered to should contain a short recipie how to add
another block to an existing block and continues where Your first Cocoon
application (http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1159.html)
and Your first Cocoon pipeline
(http://cocoon.zones.apache.org/daisy/cdocs-site-main/g2/1290.html) end.
--
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: ExpiresCachingProcessingPipeline and cache-expires
Gianugo Rabellino wrote: On 12/13/06, Matthias Epheser [EMAIL PROTECTED] wrote: According to the documentation here http://cocoon.zones.apache.org/daisy/documentation/components/1063/g1/939.html it should be possible to declare the expires time in mod_expires style (e.g.. access plus 4 ours). We couldn't find something about the apache-style support here. We are using a 2.2 development version from about early this year. Are we missing some point or is the documentation pointing to a feature that doesn't exist (any more) ? Definitely a documentation bug. I wrote that piece of code, and the corresponding docs, then the Apache style was dropped sometimes in the process (I found it out the hard way as well, but it was definitely too late at night to fix the docs). Probably, as Carsten notes, this happened when the component was moved from the sandbox. There is AbstractProcessingPipeline.parseExpires() which is used to initialize configuredExpires member variable. Not sure what's up with ExpiresCachingProcessingPipeline and why it is not using this value and/or method. Vadim
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Dec 18, 2006, at 3:59 AM, hepabolu wrote: Guys, [snipped: proposal to rebadge 2.1.11 = 2.2, 2.2 = 3.0] No, no... please, no!! The mailing list archives and JIRA are loaded with references to the current version number scheme. 2.2 = Mavenization 3.0 = OSGi Don't change it now, that will make it a lot more confusing to refer to past discussions. The Java 1.3 thing is such a minor issue, nobody cares about it, it's not a big enough deal to force a shift in a version number plan that's this long established. My $0.02, —ml—
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Dec 18, 2006, at 7:15 AM, Ralph Goers wrote: That is a valid concern. We kind of painted ourselves in a box by calling trunk 2.2 way before it was ready to be anything. Agreed, IMHO all future releases beyond 2.2 (will that actually be 2.2.0?) should use internal code names until right before we cut the release. Then we can have the numbering discussions and settle on the right thing without any historical encumbrance. cheers, —ml—
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Dec 18, 2006, at 8:14 AM, Vadim Gritsenko wrote: get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. +1! —ml—
Re: [Vote] Release 2.1.10
On 18.12.2006 10:42, Bertrand Delacretaz wrote: all the automated tests from org.apache.cocoon.forms.datatype fail (DynamicSelectionListTestCase,EnumSelectionListTestCase,FlowJXPathSelectionListTestCase). IIRC the same tests passed last week, anyone know what could have changed? This is probably due to my change to fix some samples: Commit: http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=116638665114040w=4 Thread: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116640290515848w=4 Jira messages: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116639428428700w=4 http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116639494414680w=4 As forms block is mounted from trunk and trunk's block only has the JXTemplateGenerator from template block I was quite sure not to break anything. I'll have a look on what the tests are actually checking for and see if it is the test or the result that is broken. Jörg
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Dec 17, 2006, at 8:26 PM, Antonio Gallardo wrote: I would be voting -1 in behalf of unheard users. Thanks Niclas, here we go: I vote -1 for the reasons stated above. Changing the user contracts is not fair. I'd say that you owe to users the chance to become heard by asking on the users' list, and then users who choose to remain unheard do not have standing. If it turns out that nobody on the users' list gives a rip about Java 1.3, then this whole thing is moot. If users *do* give a rip, then the answer might *still* be too freakin' bad! What else? Bummer about Cocoon, they could never release 2.1.11 because they couldn't do it without 'changing the contracts' and there were no resources to do the work to make it 1.3-compatible? If the choice truly is between that and ending 1.3 compatibility, then screw 1.3 and at least get out a final 2.1. Remember, the previous 1.3-compatible releases of Cocoon are not going to suddenly stop working. OK, I'm all done ranting on this thread... cheers, —ml—
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Vadim Gritsenko said the following on 18/12/06 17:14: get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. +1 Bye, Helma
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Just to clarify... I had a typo/braino: On Dec 18, 2006, at 11:37 AM, Mark Lundquist wrote: If users *do* give a rip, then the answer might *still* be too freakin' bad! What else? Bummer about Cocoon, they could never release 2.1.11 because they couldn't do it without 'changing the contracts' and there were no resources to do the work to make it 1.3-compatible? I meant 2.1.10, not 2.1.11!! cheers, —ml—
Re: [Vote] Release 2.1.10
On 18.12.2006 20:34, Joerg Heinicke wrote: all the automated tests from org.apache.cocoon.forms.datatype fail (DynamicSelectionListTestCase,EnumSelectionListTestCase,FlowJXPathSelectionListTestCase). IIRC the same tests passed last week, anyone know what could have changed? As forms block is mounted from trunk and trunk's block only has the JXTemplateGenerator from template block I was quite sure not to break anything. Those tests do not involve any sitemap processing, so JXTemplateGenerator is not involved. It's more likely that the upgrade of the XML libs [1] caused this not quite unwanted side effects (removing a marked DIRTY HACK). But this commit was on 27th of November. If the tests were really successful last week, I don't know what caused this failure now. But for me now org.apache.cocoon.components.thread.DefaultRunnableManagerTestCase fails in testExecuteRunnablelonglong: junit.framework.AssertionFailedError: Unexpected Exception at org.apache.cocoon.components.thread.DefaultRunnableManagerTestCase. testExecuteRunnablelonglong(DefaultRunnableManagerTestCase.java:758) Or a bit verbose: junit.framework.AssertionFailedError: Unexpected method call debug(Executing command EasyMock for interface java.lang.Runnable in pool default, schedule with interval=100): debug(Executing command EasyMock for interface java.lang.Runnable in pool default, schedule with interval=100): expected: 0, actual: 1 debug(Exiting loop): expected: 1, actual: 0 at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44) at $Proxy1.debug(Unknown Source) at org.apache.cocoon.components.thread.DefaultRunnableManager$ExecutionInfo.execute(DefaultRunnableManager.java:829) at org.apache.cocoon.components.thread.DefaultRunnableManager.run(DefaultRunnableManager.java:485) at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Thread.java:534) junit.framework.AssertionFailedError: Unexpected method call isDebugEnabled(): isDebugEnabled(): expected: 0, actual: 1 debug(Exiting loop): expected: 1, actual: 0 at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:44) at $Proxy1.isDebugEnabled(Unknown Source) at org.apache.cocoon.components.thread.DefaultRunnableManager.dispose(DefaultRunnableManager.java:258) at org.apache.cocoon.components.thread.DefaultRunnableManagerTestCase.testExecuteRunnablelonglong(DefaultRunnableManagerTestCase.java:752) Can somebody have a look on this one? Jörg [1] http://svn.apache.org/viewvc?view=revsortby=daterevision=479509
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Mon, 2006-12-18 at 16:24 +0100, Reinhard Poetz wrote: Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. I agree. I agree, too. The last thing I want is to hold up the 2.1.10. If I had known what I stirred up here, I would not have started it. I apologize for the short time for discusion and vote but the idea was to get it into 2.1.10. Otherwise it will stay forever. Personally I think trunk is still too immature and unapproachable that there must a way open for 2.1.11+ release. I have nothing against staying JDK1.3 compatible, only I doubt that is is still useful. I think it is simply a non-issue, and we are making life unnecessarily hard for ourselves. Hands up, who has still a working 1.3 JVM on his computer to support it? If we weren't nailed down with trunk == 2.2, it would be sensible to save face by calling the 2.1.1 already 2.2. But that is too late now... I am not so firm in ASF rules. Does the one who called the vote have the right to withdraw the motion? Or does somebody else want to call a vote to undo this vote? Cheers, Alfred.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On 18.12.2006 16:22, Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. +1 Jörg
ForrestBot build for cocoon-docs FAILED
Automated build for cocoon-docs FAILED Log attached. -- Forrestbot run ended at 19 December 12:29 AM Using Forrest 0.8-dev Forrestbot administrator: ForrestBot -- [echo] ... Forrest render START 2006-12-19 12:02:21 ... Rendering docs in /export/home/config/forrestbot-trunk/conf/work/cocoon-docs check-java-version: [echo] This is apache-forrest-0.8-dev [echo] Using Java 1.4 from /usr/j2se/jre init-props: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp echo-settings: check-skin: init-proxy: fetch-skins-descriptors: fetch-skin: unpack-skins: init-skins: fetch-plugins-descriptors: [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/plugins.xml [get] Getting: http://forrest.apache.org/plugins/plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml [get] local file date : Tue Aug 08 23:50:13 GMT+00:00 2006 [get] ... [get] last modified = Wed Aug 09 09:07:08 GMT+00:00 2006 [echo] Fetching plugins descriptor: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml [get] To: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-2.xml [get] local file date : Mon Jul 17 11:50:10 GMT+00:00 2006 [get] Not modified - so not downloaded [echo] Plugin list loaded from http://forrest.apache.org/plugins/plugins.xml. [echo] Plugin list loaded from http://forrest.apache.org/plugins/whiteboard-plugins.xml. init-plugins: [mkdir] Created dir: /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [copy] Copying 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp [echo] -- Installing plugin: org.apache.forrest.plugin.output.pdf -- check-plugin: [echo] org.apache.forrest.plugin.output.pdf is available in the build dir. Trying to update it... init-props: echo-settings: init-proxy: fetch-plugins-descriptors: fetch-plugin: [echo] Trying to find the description of org.apache.forrest.plugin.output.pdf in the different descriptor files [echo] Using the descriptor file /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml... [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl fetch-local-unversioned-plugin: get-local: [echo] Trying to locally get org.apache.forrest.plugin.output.pdf [echo] Looking in local /export/opt/forrest-trunk/plugins [echo] Found ! init-build-compiler: echo-init: init: compile: jar: local-deploy: [echo] Locally deploying org.apache.forrest.plugin.output.pdf build: [echo] Plugin org.apache.forrest.plugin.output.pdf deployed ! Ready to configure fetch-remote-unversioned-plugin-version-forrest: fetch-remote-unversioned-plugin-unversion-forrest: has-been-downloaded: downloaded-message: uptodate-message: not-found-message: [echo] Fetch-plugin Ok, installing ! unpack-plugin: install-plugin: configure-plugin: configure-output-plugin: [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl [move] Moving 1 file to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp configure-plugin-locationmap: [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf [xslt] Processing /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml to /export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new [xslt] Loading stylesheet /export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl [move] Moving 1 file to
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Mark Lundquist escribió: On Dec 17, 2006, at 8:26 PM, Antonio Gallardo wrote: I would be voting -1 in behalf of unheard users. Thanks Niclas, here we go: I vote -1 for the reasons stated above. Changing the user contracts is not fair. I'd say that you owe to users the chance to become heard by asking on the users' list, and then users who choose to remain unheard do not have standing. If it turns out that nobody on the users' list gives a rip about Java 1.3, then this whole thing is moot. If users *do* give a rip, then the answer might *still* be too freakin' bad! What else? Bummer about Cocoon, they could never release 2.1.11 because they couldn't do it without 'changing the contracts' and there were no resources to do the work to make it 1.3-compatible? If the choice truly is between that and ending 1.3 compatibility, then screw 1.3 and at least get out a final 2.1. Remember, the previous 1.3-compatible releases of Cocoon are not going to suddenly stop working. Unheard user are users that are not on our user list. They may be more than we may suggest. As many people here we use a lot of other projects and we are not necesarily on the user list of the given project. Best Regards, Antonio Gallardo.
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Tuesday 19 December 2006 00:14, Vadim Gritsenko wrote: Carsten Ziegeler wrote: Perhaps we should rethink this drop jdk1.3 support stuff, remove the comment from the status file and get 2.1.10 out. get 2.1.10 out, close 2.1.x branch, and work on getting 2.2 out - i'm completely +1 on this line of thinking. Why do we need to keep on dragging 2.1.x branch forward? Just say that 2.1.10 is last on jdk 1.3 (and last of 2.1.x), and 2.2 forward requires jdk 1.4. Amen and/or Amin and/or your favourite holy blessing. Cheers Niclas
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
On Tuesday 19 December 2006 03:13, Mark Lundquist wrote: On Dec 18, 2006, at 7:15 AM, Ralph Goers wrote: That is a valid concern. We kind of painted ourselves in a box by calling trunk 2.2 way before it was ready to be anything. Agreed, IMHO all future releases beyond 2.2 (will that actually be 2.2.0?) should use internal code names until right before we cut the release. Then we can have the numbering discussions and settle on the right thing without any historical encumbrance. Very good observation. What will Maven think of versionlycaenidae-SNAPSHOT/version?? Cheers Niclas [1] http://en.wikipedia.org/wiki/Lycaenidae
Re: [VOTE] Drop JDK1.3 support after 2.1.10 release
Alfred Nathaniel wrote: I agree, too. The last thing I want is to hold up the 2.1.10. If I had known what I stirred up here, I would not have started it. I guess most of us did not expect this :( I apologize for the short time for discusion and vote but the idea was to get it into 2.1.10. Otherwise it will stay forever. The intension was definitly good. Personally I think trunk is still too immature and unapproachable that there must a way open for 2.1.11+ release. Don't know if trunk is really immature, but looking at the past it seems unlikely that we will release 2.2 in a short timeframe; so it is realistic that we will have a 2.1.11. I am not so firm in ASF rules. Does the one who called the vote have the right to withdraw the motion? Or does somebody else want to call a vote to undo this vote? I think you can just withdraw the vote (if you would have a vote to undo a vote, someone could vote there -1 ... would be funny somehow) The remaining question is, if we want to keep the notice in the status.xml for 2.1.10? Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
