Re: [vote] Niclas Hedhman as a new Cocoon committer
Daniel Fagerstrom wrote: Please cast your votes. +1, welcome! 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/ Orixo alliance: http://www.orixo.com/
Properties for NekoHTMLGenerator
Hello, Can you please comment on this: https://issues.apache.org/jira/browse/COCOON-1639#action_12371243 Excerpt from the comment: I was about to commit [the new NekoHTMLTransformer] when I noticed neko.properties containing URLs as property keys. The javadoc for java.util.Properties states that « The key contains all of the characters in the line starting with the first non-white space character and up to, but not including, the first unescaped '=', ':', or white space character other than a line terminator. ». Example: http://xml.org/sax/features/namespaces=true http://cyberneko.org/html/features/balance-tags=true Has someone been able to test the settings in neko.properties successfully? If this is the case, why is the colon after http not interpreted as a key separator? Or quoting Andrew Stevens « at worst it just needs the colons to be escaped ». -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: [jira] Commented: (COCOON-1806) [PATCH] Java class custom validator builder
* Simone Gianni: I already have an account on cocoon zones : SimoneGianni. Please give me edit rights, I also have to write about the char datatype (COCOON-1789) and the apache enum selection lists (COCOON-1793). Thank you Simone! -- Jean-Baptiste Quenot http://caraldi.com/jbq/
Re: ForrestBot build for cocoon-docs FAILED
Ross Gardler wrote: David Crossley wrote: Ross Gardler wrote: Perhaps there is a time out occuring. Is there a way of increasing the timeout on files being generated from http: sources? Not a solution, but it would be a workaround. I don't know if it proves anything, but just completed a local build and it worked. This is horrendously slow for some reason (takes 25 seconds per page). Well it proves there is nothing wrong with the conversion process, there is something wrong with the interaction between forrest and the daisy publisher, but only when running on the zones. With respect to the speed, I have noticed one of my own sites, building using a different instance of Daisy is also very slow. I'm thinking that the caching of the site.xml file (which is generated from the daisy.site.* urls) may be failing for some reason (this is done in the sitemap). I'll investiagate as soon as I can. What I find interesting about the failures is that they all come towards the end of the build, and at inconsitent times. I've seen something similar when I have been doing a manual forrestbot build and the cron job for updating the forrest installation has fired up in the middle of the build. I wonder if the two cron jobs are overlapping - this is especially likely if the build on the zones is as slow as you are experiencing locally. Bingo ... i hope. Checked the crontab and yes i left an experimental cron entry which was rebuilding forrest trunk and interfering with the end of that. Sorry for the noise. -David
RE: [vote] Niclas Hedhman as a new Cocoon committer
Please cast your votes. +1 max
[vote] Simone Gianni as a new Cocoon committer
Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. +1 -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [vote] Niclas Hedhman as a new Cocoon committer
On 23 Mar 2006, at 18:26, Daniel Fagerstrom wrote: Hi all! I'd like to propose Niclas Hedhman as a new Cocoon committer. He has been around at cocoon-dev since 2000, regularly delivering insight full comments about technical as well as community questions, high quality patches and strong opinions in various topics ;) He has been and is committer and active in several other Apache projects and have started some OS projects outside Apache. He is also an expert member of JSR 291 (OSGi), and earlier JSR-78 (RMI Custom Remote References). Please cast your votes. +1 Welcome Niclas !! regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. +1 Regards, Upayavira
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez said the following on 24-03-2006 11:19: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. +1 Bye, Helma
Re: [vote] Simone Gianni as a new Cocoon committer
On 3/24/06, Sylvain Wallez [EMAIL PROTECTED] wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. I consider Simone a good friend of mine, an excellent developer and a great person overall: I'm certain he will do lots of good stuff. I'm delighted to see him join the Cocoon team, so here is my +1. Given my personal relationship with him, however, I'd like to ask you guys to consider it as a non-binding vote, much rather as an enthousiastic pat on his back. Welcome aboard, Simone! -- Gianugo Rabellino Sourcesense, making sense of Open Source: http://www.sourcesense.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. I met Simone in Amsterdam a couple of weeks ago, and can't wait to see him commit some of the things he told me about! A big +1 from me. 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/ Orixo alliance: http://www.orixo.com/
RE: [vote] Simone Gianni as a new Cocoon committer
Please cast your votes. +1 max
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. +1 Sylvain -- Sylvain Wallez http://bluxte.net Apache Software Foundation Member
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: Simone Gianni for Cocoon committership. +1 -David
Re: [vote] Simone Gianni as a new Cocoon committer
On Fri, 2006-03-24 at 11:19 +0100, Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. +1 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
[jira] Commented: (COCOON-1806) [PATCH] Java class custom validator builder
[ http://issues.apache.org/jira/browse/COCOON-1806?page=comments#action_12371716 ] Andrew Madu commented on COCOON-1806: - What is the svn path? I tried http://svn.apache.org/viewcvs.cgi/cocoon/branches/ and keep getting propfind request failed on '/viewcvs.cgi/cocoon/branches' Andrew [PATCH] Java class custom validator builder --- Key: COCOON-1806 URL: http://issues.apache.org/jira/browse/COCOON-1806 Project: Cocoon Type: New Feature Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, javavalidator.diff, javavalidator2.diff Implemented a custom java validator builder, very similar to the custom java listener builder. Also implemented a sample birthday validator and added it to form2 sample. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [vote] Simone Gianni as a new Cocoon committer
Le 24 mars 06 à 11:19, Sylvain Wallez a écrit : ...It's time for him to be able to commit his patches himself!.. Yes indeed! +1 and welcome Simone! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Properties for NekoHTMLGenerator
On Fri, 2006-03-24 at 10:17 +0100, Jean-Baptiste Quenot wrote: Hello, Can you please comment on this: https://issues.apache.org/jira/browse/COCOON-1639#action_12371243 Excerpt from the comment: I was about to commit [the new NekoHTMLTransformer] when I noticed neko.properties containing URLs as property keys. The javadoc for java.util.Properties states that « The key contains all of the characters in the line starting with the first non-white space character and up to, but not including, the first unescaped '=', ':', or white space character other than a line terminator. ». Example: http://xml.org/sax/features/namespaces=true http://cyberneko.org/html/features/balance-tags=true Has someone been able to test the settings in neko.properties successfully? If this is the case, why is the colon after http not interpreted as a key separator? Or quoting Andrew Stevens « at worst it just needs the colons to be escaped ». I have never used those components, but you're quite right that this can't work. The colons will need to be escaped. Good observation. -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [vote] Niclas Hedhman as a new Cocoon committer
Daniel Fagerstrom wrote: Hi all! I'd like to propose Niclas Hedhman as a new Cocoon committer. He has been around at cocoon-dev since 2000, regularly delivering insight full comments about technical as well as community questions, high quality patches and strong opinions in various topics ;) He has been and is committer and active in several other Apache projects and have started some OS projects outside Apache. He is also an expert member of JSR 291 (OSGi), and earlier JSR-78 (RMI Custom Remote References). Please cast your votes. /Daniel late +1 and welcome! -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. Sylvain +1 and welcome! -- Leszek Gawron [EMAIL PROTECTED] IT Manager MobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
RE: [vote] Simone Gianni as a new Cocoon committer
It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. +1 I think I know Simone from my earlier life at CERN? Cheers, Alfred. This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company.
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez skrev: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. +1 /Daniel
[jira] Commented: (COCOON-1806) [PATCH] Java class custom validator builder
[ http://issues.apache.org/jira/browse/COCOON-1806?page=comments#action_12371721 ] Simone Gianni commented on COCOON-1806: --- SVN repository path : http://svn.apache.org/repos/asf/cocoon Online html repository browsing : http://svn.apache.org/viewcvs.cgi/cocoon/branches/ Nightly generated downloadable 2.1.X svn snapshots : http://svn.apache.org/snapshots/cocoon-BRANCH_2_1_X [PATCH] Java class custom validator builder --- Key: COCOON-1806 URL: http://issues.apache.org/jira/browse/COCOON-1806 Project: Cocoon Type: New Feature Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Attachments: javavalidator-conf.diff, javavalidator-trunk.diff, javavalidator.diff, javavalidator2.diff Implemented a custom java validator builder, very similar to the custom java listener builder. Also implemented a sample birthday validator and added it to form2 sample. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [vote] Niclas Hedhman as a new Cocoon committer
Daniel Fagerstrom wrote: I'd like to propose Niclas Hedhman as a new Cocoon committer. +1 Vadim
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. +1 Vadim
Re: [vote] Simone Gianni as a new Cocoon committer
Il giorno 24/mar/06, alle ore 11:19, Sylvain Wallez ha scritto: It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. +1 Ugo -- Ugo Cei Blog: http://agylen.com/ Open Source Zone: http://oszone.org/ Evil or Not?: http://evilornot.info/ Company: http://www.sourcesense.com/
Re: [vote] Simone Gianni as a new Cocoon committer
On 24 Mar 2006, at 10:19, Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. +1 !!! Two in one day, WOW ! Welcome Simone ! regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote:
Hi all,
It's spring time, new committers are blossoming! I'd like to propose
Simone Gianni for Cocoon committership.
Simone has contributed interesting additions and bug fixes to CForms
that show a very good understanding of this stuff, and is participating
more and more to discussions. It's time for him to be able to commit his
patches himself!
Please cast your votes.
Sylvain
+1, welcome!
--
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] Niclas Hedhman as a new Cocoon committer
On Friday 24 March 2006 02:26, Daniel Fagerstrom wrote: Hi all! I'd like to propose Niclas Hedhman as a new Cocoon committer. He has been around at cocoon-dev since 2000, regularly delivering insight full comments about technical as well as community questions, high quality patches and strong opinions in various topics ;) He has been and is committer and active in several other Apache projects and have started some OS projects outside Apache. He is also an expert member of JSR 291 (OSGi), and earlier JSR-78 (RMI Custom Remote References). Please cast your votes. Thank you all. I have been around Cocoon since the first day, when Stefano dropped a note on this new cool way of delivery on the JServ mailing list, and asked if anyone thought it was a good idea to start a project around it. Those were the days when mailing lists were hosted on workingdogs, it was new, it was fresh, it was exciting and Cocoon offered a radical new approach on server side processing. The 1.x series exposed a lot of problems with the initial reactor design, and the ver 2 was started, several times. It was painful, but definately worth it. Ver 2 added Cocoon product after cool. Since these days, Cocoon has matured and grown bigger, some say grown too big. Too big for its own good. It is not modular enough. Blocks were invented to save the day. It helped some, but the real blocks concept eluded the grasp of community. Real blocks requires fundamental changes, and too many people remember the pain of the 1.x to 2.x transition and swear never again. Either small steps or no steps. I feel OSGi is last chance for Cocoon to revitalize itself, and enter a 3rd generation of exciting technology. The importance of OSGi is enormous (you will hear more in due time) and the Cocoon community must prepare itself for; * Binary, hot-pluggable binary blocks of functionality. * Binary, hot-pluggable extensions to the Cocoon framework. * GUI clients deploy in the Cocoon instance for management/monitoring tasks. * Multiple implementations of well-accepted services. * Multiple incompatible versions of the same feature co-existing in runtime. * Hot-pluggable content, sub-sites, portlets. * Quicker turn-around on releases. * Faster pace of development, and more non-disruptive experiments. * Flash, Java, XUL and whatever MS is up to as richer clients. * User workbenches. * real Rich Clients probably Eclipse-based applications. * and a lot more... Cocoon has for very long been a integration platform where all kinds of cool stuff works together. Even things that were never meant to work together has been implemented. Keeping this up will become ever more complicated, but with better modularity, binary pluggability, and a large and dedicated community, it will be possible. Now, with all that said; Ironically, I am no longer a Cocoon user. I found new toys, doing a lot less web and more RCP, embedded and mobile stuff. So, suddenly being voted into Cocoon as a committer is awkward... However, I will try to help Daniel, Reinhard and others with the OSGi side of things as much as I can. I urge everyone to try and get an understanding of what OSGi is, and what it means to Cocoon. Daniel have tried to explain it many times at different levels, but due to its enormous impact on everything, it is difficult for most developers here to see the light. I will try to find, or even make, some introductory material, and slowly associate each of the basics into how Daniel et al are applying that to Cocoon. Maybe I will even start using Cocoon again as a result of this :o) Cheers Niclas P.S. The introduction mentions strong opinions... :o) I am as blunt as beach ball and don't do well in political organizations, but the Avalon debacle taught me one thing; Relax, it is not important! and I feel much more relaxed nowadays. Or maybe that is because of my 2yr old son...
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. Sylvain +1 Ralph
Re: [vote] Niclas Hedhman as a new Cocoon committer
Le 24 mars 06 à 15:22, Niclas Hedhman a écrit : ...Thank you all Thanks Niclas for your thoughts and very interesting views! -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez escribió: Hi all, It's spring time, new committers are blossoming! I'd like to propose Simone Gianni for Cocoon committership. Simone has contributed interesting additions and bug fixes to CForms that show a very good understanding of this stuff, and is participating more and more to discussions. It's time for him to be able to commit his patches himself! Please cast your votes. Sylvain +1 Best Regards, Antonio Gallardo
Re: [vote] Simone Gianni as a new Cocoon committer
Sylvain Wallez wrote: Simone Gianni for Cocoon committership. +1, welcome Simone! Jorg
[jira] Created: (COCOON-1812) Javaflow and Ajax when sending two forms one after eachother
Javaflow and Ajax when sending two forms one after eachother Key: COCOON-1812 URL: http://issues.apache.org/jira/browse/COCOON-1812 Project: Cocoon Type: Bug Components: Blocks: Forms, Blocks: Java Flow Versions: 2.1.9-dev (current SVN) Reporter: Simone Gianni Priority: Critical In javaflow, if I try to send an ajax form and then send another ajax form I obtain a NPE originating from JXMacroHelper. For example : FormInstance fi = new FormInstance(myform.def.xml); fi.show(mypipe); fi = new FormInstance(myotherform.def.xml); fi.show(myotherpipe); I receive an NPE originating from JXMacroHelper:162 while showing the second forms. After investigations i noticed that the second form was displayed following the ajax behaviour, while this second form is new and should not be ajaxed. This causes the updatedWidgets list to be null (both in form and in JXMacroHelper) and thus the NPE. Sniffing the http traffic showed me that while in javascript the submission of the first form causes a bu:continue/ and a new non-ajax request from the browser, while with javaflow this does not happen. Seems like the lines from 176 to 201 of /cocoon-2.1.X/src/blocks/forms/java/org/apache/cocoon/forms/flow/javascript/Form.js were not ported to the javaflow FormInstance. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[RT] Set min JVM to 1.4 after 2.1.9?
Hi: Facts: 1. We are not able to update some libraries. ie: lucene, itext, eclipse jdt compiler, joost, icu4j, and the list is growing every day. 2. There are some blocks that silently does not compile in 1.3 at all. ie: faces, jcr. 3. There are some blocks that compiles using Java 1.3 but don't run. 4. Java 1.6 (Mustag) already released a beta. Once it will be out, we will have in hands 4 different JVM to care of. As we see, Java 1.3 is stoping us in many ways, hence the need for raising the minimal required JVM version for 2.1.x branch. Perhaps, we should do a note about this in the 2.1.9 Release Notes. That way our users will have time to prepare for switching JVM. WDYT? Best Regards, Antonio Gallardo.
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Antonio Gallardo wrote: WDYT? I agree with all points, but personally I'd prefer to release 2.2 (defined as: 2.1 + new core + mvn monolithic build) and stop maintenance of 2.1 branch. Don't you think this will be a better alternative? :) Vadim
[jira] Created: (COCOON-1813) fb:identify doesn't work with repeater of repeaters
fb:identify doesn't work with repeater of repeaters --- Key: COCOON-1813 URL: http://issues.apache.org/jira/browse/COCOON-1813 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Eric Meyer I have a repeater where each row contains a different repeater (concretely a repeater of tabs where each row contains a repeater of modules). I used the tasktree example (http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/do-taskTree.flow) for a sample structure to get me started. I can see that the fb:identity bindings for both the outer and inner repeaters are being loaded successfully. However reordering inner or outer repeater elements does not result in any of the collection items being reordered in the underlying object model. If i remove my fb:identity bindings, then new objects are successfully created each time the form is saved (and the old ones are discarded). This is not ideal, as the objects are persistent (mapped using Hibernate). I have a work-around, but it's not pretty. The use of repeaters inside repeaters is pretty rare, so I think I just stumbled into a dusty corner. I'd be happy to collaborate on a fix. Regards, Eric -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Vadim Gritsenko escribió: Antonio Gallardo wrote: WDYT? I agree with all points, but personally I'd prefer to release 2.2 (defined as: 2.1 + new core + mvn monolithic build) and stop maintenance of 2.1 branch. Don't you think this will be a better alternative? :) While I understand the importance of the cocoon versioning system. I don't see the point to have a new major release right now. I also understand Cocoon 2.1 is a settled version. A version that we can keep improving until the next major version hit the streets. For this reasons, I prefer to wait for 2.2. IMHO, it's important for us to include osgi support and real blocks in 2.2. It will make a huge difference. I am sorry for being useful in this effort. As many of us (Cocoon committers), I have been very busy in own things for few months. Why waste our few resources creating a mvn monolithic build just for few weeks? Do we eagerly need a new version? If so, we should stabilize 2.2 and release an alpha of the current trunk as is. BTW, these days, I feel like cocoon is eagerly releasing just because a boss somewhere needs a tagged versioned and released code before starting or launching his internal project. Are we forced to third-party schedule? Why not the opposite? Whatever. I want to state this was exactly the reasons why I didn't vote for the 2.1.8 release [1]. I accept it is my fault for not externalizing my concern at the right moment. But I think we need to think about this. Or is this only me? We need a plan and we need to try to follow the plan. Also, if we release 2.2 as you suggest How long will be the 2.2 life? IMHO, very short. Makes sense at all? Best Regards, Antonio Gallardo. [1] http://marc.theaimsgroup.com/?t=11314474223 Vadim
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Antonio Gallardo wrote: Vadim Gritsenko escribió: Antonio Gallardo wrote: WDYT? I agree with all points, but personally I'd prefer to release 2.2 (defined as: 2.1 + new core + mvn monolithic build) and stop maintenance of 2.1 branch. Don't you think this will be a better alternative? :) While I understand the importance of the cocoon versioning system. I don't see the point to have a new major release right now. I also understand Cocoon 2.1 is a settled version. A version that we can keep improving until the next major version hit the streets. For this reasons, I prefer to wait for 2.2. IMHO, it's important for us to include osgi support and real blocks in 2.2. I disagree with you here. It is more important for me to get new core and new 2.2 features out really soon - so it is possible to get it stabilized and start moving existing new projects - rather than wait several more years for Cocoon Vista to appear on horizon. Releases should happen often and with relatively small number of changes. Not once in a decade with 60% of code re-written... Why waste our few resources creating a mvn monolithic build just for few weeks? (answer: because it is required anyway for backward compatibility) Do we eagerly need a new version? If so, we should stabilize 2.2 and release an alpha of the current trunk as is. Completely agree: next release can use ant build, it does not have to be maven, if it helps to push release earlier. Two month after that, 2.3 release can bring maven. 2.4 can bring OSGi. etc. BTW, these days, I feel like cocoon is eagerly releasing just because a boss somewhere needs a tagged versioned and released code before starting or launching his internal project. Are we forced to third-party schedule? Why not the opposite? For me it is exactly the opposite. The longer it takes to get next 2.X Cocoon release out, the harder it will be for me to switch to it. Also, if we release 2.2 as you suggest How long will be the 2.2 life? IMHO, very short. Makes sense at all? Ideally, life of each release should be short - say, 25 Internet years? Continuing with 2.1.X starting to feel like necrophilia... :-P Vadim
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Vadim Gritsenko wrote: rather than wait several more years for Cocoon Vista to appear on horizon. ^ Man, that's nasty ;) Luca Morandini www.lucamorandini.it
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Vadim Gritsenko wrote: rather than wait several more years for Cocoon Vista to appear on horizon. And that's even nastier ;) Luca Morandini www.lucamorandini.it
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Vadim Gritsenko escribió: Antonio Gallardo wrote: WDYT? I agree with all points, but personally I'd prefer to release 2.2 (defined as: 2.1 + new core + mvn monolithic build) and stop maintenance of 2.1 branch. Don't you think this will be a better alternative? :) Vadim retrying... What does it mean? A do nothing? Best Regards, Antonio Gallardo.
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Antonio Gallardo wrote: Vadim Gritsenko escribió: Antonio Gallardo wrote: WDYT? I agree with all points, but personally I'd prefer to release 2.2 (defined as: 2.1 + new core + mvn monolithic build) and stop maintenance of 2.1 branch. Don't you think this will be a better alternative? :) retrying... What does it mean? A do nothing? It means keep 2.1 as is, with 2.1.9 being the last release, and concentrate on getting 2.2 out. Vadim (who also should start working on 2.2)
Re: [RT] Set min JVM to 1.4 after 2.1.9?
Vadim Gritsenko wrote: Antonio Gallardo wrote: WDYT? I agree with all points, but personally I'd prefer to release 2.2 (defined as: 2.1 + new core + mvn monolithic build) and stop maintenance of 2.1 branch. Don't you think this will be a better alternative? :) Vadim Even if trunk isn't released for months, I'd prefer that 2.1.9 become 2.2 before switching to JDK 1.4. In other words, I'm not in favor of 2.1.x ever being upgraded to JDK 1.4. However, I'm ok with creating a 2.2.x branch that contains 2.1.9 and making the minimum JDK 1.4. But if trunk can be released by the end of May then I would prefer that. Ralph
Re: [vote] Simone Gianni as a new Cocoon committer
+1 cheers -- Torsten
[jira] Updated: (COCOON-1639) [patch] NekoHTMLTransformer
[ http://issues.apache.org/jira/browse/COCOON-1639?page=all ]
Andrew Stevens updated COCOON-1639:
---
Attachment: neko.properties
To test out various neko properties, I did a couple of unit tests for the neko
generator. Unfortunately, all they really showed was how troublesome nekohtml
is :-( For example, with
script!--
function doNothing() { return 0; }
//--/script
in the source file, despite setting the property
http\://cyberneko.org/html/features/scanner/script/strip-comment-delims=true
( Specifies whether the scanner should strip HTML comment delimiters (i.e.
!-- and --) from script element content.) I still got the comment
delimiters in the output. I also discovered it fixes bifoo/b/i as
bifoo/i/bi/ rather than just the bifoo/i/b I was expecting.
And when I omitted a closing /h1 tag, leaving h1foopbar..., Neko didn't
close it until the end of the body, even though IIRC headings can only contain
inline elements and p is a block element. Or maybe that's only the case for
4.01 Strict? At any rate, there was also the fact that when I set the various
doctype properties, although I'd specified false for the validate parameter
on the xml-parser component something still read the strict.dtd from w3.org and
then complained that it contained syntax errors!
All in all, I don't think I'll bother uploading my test cases here ;-)
However, in the course of all this I did discover that escaping the colons in
the properties file is indeed necessary, so here's an updated neko.properties
for the WEB-INF directory.
[patch] NekoHTMLTransformer
---
Key: COCOON-1639
URL: http://issues.apache.org/jira/browse/COCOON-1639
Project: Cocoon
Type: Improvement
Components: Blocks: HTML
Versions: 2.1.8
Environment: Operating System: All
Platform: All
Reporter: Andrew Stevens
Assignee: Jean-Baptiste Quenot
Priority: Minor
Attachments: NekoHTMLTransformer.java, NekoHTMLTransformer.java, cocoon.log,
combined.diff, htmlblock.diff, neko.properties, neko.properties, samples.diff
The html block contains HTMLGenerator, HTMLTransformer, NekoHTMLGenerator
and...
hey, where's the NekoHTMLTransformer?
So, just to complete the set, here's one I prepared earlier :-)
I've also included an (empty) neko.properties configuration file, and updated
the neko generator's setup bits to allow for setting parser features as well
as
properties.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [RT] Set min JVM to 1.4 after 2.1.9?
From: Ralph Goers [EMAIL PROTECTED] Date: Fri, 24 Mar 2006 14:22:18 -0800 Even if trunk isn't released for months, I'd prefer that 2.1.9 become 2.2 before switching to JDK 1.4. In other words, I'm not in favor of 2.1.x ever being upgraded to JDK 1.4. However, I'm ok with creating a 2.2.x branch that contains 2.1.9 and making the minimum JDK 1.4. But if trunk can be released by the end of May then I would prefer that. Speaking as just a user (so feel free to ignore me), it seems to me that that dropping JDK 1.3 (and/or servlet 2.2) support would warrant rolling the version number to 2.2.x; continue to support it on the 2.1.x branch, even if that means 2.1.9 is the last release in that series. Seeing as only this afternoon I had to make Fins build under 1.3 (due to the Websphere version we have to deploy to in our US datacentre), I'm a fan of 1.3 compatibility :-) Which reminds me, can anyone suggest a library to read (awt) images from an inputsource, since javax.imageio (which Fins uses to set background images on charts) is 1.4+? Andrew.
[jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule
[ http://issues.apache.org/jira/browse/COCOON-1574?page=comments#action_12371831 ] Gavin commented on COCOON-1574: --- Hi Guys, Any progress on this issue at all. Forrest is looking to a new release soon, and we have an issue that depends on this one currently scheduled to be fixed before the release. Thanks Gav... Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: http://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1574) Memory Leak with XMLFileModule
[ http://issues.apache.org/jira/browse/COCOON-1574?page=comments#action_12371833 ] Ralph Goers commented on COCOON-1574: - Not yet. I hope to get to this in the next couple of days. Memory Leak with XMLFileModule -- Key: COCOON-1574 URL: http://issues.apache.org/jira/browse/COCOON-1574 Project: Cocoon Type: Bug Components: * Cocoon Core Versions: 2.2-dev (Current SVN) Environment: Operating System: Windows XP Platform: PC Reporter: Ron Blaschke Assignee: Ralph Goers I'm currently looking into a memory leak issue at Apache Forrest. Forrest's site currently needs to be built with -Xmx128m because of this. I believe the issue is originated at Cocoon's LinkRewriterTransformer or XMLFileModule. A memory profiler shows lots (30MB+) of DOM DocumentImpls (150+ objects), which get referenced by XMLFileModule.DocumentHelper. Their URIs are linkmap-xxx. LinkRewriterTransformer#createTransformedLink(String) uses a InputModuleHelper, which seems to reference a XMLFileModule. ... newLink = (String) modHelper.getAttribute(this.objectModel, ^ ... The XMLFileModule keeps the visited documents in a map, which is where they build up. Just for testing, I changed XMLFileModule#getDocumentHelper(Configuration) from this.documents.put(src, new DocumentHelper(reload, cache, src, this)); to return new DocumentHelper(reload, cache, src, this); Thus, a new DocumentHelper is created every time, instead of caching them. The result: No more memory problems, Apache Forrest's site builds again with -Xmx32. Ron -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
