Re: [vote] Release Cocoon 2.2-final
Luca Morandini wrote: Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. There is much room for improvement in the doc though: don't you think it should be improved before release ? It would be great to have better docs, but honestly who is going to write them? We can either release with the docs we have or wait forever for better docs and never release. From these two choices I prefer the first one. Anything between these two extremes is imho not going to happen. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. If we wait for better docs we loose everyone as we never release. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [vote] Release Cocoon 2.2-final
Carsten Ziegeler wrote: Luca Morandini wrote: Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. There is much room for improvement in the doc though: don't you think it should be improved before release ? It would be great to have better docs, but honestly who is going to write them? We can either release with the docs we have or wait forever for better docs and never release. From these two choices I prefer the first one. Anything between these two extremes is imho not going to happen. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. If we wait for better docs we loose everyone as we never release. Yup. And add to this the fact that doc lifecycle is different from the software lifecycle, since there is no doc releases, but a continuous improvement. Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [vote] Release Cocoon 2.2-final
Sylvain Wallez wrote: Carsten Ziegeler wrote: Luca Morandini wrote: Reinhard Poetz wrote: I've prepared the artifacts for the release of Cocoon 2.2 final. There is much room for improvement in the doc though: don't you think it should be improved before release ? It would be great to have better docs, but honestly who is going to write them? We can either release with the docs we have or wait forever for better docs and never release. From these two choices I prefer the first one. Anything between these two extremes is imho not going to happen. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. If we wait for better docs we loose everyone as we never release. Yup. And add to this the fact that doc lifecycle is different from the software lifecycle, since there is no doc releases, but a continuous improvement. Sorry, I can't agree. Cocoon still has the same fault as many open-source products: A lack of documentation. I don't know if GSoC is for docs, too, but it is really, really necessary to improve docs. It's still the same Catch-22: To write docs you need to understand the developed, to understand the developed you need the docs, ... Writing docs does belong to development, even when it seems to be at a kindergarden level for newbies! Just my 0,02 CHF Florian
Re: [vote] Release Cocoon 2.2-final
Dev at weitling wrote: Sorry, I can't agree. Cocoon still has the same fault as many open-source products: A lack of documentation. I don't know if GSoC is for docs, too, but it is really, really necessary to improve docs. It's still the same Catch-22: To write docs you need to understand the developed, to understand the developed you need the docs, ... Writing docs does belong to development, even when it seems to be at a kindergarden level for newbies! I think we all agree that we need docs (or more/better docs), absolutely no doubt. And I think we also agree that writing docs is one task of the development process, and it's an important task. But we can't force anyone to write docs; and delaying a release because of lacking documentation is not producing the desired effect: instead of getting docs this way, nothing is usually happening: no docs and no release. I don't say that I'm happy about this. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: [vote] Release Cocoon 2.2-final
Carsten Ziegeler wrote: Dev at weitling wrote: Sorry, I can't agree. Cocoon still has the same fault as many open-source products: A lack of documentation. I don't know if GSoC is for docs, too, but it is really, really necessary to improve docs. It's still the same Catch-22: To write docs you need to understand the developed, to understand the developed you need the docs, ... Writing docs does belong to development, even when it seems to be at a kindergarden level for newbies! I think we all agree that we need docs (or more/better docs), absolutely no doubt. And I think we also agree that writing docs is one task of the development process, and it's an important task. But we can't force anyone to write docs; and delaying a release because of lacking documentation is not producing the desired effect: instead of getting docs this way, nothing is usually happening: no docs and no release. I don't say that I'm happy about this. Despite my sometimes dumb question here on the list I know Cocoon is really cool and still improving. But without good docs the developers and the users separate more and more. There are many people who want to contribute to Cocoon, but most of them do only have spare time and are not paid by a company with interest in Cocoon. For them it's really hard to dig trough the docs to understand things before they can even think of contributing code. Why not introduce documentation releases? BTW: If I could meet some of you wizards and get an indoctrination I could/would improve docs. Florian
Re: [vote] Release Cocoon 2.2-final
Carsten Ziegeler wrote: It would be great to have better docs, but honestly who is going to write them? Some (most ?) of it has been already written, it's just a matter of copying it from Javadoc (or 2.1 docs pages) to the 2.2 ones, and check its currentness, of course. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. Does it mean we already gave up with attracting new users ? What's the mission of 2.2 then ? As I see it, this release has the potential of attracting new users to a leaner, meaner Cocoon, but then we should be able to greet them appropriately. As for old users: I can talk only for myself, but I think 2.2 is great for new projects only, since it doesn't pay to Springify and Mavenize old ones. So, we got two distinct classes of users: 1) Old ones, which will use 2.2 as new projects come in, hence allowing for a rather long transition period. 2) New ones, which will be very sensible to good docs and samples and will try 2.2 right after its release. The current state of docs is good enough for the old users, not for the new ones, I think. Hence, 2.2 faces the fate of being caught between old users adopting it very slowly and new users not adopting it in great numbers... not an exciting prospect. Regards, Luca Morandini www.lucamorandini.it
2.2 Docs (was Re: [vote] Release Cocoon 2.2-final)
Hi, (Changing subject, starting new thread. Please, when an email says 'this thread is for votes only', try to respect that!) On 03/04/2008, Luca Morandini [EMAIL PROTECTED] wrote: Carsten Ziegeler wrote: We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. Does it mean we already gave up with attracting new users ? What's the mission of 2.2 then ? No, releasing without complete docs does not mean giving up on attracting new users. There have been many initiatives over the years to improve our docs but ultimately the problem remains: writing docs is hard and boring, and people are rarely willing to do this on a voluntary basis. We should accept this and get 2.2 out the door (honestly, I think delaying it further will lose more users than not having sufficient docs) and then if we can, turn some of the energy of this debate into writing docs. Better yet, let's be diligent in taking questions on the mailing lists and turning them into FAQs/documentation, and improve the docs that way. Or if anyone knows a good technical author who might be willing to participate in GSoC, please speak now! Andrew.
Re: [vote] Release Cocoon 2.2-final
Luca Morandini schrieb: Carsten Ziegeler wrote: It would be great to have better docs, but honestly who is going to write them? Some (most ?) of it has been already written, it's just a matter of copying it from Javadoc (or 2.1 docs pages) to the 2.2 ones, and check its currentness, of course. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. Does it mean we already gave up with attracting new users ? What's the mission of 2.2 then ? As I see it, this release has the potential of attracting new users to a leaner, meaner Cocoon, but then we should be able to greet them appropriately. As for old users: I can talk only for myself, but I think 2.2 is great for new projects only, since it doesn't pay to Springify and Mavenize old ones. I don't think so - that depends on the situation. We at Lenya will have to upgrade sooner or later, otherwise we'd lose touch with the Cocoon community and we'd have to backport all fixes and improvements. Most people who maintain an ongoing project will do the migration, whether it makes sense from a technological point of view or not. Regarding documentation: In my experience, one of the best ways for creating docs is via personal marketing. When people create a tutorial on their blogs or a presentation for a conference, the effort to move these contents to the project docs isn't that big (a big chunk of the Lenya documentation was developed this way). Maybe some of the developers could provide their slides? Even some links to slideshare.net could certainly be helpful. -- Andreas So, we got two distinct classes of users: 1) Old ones, which will use 2.2 as new projects come in, hence allowing for a rather long transition period. 2) New ones, which will be very sensible to good docs and samples and will try 2.2 right after its release. The current state of docs is good enough for the old users, not for the new ones, I think. Hence, 2.2 faces the fate of being caught between old users adopting it very slowly and new users not adopting it in great numbers... not an exciting prospect. Regards, Luca Morandini www.lucamorandini.it -- Andreas Hartmann, CTO BeCompany GmbH http://www.becompany.ch Tel.: +41 (0) 43 818 57 01
Re: [vote] Release Cocoon 2.2-final
Carsten Ziegeler wrote: Dev at weitling wrote: Sorry, I can't agree. Cocoon still has the same fault as many open-source products: A lack of documentation. I don't know if GSoC is for docs, too, but it is really, really necessary to improve docs. It's still the same Catch-22: To write docs you need to understand the developed, to understand the developed you need the docs, ... Writing docs does belong to development, even when it seems to be at a kindergarden level for newbies! I think we all agree that we need docs (or more/better docs), absolutely no doubt. And I think we also agree that writing docs is one task of the development process, and it's an important task. But we can't force anyone to write docs; and delaying a release because of lacking documentation is not producing the desired effect: instead of getting docs this way, nothing is usually happening: no docs and no release. I don't say that I'm happy about this. Yes. That's exactly what I meant! Thanks for making it clear Carsten :-) Sylvain -- Sylvain Wallez - http://bluxte.net
Re: [test] Instructions to test Cocoon 2.2-final
Hi On 02/04/2008, Reinhard Poetz [EMAIL PROTECTED] wrote: mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-22-archetype-block -DarchetypeVersion=1.0.0 -DgroupId=com.mycompany -DartifactId=myBlock -DremoteRepositories=http://people.apache.org/builds/cocoon/ works for me Please test the getting-started application (http://people.apache.org/~reinhard/cocoon-staging/cocoon-getting-started/) whether it runs at your environment. works for me Andrew.
Re: [vote] Release Cocoon 2.2-final
Hi, On 02/04/2008, Reinhard Poetz [EMAIL PROTECTED] wrote: Find instructions about how you can test in a seperate mail. Report your findings to that thread and use this one for voting only. Thanks! This majority vote stays open for 72 hours. +1 Andrew.
[jira] Commented: (COCOON-2063) NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8
[ https://issues.apache.org/jira/browse/COCOON-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12585165#action_12585165 ] Ellis Pritchard commented on COCOON-2063: - Anyone fancy applying the patches? NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8 --- Key: COCOON-2063 URL: https://issues.apache.org/jira/browse/COCOON-2063 Project: Cocoon Issue Type: Bug Components: Blocks: HTML Affects Versions: 2.1.11, 2.2-dev (Current SVN) Reporter: Alexander Klimetschek Attachments: NekoHTMLGenerator_BRANCH2_1_X.patch, nekohtmltransformer-encoding.patch The NekoHTMLTransformer uses the cyberneko HTMLConfiguration for tidying html. Unfortunately it does not use the system's current encoding as default, instead you have to set a property to set your encoding. But this varies from one OS to another, so the best solution is to set this property automatically in the NekoHTMLTransformer depending on what Java uses as defaultCharset: config.setProperty(http://cyberneko.org/html/properties/default-encoding;, Charset.defaultCharset().name()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: JNet integration doubts
Grzegorz Kossakowski wrote:
Hello,
I've played with JNet for a while trying to integrate it with SSF and run
into many troubles.
First of all, I'm not sure if I understand whole concept correctly. Do I
understand correctly that JNet provides SourceURLStreamHandlerFactory class
that acts just like a bridge supporting legacy Source implementations? Should
we consider URLStreamHandlerFactory and URLStreamHandler as general
replacements for SourceFactory and Source interfaces?
If a long-term goal is to drop Source and SourceFactory interfaces what about
extension like ModifiableSource, MoveableSource, PostableSource? How can they
be supported by URLConnection and friends?
--- o0o ---
Another problem is with the implementation. There is a problem with
installing SourceURLStreamHandlerFactory because: a) it must be installed
before ServletFactoryBean is being used at Spring initialization phase b) it
must be installed after ApplicationContext is created because SourceFactories
are components that must be initialized by Spring container.
I have no clue how to solve this problem. Any ideas?
Why do we have to replace the blockcontext: protocol at all?
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: JNet integration doubts
Reinhard Poetz pisze: Grzegorz Kossakowski wrote: Hello, I've played with JNet for a while trying to integrate it with SSF and run into many troubles. First of all, I'm not sure if I understand whole concept correctly. Do I understand correctly that JNet provides SourceURLStreamHandlerFactory class that acts just like a bridge supporting legacy Source implementations? Should we consider URLStreamHandlerFactory and URLStreamHandler as general replacements for SourceFactory and Source interfaces? If a long-term goal is to drop Source and SourceFactory interfaces what about extension like ModifiableSource, MoveableSource, PostableSource? How can they be supported by URLConnection and friends? --- o0o --- Another problem is with the implementation. There is a problem with installing SourceURLStreamHandlerFactory because: a) it must be installed before ServletFactoryBean is being used at Spring initialization phase b) it must be installed after ApplicationContext is created because SourceFactories are components that must be initialized by Spring container. I have no clue how to solve this problem. Any ideas? Why do we have to replace the blockcontext: protocol at all? Take a look at its current source code. There is no such a thing like blockcontext: protocol implementation at the moment. In my [RT] mail I explained how we could possibly to stop cheating pretending there is a blockcontext protocol and replace it with blockcontext expression that would better reflect current implementation. Another possibility (suggested by you) is to provide real implementation of blockcontext: protocol and use blockcontext protocol in base URLs for blocks. I cannot comment on this solution because I haven't enough free time to check all implications. Remember: you will put blockcontext into ServletContext that is rather general interface. I don't say there is any problem, I'm only saying I haven't checked if there is none. I prefer (only for now, as a quick solution) first way because there is not much room for discussion, brainstorming and general research which is quite opposite to URL-em-them-all approach. I really would like to fix SSF ASAP and let the discussion/research on URL go in parallel. -- Grzegorz Kossakowski
Re: [vote] Release Cocoon 2.2-final
Reinhard Poetz pisze: I've prepared the artifacts for the release of Cocoon 2.2 final. See the list of all proposed artifacts below. You can find the staged files for all modules (sources, binaries, javadocs, checksums, gpg signatures) at - http://people.apache.org/builds/cocoon/ (Maven 2 repo) - http://people.apache.org/builds/cocoon/cocoon-2.2-all.tar.gz (tar archive of all artifacts). SVN tags of all these artifacts can be found at http://svn.apache.org/repos/asf/cocoon/tags/cocoon-2.2/. For the final release I've also created release artifacts for people who don't want to use Maven 2 or Ivy. These artifacts can be found at - http://people.apache.org/~reinhard/cocoon-staging/. A tar containing all release artifacts is available at http://apache.org/~reinhard/cocoon-2.2-non-maven-all.tar.gz. Note that there is a special release artifact cocoon-getting-started that creates the structure of a Cocoon project, consisting of a web application and one block, that can be built by plain Ant only. Find instructions about how you can test in a seperate mail. Report your findings to that thread and use this one for voting only. Thanks! This majority vote stays open for 72 hours. - o - SUBPROJECT: COCOON CONFIGURATION - cocoon-configuration-api-1.0.2.jar - cocoon-spring-configurator-1.0.2.jar SUBPROJECT: COCOON SERVLET-SERVICE-FRAMEWORK - cocoon-servlet-service-impl-1.0.0.jar - cocoon-servlet-service-components-1.0.0.jar COCOON CORE - cocoon-xml-api-1.0.0.jar - cocoon-xml-impl-1.0.0.jar - cocoon-xml-resolver-1.0.0.jar - cocoon-xml-util-1.0.0.jar - cocoon-thread-api-1.0.0.jar - cocoon-thread-impl-1.0.0.jar - cocoon-expression-language-api-1.0.0.jar - cocoon-expression-language-impl-1.0.0.jar - cocoon-util-1.0.0.jar - cocoon-store-impl-1.0.0.jar - cocoon-pipeline-api-1.0.0.jar - cocoon-pipeline-impl-1.0.0.jar - cocoon-pipeline-impl-1.0.0-tests.jar - cocoon-pipeline-components-1.0.0.jar - cocoon-sitemap-api-1.0.0.jar - cocoon-sitemap-impl-1.0.0.jar - cocoon-sitemap-impl-1.0.0-tests.jar - cocoon-sitemap-components-1.0.0.jar - cocoon-core-2.2.0.jar - cocoon-core-2.2.0-tests.jar COCOON BLOCKS - cocoon-template-impl-1.1.0.jar* - cocoon-flowscript-impl-1.0.0.jar - cocoon-auth-api-1.0.0.jar - cocoon-auth-impl-1.0.0.jar - cocoon-batik-impl-1.0.0.jar - cocoon-captcha-impl-1.0.0.jar - cocoon-fop-impl-1.0.0.jar - cocoon-html-impl-1.0.0.jar - cocoon-linkrewriter-impl-1.0.0.jar - cocoon-mail-impl-1.0.0.jar - cocoon-databases-hsqldb-client-1.0.0.jar - cocoon-databases-hsqldb-server-1.0.0.jar - cocoon-databases-mocks-1.0.0.jar - cocoon-databases-impl-1.0.0.jar - cocoon-databases-bridge-1.0.0-jar - cocoon-ajax-impl-1.0.0.jar - cocoon-apples-impl-1.0.0.jar - cocoon-forms-impl-1.1.0.jar* [*] The 1.0.0 releases are still missing but provided for a version that hasn't been mirgrated to Spring. These artifacts will hopefully follow soon. Any reason for such a weird practice marked with [*]? It's really questionable to release 1.1.0 before 1.0.0... -- Grzegorz Kossakowski
Re: [vote] Release Cocoon 2.2-final
Andreas Hartmann pisze: Luca Morandini schrieb: Carsten Ziegeler wrote: It would be great to have better docs, but honestly who is going to write them? Some (most ?) of it has been already written, it's just a matter of copying it from Javadoc (or 2.1 docs pages) to the 2.2 ones, and check its currentness, of course. We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. Does it mean we already gave up with attracting new users ? What's the mission of 2.2 then ? As I see it, this release has the potential of attracting new users to a leaner, meaner Cocoon, but then we should be able to greet them appropriately. As for old users: I can talk only for myself, but I think 2.2 is great for new projects only, since it doesn't pay to Springify and Mavenize old ones. I don't think so - that depends on the situation. We at Lenya will have to upgrade sooner or later, otherwise we'd lose touch with the Cocoon community and we'd have to backport all fixes and improvements. Most people who maintain an ongoing project will do the migration, whether it makes sense from a technological point of view or not. Regarding documentation: In my experience, one of the best ways for creating docs is via personal marketing. When people create a tutorial on their blogs or a presentation for a conference, the effort to move these contents to the project docs isn't that big (a big chunk of the Lenya documentation was developed this way). Maybe some of the developers could provide their slides? Even some links to slideshare.net could certainly be helpful. That's some kind of idea... Need to blow cobweb away from my blog.. :-) -- Grzegorz
Re: [vote] Release Cocoon 2.2-final
Dev at weitling pisze: Despite my sometimes dumb question here on the list I know Cocoon is really cool and still improving. But without good docs the developers and the users separate more and more. There are many people who want to contribute to Cocoon, but most of them do only have spare time and are not paid by a company with interest in Cocoon. For them it's really hard to dig trough the docs to understand things before they can even think of contributing code. Why not introduce documentation releases? To be honest I'm not sure what kind of policy we have about publishing docs but I consider this a continuous process. For example, Luca has contributed some docs that will get published once I (or any other committer) finds few minutes to review them. I don't think it makes that much sense to synchronize docs publishing with artifact releases. BTW: If I could meet some of you wizards and get an indoctrination I could/would improve docs. Florian, are you coming to ApacheCon (hackathon days)? If not, I'm available in Warsaw almost all the time always willing to speak about Cocoon. :-) -- Grzegorz Kossakowski
Re: 2.2 Docs (was Re: [vote] Release Cocoon 2.2-final)
Andrew Savory pisze: Hi, (Changing subject, starting new thread. Please, when an email says 'this thread is for votes only', try to respect that!) On 03/04/2008, Luca Morandini [EMAIL PROTECTED] wrote: Carsten Ziegeler wrote: We might not get some new users because of bad docs, but we might get people really interested in a new Cocoon. Does it mean we already gave up with attracting new users ? What's the mission of 2.2 then ? No, releasing without complete docs does not mean giving up on attracting new users. There have been many initiatives over the years to improve our docs but ultimately the problem remains: writing docs is hard and boring, and people are rarely willing to do this on a voluntary basis. Speaking about myself only but I have never found writing docs boring. Moreover, I've expierienced Cocoon bugs that were much more difficult to fix than any docs page to write. Not sure why others find it boring. Don't you like to boast about your knowledge? We should accept this and get 2.2 out the door (honestly, I think delaying it further will lose more users than not having sufficient docs) and then if we can, turn some of the energy of this debate into writing docs. Better yet, let's be diligent in taking questions on the mailing lists and turning them into FAQs/documentation, and improve the docs that way. +1 Or if anyone knows a good technical author who might be willing to participate in GSoC, please speak now! GSoC is about delivering code not documentation, see: http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_doc_proposals -- Grzegorz Kossakowski
Re: [test] Instructions to test Cocoon 2.2-final
Reinhard Poetz pisze: The proposed release artifacts of all the modules that we vote on (see the seperate voting thread) are available at http://people.apache.org/builds/cocoon/ The easiest way to test the artifacts is by adding a cocoon-staging profile to your ~/.m2/settings.xml: - o - In order to test the archetypes - cocoon-22-archetype-block-1.0.0 - cocoon-22-archetype-webapp-1.0.0 - cocoon-22-archetype-block-plain-1.0.0 append -DremoteRepositories=http://people.apache.org/builds/cocoon/ to your mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create commands, e.g. mvn org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create -DarchetypeGroupId=org.apache.cocoon -DarchetypeArtifactId=cocoon-22-archetype-block -DarchetypeVersion=1.0.0 -DgroupId=com.mycompany -DartifactId=myBlock -DremoteRepositories=http://people.apache.org/builds/cocoon/ The commands to use the archetypes and explanations of what they are for can be found at http://cocoon.apache.org/2.2/maven-plugins/ (Note: Make sure that you set the correct archetypeVersion parameter!). Tested archetypes and Cocoon artifacts quite extensively (with my own small apps). Everything works like a charm at openSUSE with Java 1.6. - o - Please test the getting-started application (http://people.apache.org/~reinhard/cocoon-staging/cocoon-getting-started/) whether it runs at your environment. - o - In general, please check if the release artifacts meet all legal requirements of the ASF. (checksums, signatures, license notice files) Will do this tomorrow. Thanks for your work Reinhard! -- Grzegorz Kossakowski
Re: JNet integration doubts
On Apr 3, 2008, at 2:58 PM, Grzegorz Kossakowski wrote: Reinhard Poetz pisze: Why do we have to replace the blockcontext: protocol at all? Take a look at its current source code. There is no such a thing like blockcontext: protocol implementation at the moment. In my [RT] mail I explained how we could possibly to stop cheating pretending there is a blockcontext protocol and A: replace it with blockcontext expression that would better reflect current implementation. B: Another possibility (suggested by you) is to provide real implementation of blockcontext: protocol and use blockcontext protocol in base URLs for blocks. I cannot comment on this solution because I haven't enough free time to check all implications. Remember: you will put blockcontext into ServletContext that is rather general interface. I don't say there is any problem, I'm only saying I haven't checked if there is none. I prefer (only for now, as a quick solution) first way because there is not much room for discussion, brainstorming and general research which is quite opposite to URL-em-them-all approach. I really would like to fix SSF ASAP and let the discussion/research on URL go in parallel. I've read your RT and I agree with conclusion that approach taken there - to convert String (blockcontext:) -- SourceResolver -- Source -- and back into String (file:) - it definitely smells bad. But, I don't think plugging dependency to expressions block (A above) is the good idea. I'd rather prefer B: make blockcontext a regular protocol, and treat context path parameter as regular source without any special treatment. I'd expect any of supported source implementations to work there, be it http, webdav, or xmldb, or even blockcontext. Vadim
[jira] Updated: (COCOON-2063) NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8
[ https://issues.apache.org/jira/browse/COCOON-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-2063: -- Affects version (Component): Parent values: Blocks: HTML(10168). Level 1 values: 1.0.0-M1(10198). Fix version (Component): Parent values: Blocks: HTML(10240). Level 1 values: 1.0.0-RC1(10271). Priority: Minor (was: Major) Affects Version/s: (was: 2.2) Fix Version/s: 2.2-dev (Current SVN) Assignee: Jörg Heinicke I fixed this issue in 2.2. The fix in 2.1 does not work since it uses java.nio which was only added in Java 1.4. Cocoon 2.1 has to be Java 1.3 compatible. Is there a way to find out the default encoding in Java 1.3? All the classes and methods were it would be necessary like new String(byte[]) or InputStreamReader() only point to http://java.sun.com/j2se/1.3/docs/api/java/lang/package-summary.html#charenc which just names some constants. With Mac OS X I also have no access to the source code of the JDK. The bytecode implies that the mentioned classes and methods use some Sun-internal class to retrieve the default encoding. NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8 --- Key: COCOON-2063 URL: https://issues.apache.org/jira/browse/COCOON-2063 Project: Cocoon Issue Type: Bug Components: Blocks: HTML Affects Versions: 2.1.11 Reporter: Alexander Klimetschek Assignee: Jörg Heinicke Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: NekoHTMLGenerator_BRANCH2_1_X.patch, nekohtmltransformer-encoding.patch The NekoHTMLTransformer uses the cyberneko HTMLConfiguration for tidying html. Unfortunately it does not use the system's current encoding as default, instead you have to set a property to set your encoding. But this varies from one OS to another, so the best solution is to set this property automatically in the NekoHTMLTransformer depending on what Java uses as defaultCharset: config.setProperty(http://cyberneko.org/html/properties/default-encoding;, Charset.defaultCharset().name()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (COCOON-2063) NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8
[ https://issues.apache.org/jira/browse/COCOON-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jörg Heinicke updated COCOON-2063: -- Affects Version/s: 2.2 NekoHTMLTransformer needs to set the default-encoding of the current system to work properly with UTF-8 --- Key: COCOON-2063 URL: https://issues.apache.org/jira/browse/COCOON-2063 Project: Cocoon Issue Type: Bug Components: Blocks: HTML Affects Versions: 2.1.11, 2.2 Reporter: Alexander Klimetschek Assignee: Jörg Heinicke Priority: Minor Fix For: 2.2-dev (Current SVN) Attachments: NekoHTMLGenerator_BRANCH2_1_X.patch, nekohtmltransformer-encoding.patch The NekoHTMLTransformer uses the cyberneko HTMLConfiguration for tidying html. Unfortunately it does not use the system's current encoding as default, instead you have to set a property to set your encoding. But this varies from one OS to another, so the best solution is to set this property automatically in the NekoHTMLTransformer depending on what Java uses as defaultCharset: config.setProperty(http://cyberneko.org/html/properties/default-encoding;, Charset.defaultCharset().name()); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[OT] Mac OS X and Java development (was: Re: [jira] Updated: (COCOON-2063))
On 03.04.2008 23:33, Jörg Heinicke (JIRA) wrote: With Mac OS X I also have no access to the source code of the JDK. Which makes me wonder again how to do serious Java development with Mac OS X. I know a few of you guys are using Mac OS X. How do you do it? Whenever I start this I get annoyed very fast. The missing Java sources are only the tip of the iceberg. Every tree representation in Eclipse just sucks. Keyboard navigation in Mac OS X is completely inconsistent, especially with Java programs. There seems to be no serious SVN command line client (or at least the CollabNet download page is just self-linking at the moment: http://downloads.open.collab.net/binaries.html). And so on ... Windows has also bunch of annoying issues but there is at least consistency and usually there is a solution for everything. Do you guys all switch to Linux when it comes to Java development? :) Joerg
Re: [vote] Release Cocoon 2.2-final
Grzegorz Kossakowski wrote:
[*] The 1.0.0 releases are still missing but provided for a version
that hasn't
been mirgrated to Spring. These artifacts will hopefully follow soon.
Any reason for such a weird practice marked with [*]? It's really
questionable to release 1.1.0 before 1.0.0...
I noticed that not until I wrote the voting mail and don't have time to create
the 1.0.0 releases of those two modules happen neither this week nor the next.
Maybe somebody else can help out ...
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
Re: JNet integration doubts
Grzegorz Kossakowski wrote:
Why do we have to replace the blockcontext: protocol at all?
Take a look at its current source code. There is no such a thing like
blockcontext: protocol implementation at the moment.
Therefore I'm asking ...
In my [RT] mail I explained how we could possibly to stop cheating
pretending there is a blockcontext protocol and replace it with
blockcontext expression that would better reflect current implementation.
making the blockcontext protocol an expression is just another big hack IMO.
Another possibility (suggested by you) is to provide real implementation
of blockcontext: protocol and use blockcontext protocol in base URLs for
blocks. I cannot comment on this solution because I haven't enough free
time to check all implications. Remember: you will put blockcontext into
ServletContext that is rather general interface. I don't say there is
any problem, I'm only saying I haven't checked if there is none.
Steven and I made the servlet protocol based on JNet work for Corona yesterday
(not committed yet). Then we had a quick look into the resolution of the
blockcontext protocol and we don't see any problem why it should not work.
I prefer (only for now, as a quick solution) first way because there is
not much room for discussion, brainstorming and general research which
is quite opposite to URL-em-them-all approach. I really would like to
fix SSF ASAP and let the discussion/research on URL go in parallel.
Making blockcontext: a real protocol seems to be the simplest and by far the
most elegant and most obvious solution. I will give this a try either today or
at the Hackathon and find out if it is really as simple as expected.
--
Reinhard PötzManaging Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair[EMAIL PROTECTED]
_
