date:20060416

Re: [RT] Mini-Cocoon

2006-04-16 Thread Sylvain Wallez

Don Brown wrote:
> For the next generation of Struts Action Framework, we have merged
> with WebWork to build the new version on its solid foundation. One of
> its powerful features are its Interceptors, which act like Servlet
> filters allowing you to define the framework workflow for the Action
> on either a per-action or per-package basis.  This lets you fully
> separate the concerns of your framework logic.
>
> I've been toying with the idea of bringing the Interceptor concept to
> the view layer, and with XHTML becoming more and more prevalent, I
> think it is ripe to bring the power of the Cocoon pipline to post-page
> processing.  I'd like a user to be able to specify an interceptor
> stack (pipeline) on a per-action or per-package basis.  This would be
> similar to the popular Sitemesh project, but more powerful has any
> page minipulation is possible.
>
> Anyways, I bring this up here because it would require a SAX-based XML
> pipeline implementation and I immedately think of Cocoon.  However,
> the requirements for such a feature would be:
>  - We only need transformers and serializers, the framework would
> handle the generation (implicitly a SAX parser generator would be used
> to process the response's outputstream)
>  - Ideally no additional dependencies
>  - The pipeline impl should be small, and focused
>  - Very little to no additional configuration for the user.  A set of
> transformers and serializers would be defined somewhere, and stacks,
> or statically defined pipelines.  No selectors, matchers, or other
> sitemap capabilies would be needed.
>
> We could write our own, but part of the vision of Struts Action 2 is
> to bring some level of unification to the Java web development space,
> and I'd like to include Cocoon in the discussion.  I have a Cocoon
> pipeline extract project, Simple XML Pipelines[1], we could use, but
> I'd rather use an "official" Cocoon artifact to strengthen the ties of
> the two projects and leverage the years of experience and knowledge of
> the Cocoon community.  My pipelines project could be donated, if
> necessary, to seed the work.
>
> This new Struts Action 2 feature hasn't been discussed, much less
> accepted by the project, still in its infancy, but I wanted to first
> float the idea to see if the Cocoon community would be interested in
> developing such a "mini-Cocoon".  I've found several uses of my
> stripped down Pipeline project in areas like multi-versioned SOAP
> services support and portal URL-rewriting, so I think it would be of
> interest outside Struts.
>
> Look forward to the feedback,

Splitting Cocoon in smaller pieces is something that absolutely must be
done IMO if we want Cocoon to evolve. This has been discussed many times
on this list and your deconstruction of Cocoon for use in Struts
(flowscript and now pipelines) shows well that Cocoon will be copied
rather than used if it stays the monolithic piece of code it is today.

Sylvain

-- 
Sylvain Wallez - http://bluxte.net

Re: Maven2 plugin for eclipse with cocoon 2.2

2006-04-16 Thread Antonio Gallardo


Jorg Heymans escribió:

Antonio Gallardo wrote:

  

Still there are some problems with this plugin, but allows to see 1
project, wich I found very useful.




I didn't try this, but what do you mean by 1 project ? Mounting
everything like is done in 2.1.x ?
  

Yep.

Best Regards,

Antonio Gallardo.

Re: Maven2 plugin for eclipse with cocoon 2.2

2006-04-16 Thread Jorg Heymans


Antonio Gallardo wrote:

> 
> Still there are some problems with this plugin, but allows to see 1
> project, wich I found very useful.
> 

I didn't try this, but what do you mean by 1 project ? Mounting
everything like is done in 2.1.x ?


Jorg

continuum mailinglist notifications

2006-04-16 Thread Jorg Heymans

Dear all,

I have configured continuum to start sending mailinglist notifiers. I
hope it doesn't start flooding the list, if it does please bear with me
while i get things sorted out over the next few hours.


Regards
Jorg

ForrestBot build for cocoon-docs FAILED

2006-04-16 Thread Forrestbot

Automated build for cocoon-docs FAILED
Log attached.

--
Forrestbot run ended at 16 April 12:02 PM
Using Forrest 0.8-dev
Forrestbot administrator: ForrestBot
--

 [echo] 
  ... Forrest render START 2006-04-16 12:02:23
  ... Rendering docs in 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs


check-java-version:
 [echo] This is apache-forrest-0.8-dev
 [echo] Using Java 1.4 from /usr/j2se/jre

init-props:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

echo-settings:

check-skin:

init-proxy:

fetch-skins-descriptors:

fetch-skin:

unpack-skins:

init-skins:

init-plugins:
[mkdir] Created dir: 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/webapp/conf
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [copy] Copying 1 file to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] 
  --
  Installing plugin: org.apache.forrest.plugin.output.pdf
  --
   

