Re: [RANT] The Cocoon website: move on, nothing is happening here
On 10/19/06, Ross Gardler [EMAIL PROTECTED] wrote: ...But is there any need for the news item to be sent to the live server immediately? I don't think so. A daily update will do just fine. For now use the Forrest generated tar, or a maven generated tar if someone sets it up... You're right, we don't have a need for immediate publishing, a few hours delay could be good enough. Let's see what happens with continuum, but in the meantime we could work as you suggest (assuming someone does write stuff, of course ;-) -Bertrand
Forrest zone auto startup (was: [RANT] The Cocoon website: move on, nothing is happening here)
On 10/20/06, David Crossley [EMAIL PROTECTED] wrote: ...Forrest doesn't have automatic httpd restart and the zones machine goes down a lot... Note that, altough Solaris apparently has something new and improved, the old rc*.d stuff does work. On the cocoon zone we have created the usual apache2 start script links: /etc/rc0.d/K16apache2 /etc/rc1.d/K16apache2 /etc/rc2.d/K16apache2 /etc/rc3.d/S50apache2 /etc/rcS.d/K16apache2 And they work fine. Also, if you need to startup non-root stuff automatically, I have created a script for that on our zone, see http://issues.apache.org/jira/browse/COCOON-1923. This is also started in /etc/rc3.d and calls $HOME/rc/start and $HOME/rc/stop for each user where these files exist. We use it to start Daisy, the Cocoon demos and Continuum on our zone, all running under their respective usernames. -Bertrand
Re: Forrest zone auto startup
Bertrand Delacretaz wrote: David Crossley wrote: ...Forrest doesn't have automatic httpd restart and the zones machine goes down a lot... Note that, altough Solaris apparently has something new and improved, the old rc*.d stuff does work. On the cocoon zone we have created the usual apache2 start script links: /etc/rc0.d/K16apache2 /etc/rc1.d/K16apache2 /etc/rc2.d/K16apache2 /etc/rc3.d/S50apache2 /etc/rcS.d/K16apache2 And they work fine. Also, if you need to startup non-root stuff automatically, I have created a script for that on our zone, see http://issues.apache.org/jira/browse/COCOON-1923. This is also started in /etc/rc3.d and calls $HOME/rc/start and $HOME/rc/stop for each user where these files exist. We use it to start Daisy, the Cocoon demos and Continuum on our zone, all running under their respective usernames. Thanks for your help mate. One of us that has access to both zones will get around to it. http://issues.apache.org/jira/browse/FOR-940 -David
Re: [RANT] The Cocoon website: move on, nothing is happening here
Niclas Hedhman wrote: Steven Noels wrote: What those Belgian guys ? however (in)frequently murmured amongst themselves was: why the ? stupid fixation with SVN as a required content repository for ? official ASF documentation sites? Why can't cocoon.apache.org simply ? be a proxy for http://cocoon.zones.apache.org/daisy/documentation/ ? I think it is related to the principles of primary resources; - mailing lists - subversion - ? which infrastructure works hard to make sure are operational, backed-up, fail-over, disaster planning et al. Wiki and other stuff is not considered primary, and doesn't enjoy the attention of the infrastructure folks. Yep. Also the cocoon.zones.apache.org is only an experimental playground. It is risky to rely on it. There is a lot of mis-information about the use of SVN and websites. The docs source content is an asset and needs to be stored. The generated docs currently need to be in SVN so that websites can be easily restored by the infrastructure people. The infrastructure site-dev mailing list tried to find other solutions to enable any content repository, generate final docs to staging area, rsync to production. That has stalled. If someone has the energy, it would be great to help move that again. Any committer can subscribe. http://www.apache.org/dev/infra-mail.html ---oOo--- Anyway, here is a proposed solution for Cocoon ... - A) Store docs content in Daisy. The /2.1/ content is already there and /2.2/ is being developed. Move the content for the top-level website from xdocs into Daisy (see http://wiki.apache.org/cocoon/CocoonWebsiteUpdate). Move select docs from the current wiki.a.o/cocoon into Daisy. Remove current wiki and use Daisy instead. - B) Generate final docs into a staging area on cocoon.zones.a.o Don't care how this happens. Some straight Daisy docs, some from Maven, some generated by Forrest (would need to rsync from forrest.zones.apache.org). Using CSS we should be able to make it consistent. - C) Give each committer a local publish shell script. This updates their working copy of the cocoon/site/ SVN, then rsyncs generated docs from cocoon.zones.a.o/stage/ and does 'svn commit'. - D) A cronjob on people.apache.org does 'svn update' to put the site into production. Already happening. - E) Improve the backup of docs source. http://issues.apache.org/jira/browse/COCOON-1925 - F) Work with infrastructure site-dev@ find better solutions. -
isolate the pipeline component from rest of cocoon
Hi there, I have a bit of cocoon knowledge from the 2.0.x days, and I remember that the whole pipelining system was deeply integrated inside cocoon. I have a need for an XML pipeline system and cocoon's SAX pipeline technology is an obvious candidate. However I am not so interested in the rest, i.e. the blocks, the servlet integration, etc. Therefore I would really like to be able to isolate the pipeline from the rest of cocoon, and be able to configure and instantiate it alone. I would like to do things like this: Generator producer = MyFactory.newGenerate(...); XMLConsumer consumer = MyFactory.newConsumer(...); pipeline.generate(producer, consumer); I am willing to dig around in SVN, however it would help a lot with a few pointers. I could not find anything beyond 2.1.x on the wiki/official site. Do you have any pointers to things I should look at in SVN, or even if what I am asking for is remotely possible? best regards, - Renaud
Re: isolate the pipeline component from rest of cocoon
I am willing to dig around in SVN, however it would help a lot with a few pointers. I could not find anything beyond 2.1.x on the wiki/official site. Do you have any pointers to things I should look at in SVN, or even if what I am asking for is remotely possible? There have been discussions around this very topic now and then.But there is not much to point to. You know were the classes are ..just something that needs to be done. MO this would be more than useful!. cheers - Torsten
imageop-block in 2.2
Hi, In cocoon 2.1 there is an imageop-block that allows more powerful image transformations then the standard image reader. It is based on a contribution https://issues.apache.org/jira/browse/COCOON-1301 but not yet ported to Cocoon 2.2. I see Jean-Baptiste started porting, but was unable to finish it, so if there are no obections, I will start porting it to cocoon 2.2. Lars Lars Trieloff visit http://www.mindquarry.com/
Re: isolate the pipeline component from rest of cocoon
On 10/20/06, Torsten Curdt [EMAIL PROTECTED] wrote: ...MO this would be more than useful!... Sure - anyone who makes this happen is going to get a Hero Plate I guess. -Bertrand
Writing and managing news releases (was Re: [RANT] The Cocoon website: move on, nothing is happening here)
Bertrand Delacretaz wrote: On 10/19/06, Ross Gardler [EMAIL PROTECTED] wrote: ...But is there any need for the news item to be sent to the live server immediately? I don't think so. A daily update will do just fine. For now use the Forrest generated tar, or a maven generated tar if someone sets it up... You're right, we don't have a need for immediate publishing, a few hours delay could be good enough. Let's see what happens with continuum, but in the meantime we could work as you suggest (assuming someone does write stuff, of course ;-) For those interested Reinhard and I have made a small start on the configuration of Daisy to manage news items in the 2.2 docs. The output needs to be prettied up - but it does work. Basically, create a new document of type NewsItem and publish it (or get an editor to publish it for you). The seven most recent will appear on the welcome page [1] I've added a tagging system that allows filtered news items to appear on welcome pages for sub-sites for each block. The tags field is free form, you can enter anything you want. We can use this field to filter news items. At present there is only one tag that does anything. If you add core to the tags your news item will appear on the core sub-site [2] [I'm not too familiar with the intended use of the cdocs layout can someone check I put this in the right place.] Sorry I've not added news filters for all of the blocks or added the lazy consensus date filter to the queries - no time today - maybe someone can do this. Ross [1] http://cocoon.zones.apache.org/daisy/cdocs/g2/g1/g1/1213.htm [2] http://cocoon.zones.apache.org/daisy/cdocs-core/1270.html
Re: imageop-block in 2.2
Lars Trieloff wrote: In cocoon 2.1 there is an imageop-block that allows more powerful image transformations then the standard image reader. It is based on a contribution https://issues.apache.org/jira/browse/COCOON-1301 but not yet ported to Cocoon 2.2. I see Jean-Baptiste started porting, but was unable to finish it, so if there are no obections, I will start porting it to cocoon 2.2. +1 Vadim
Re: isolate the pipeline component from rest of cocoon
Renaud Bruyeron wrote:
Therefore I would really like to be able to isolate the pipeline from
the rest of cocoon, and be able to configure and instantiate it alone.
I would like to do things like this:
Generator producer = MyFactory.newGenerate(...);
XMLConsumer consumer = MyFactory.newConsumer(...);
pipeline.generate(producer, consumer);
It is possible to use pipelines directly, it would look something like:
...setup container...
ProcessingPipeline pipeline = new [Non]CachingProcessingPipeline();
pipeline.enableLogging(...);
while (...) {
pipeline.setup(new Parameters());
// Pipeline will get generator from container
pipeline.setGenerator(file, ...);
pipeline.addTransformer(xslt, ...);
pipeline.setSerializer(html, ...);
Environment env = new BackgroundEnvironment(...);
pipeline.process(env);
pipeline.recycle();
}
I am willing to dig around in SVN, however it would help a lot with a
few pointers. I could not find anything beyond 2.1.x on the
wiki/official site.
Cocoon 2.2 (spring based) is in trunk, Cocoon 2.1 (avalon based) is in branch.
Do you have any pointers to things I should look at in SVN, or even if
what I am asking for is remotely possible?
It might be more complex than what you want but it's possible.
Vadim
Re: isolate the pipeline component from rest of cocoon
It is possible to use pipelines directly, it would look something like: ...setup container... Sorry, but please without that ;-) cheers -- Torsten
Re: isolate the pipeline component from rest of cocoon
Torsten Curdt wrote: It is possible to use pipelines directly, it would look something like: ...setup container... Sorry, but please without that ;-) Where would you get dependencies from? SourceResolver, Cache, Store, what else? And, AFAIU, setting up Spring is way easier than Excalibur. Vadim
[jira] Updated: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=all ] Lars Trieloff updated COCOON-1301: -- Attachment: cocoon-imageop-2.2.tar.gz Complete port of the imageop block to Cocoon 2.2. To be extracted in trunk/blocks. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, imageop-block.zip I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- 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] Updated: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=all ] Lars Trieloff updated COCOON-1301: -- Attachment: cocoon-imageop-2.2.tar.gz Same file, without compiled classes. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, cocoon-imageop-2.2.tar.gz, imageop-block.zip I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- 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: [jira] Updated: (COCOON-1301) [Patch] Image Operation Reader
Lars Trieloff (JIRA) wrote: [ http://issues.apache.org/jira/browse/COCOON-1301?page=all ] Lars Trieloff updated COCOON-1301: -- Attachment: cocoon-imageop-2.2.tar.gz You can apply it yourself now. Vadim
Re: isolate the pipeline component from rest of cocoon
Vadim Gritsenko wrote:
Renaud Bruyeron wrote:
It is possible to use pipelines directly, it would look something like:
...setup container...
Is that the avalon container, or is it a spring container? Is there an
example of this somewhere?
ProcessingPipeline pipeline = new [Non]CachingProcessingPipeline();
pipeline.enableLogging(...);
while (...) {
pipeline.setup(new Parameters());
// Pipeline will get generator from container
pipeline.setGenerator(file, ...);
pipeline.addTransformer(xslt, ...);
pipeline.setSerializer(html, ...);
Environment env = new BackgroundEnvironment(...);
pipeline.process(env);
pipeline.recycle();
}
This looks simple enough. The recycle() method is not part of the
ProcessingPipeline interface, but all its implementations are Recyclable
(I guess this is avalon speak for to be used in a pool, and therefore
I can assume that the implementations are not threadsafe, right?).
Am I correct in assuming that cocoon pools instances of the pipelines
(one per thread) when in a webapp context ?
- Renaud
[jira] Updated: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=all ] Alexander Klimetschek updated COCOON-1301: -- Attachment: pom.xml Lars, you missed the root pom. Here it is. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, cocoon-imageop-2.2.tar.gz, imageop-block.zip, pom.xml I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- 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] Closed: (COCOON-1301) [Patch] Image Operation Reader
[ http://issues.apache.org/jira/browse/COCOON-1301?page=all ] Lars Trieloff closed COCOON-1301. - Resolution: Fixed Resolved with r466242. [Patch] Image Operation Reader -- Key: COCOON-1301 URL: http://issues.apache.org/jira/browse/COCOON-1301 Project: Cocoon Issue Type: Improvement Components: * Cocoon Core Affects Versions: 2.2-dev (Current SVN) Environment: Operating System: other Platform: Other Reporter: Niclas Hedhman Priority: Minor Attachments: cocoon-imageop-2.2.tar.gz, cocoon-imageop-2.2.tar.gz, imageop-block.zip, pom.xml I would like to contribute a fairly flexible and powerful Image Reader that is capable of performing a stack of Effects, such as Scaling, color manipulation, and coordination transforms (rotate, mirror and so forth), in a pluggable manner. The ImageOpReader also reads any of the graphics formats supported by javax.imageio package in JDK 1.4, including Png, Jpg and many more. Any image can be returned to the client browser in any of the supported formats. There is still a problem with the AffineTransform operations, and I am working on sorting these out, but; 1. The block is already useful to many as it is. 2. I could need some help getting the AffineTransforms to work properly. Stuff that is still left to do; * Image Operation tests. How does one test image tranforms? * JavaDocs. * User Documentation * Get Rotation Mirror transforms to work. (Problem related to clipping outside the positive coordinate system.) * More samples - The bulk are in place, but more doesn't hurt. I would *really* appreciate if the ImageOp block becomes part of the standard Cocoon 2.2 distribution. I am willing to help out maintaining it for the long term, if I am allowed to... P.S. I already have a CLA on file with the ASF. -- 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