check-plugin:
 [echo] org.apache.forrest.plugin.output.pdf is available in the build dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:

fetch-plugin:

unpack-plugin:

install-plugin:

configure-plugin:

configure-output-plugin:
 [echo] Mounting output plugin: org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/output.xmap.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp

configure-plugin-locationmap:
 [echo] Mounting plugin locationmap for org.apache.forrest.plugin.output.pdf
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml 
to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/locationmap.xml.new
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginLmMountSnippet.xsl
 [move] Moving 1 files to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp
 [echo] 
  --
  Installing plugin: org.apache.forrest.plugin.input.projectInfo
  --
   

check-plugin:
 [echo] org.apache.forrest.plugin.input.projectInfo is not available in the 
build dir

init-props:

echo-settings:

init-proxy:

fetch-plugins-descriptors:
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/plugins.xml
  [get] .
  [get] last modified = Fri Feb 24 09:07:16 GMT+00:00 2006
 [echo] Fetching plugins descriptor: 
http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] Getting: http://forrest.apache.org/plugins/whiteboard-plugins.xml
  [get] ..
  [get] last modified = Thu Apr 06 07:54:56 GMT+00:00 2006
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/plugins.xml.
 [echo] Plugin list loaded from 
http://forrest.apache.org/plugins/whiteboard-plugins.xml.

fetch-plugin:
 [xslt] Processing 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/plugins-1.xml to 
/export/home/config/forrestbot-trunk/conf/work/cocoon-docs/tmp/pluginlist2fetchbuild.xml
 [xslt] Loading stylesheet 
/export/opt/forrest-trunk/main/var/pluginlist2fetch.xsl

fetch-local-unversioned-plugin:

get-local:
 [echo] Trying to locally get org.apache.forrest.plugin.input.projectInfo
 [echo] Looking in local /export/opt/forrest-trunk/plugins

init:
 [echo] 
  --

  Using Apache Ant version 1.6.2 compiled on July 16 2004
  Build file 
/export/opt/forrest-trunk/plugins/org.apache.forrest.plugin.input.projectInfo/build.xml
  Use 'build.[sh|bat] -projecthelp' to see other options.
  Build system home /export/opt/forrest-trunk/tools/ant
  Build number 70
  Project Name Forrest plugin build file
  Java Version 1.4  
  Timestamp 200604161202
  
  --


clean:

compile:

jar:

local-deploy:
 [echo] Locally deploying org.apache.forrest.plugin.input.projectInfo
 [copy] Copying 32 files to 
/export/opt/forrest-trunk/build/plugins/org.apache.for

Re: [RT] Mini-Cocoon

2006-04-16 Thread Daniel Fagerstrom


Max Pfingsthorn skrev:

Hi!

I really like the idea to make cleancut interfaces between core components and 
factoring them out.
What I would really look forward to would be an abstraction of the processor 
level.


There is already a well known API for that: the servlet. We have had a 
number of discussions about using Servlet instead of Processor. The 
blocks architecture is based on servlets as processing level abstraction.



That would allow
> us to do cool rails-like things by implementing an MVC processor :). 
Berin hat this idea a
> while ago [1]. Having a processor implementation would allow us to 
simply  an mcv
> component into publishy sitemap uri spaces, for example for the 
ever-recurring polls and so on,
> while not polluting the sitemap language. Flowscript might be ok for 
smaller controlling needs, but
> I think a dedicated java implementation would go a long way. Think of 
debugging for one thing.

> Integrating Javaflow would be nice though for the stateful controllers.

You are going to like the blocks architecture, the block protocol 
already do what you are asking for see 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=114237414521595&w=2 for 
the current state and for more about the block protocol.


/Daniel

Re: [FYI] GSoC 2006 announced!

2006-04-16 Thread Daniel Fagerstrom

Upayavira skrev:

Bertrand Delacretaz wrote:

Most of you have probably seen it already, Google has officially
announced Summer Of Code 2006: http://code.google.com/soc/

I'll probably suggest a project to expand the scope of automated testing
of our 2.1.x "workhorse branch".

That would be great, but what we _really_ need is help getting 2.2 (with
or without OSGi) out. Are there chunks of work that are both interesting
and challenging, but not too challenging, that could be made into Gsoc
projects? That's what we really need to help move our project on.

Maybe the creation of a sitemap servlet,
Too late ;)
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/sitemap/SitemapServlet.java

or a javascript servlet?

Yes

Or a proposal for a pull pipeline servlet?
Not certain that pull pipelines should be introduced at the
servlet(=controller) level, rather an API that is used within a
controller. I'd like to see a number of example implementations on using
Axiom http://ws.apache.org/commons/axiom/index.html for server side AJAX
handling. And also for more conventional publishing. We would also
need a pull pipeline based template implementation.

Or some other block deployer code
We'd like to get something running in this area before rather than after
the summer.

or something?

JMX for management of OSGi based Cocoon?

There are of course many things that needs to be done in the blocks
architecture. But much of it require detailed knowledge about internals
of current Cocoon core wich makes it to complicated as a GSOC project.

Thoughts?

An attribute template language for Cocoon would still be nice.

/Daniel

RE: [RT] Mini-Cocoon

2006-04-16 Thread Max Pfingsthorn

Hi!

I really like the idea to make cleancut interfaces between core components and 
factoring them out.

What I would really look forward to would be an abstraction of the processor 
level. That would allow us to do cool rails-like things by implementing an MVC 
processor :). Berin hat this idea a while ago [1]. Having a processor 
implementation would allow us to simply  an mcv component into 
publishy sitemap uri spaces, for example for the ever-recurring polls and so 
on, while not polluting the sitemap language. Flowscript might be ok for 
smaller controlling needs, but I think a dedicated java implementation would go 
a long way. Think of debugging for one thing. Integrating Javaflow would be 
nice though for the stateful controllers.

Bye!
max

[1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112869422207312&w=2

> -Original Message-
> From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED]
> Sent: Saturday, April 15, 2006 14:01
> To: dev@cocoon.apache.org
> Subject: Re: [RT] Mini-Cocoon
> 
> 
> Bertrand Delacretaz skrev:
> > Hi Don,
> > 
> > Le 14 avr. 06 à 21:13, Don Brown a écrit :
> > 
> >> ... - We only need transformers and serializers, the 
> framework would 
> >> handle the generation (implicitly a SAX parser generator 
> would be used 
> >> to process the response's outputstream)
> >>  - Ideally no additional dependencies
> >>  - The pipeline impl should be small, and focused
> >>  - Very little to no additional configuration for the 
> user.  A set of 
> >> transformers and serializers would be defined somewhere, 
> and stacks, 
> >> or statically defined pipelines.  No selectors, matchers, or other 
> >> sitemap capabilies would be needed. ..
> > 
> > What you suggest echoes our discussions from a last 
> December [1], and I 
> > think there's definite interest in our community to see 
> Cocoon delivered 
> > in smaller independent packages. At least at the "talking about it" 
> > level...but let's hope your message prompts some people to stand up.
> > 
> > Maybe some of the people working on 2.2 can comment about this? How 
> > could the new structure of 2.2 help using our sitemap 
> components outside 
> > of Cocoon?
> > 
> > Personally I'd love to help, but to be realistic I won't be able to 
> > commit serious time to such a project in the next few weeks. Except 
> > maybe mentoring or co-mentoring a Summer Of Code project to 
> experiment 
> > with refactoring some of our sitemap components to be usable in a 
> > lighter environment.
> > 
> > -Bertrand
> > 
> > [1] 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113380354129554&w=2

Splitting Cocoon core is on my todo-list, I wrote something about it a 
while ago: 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=113682736011081&w=2.

An important question is of course what blocks to split core into and 
what the contracts should be for these blocks.

/Daniel

Re: [FYI] GSoC 2006 announced!

2006-04-16 Thread Upayavira

Upayavira wrote:
> Bertrand Delacretaz wrote:
>> Most of you have probably seen it already, Google has officially
>> announced Summer Of Code 2006: http://code.google.com/soc/
>>
>> I'll probably suggest a project to expand the scope of automated testing
>> of our 2.1.x "workhorse branch".
> 
> That would be great, but what we _really_ need is help getting 2.2 (with
> or without OSGi) out. Are there chunks of work that are both interesting
> and challenging, but not too challenging, that could be made into Gsoc
> projects? That's what we really need to help move our project on.
> 
> Maybe the creation of a sitemap servlet, or a javascript servlet? Or a
> proposal for a pull pipeline servlet? Or some other block deployer code
> or something?
> 
> Thoughts?

e.g. reimplementing the CLI based on the new technology. I'd happily
mentor that project (something I'd like to do myself but won't have time).

Upayavira

45 matches

Mail list logo