Re: Building changes into the top level sitemap
Hi, Jeremy Quinn wrote: Hi Carsten For static files that are just using a reader, this may be a good solution. In the case of these system pipelines however, there is a sitemap/ flowscript etc. that has to be executed. Ah, ok - so this has to go through the sitemap of course. As for static files, they are currently being served for 2 blocks, Forms which has CForms Dojo Widgets, CSS and Images; Ajax which has more Widgets etc. plus it contains Dojo libs. Yepp - it would be great to serve these files directly from a resource servlet. Due to a recent development at AOL, it could be possible to do without distributing Dojo from Cocoon : http://ajaxian.com/archives/including-dojo-via-the-aol-cdn Alex Russell has: constructed a couple of very small “wrapper” files that will let you include the “Ajax” build of Dojo from various versions through the cross-domain loader. Including the latest stable Dojo couldn’t be simpler: script src=http://download.dojotoolkit.org/dojo_0.3.1.js;/script It’s also trivial to test out the latest 0.4.1 Release Candidate: script src=http://download.dojotoolkit.org/dojo_0.4.1rc2.js;/script That would be cool and reduce downloads for users as well. I have not tested this yet. My hopes are that CForms etc. will be compatible with Dojo 0.4.n very shortly :) Great!! :) Carsten -- Carsten Ziegeler - Chief Architect http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Building changes into the top level sitemap
I'm wondering if it would be better to use a resource servlet for
serving resources instead of going through the sitemap?
With 2.2 we can mount servlets at mount paths through the dispatcher
servlet. So perhaps this is a way to go? (Just a rough idea)
Carsten
Jeremy Quinn wrote:
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
regards Jeremy
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Building changes into the top level sitemap
Hi Carsten
For static files that are just using a reader, this may be a good
solution.
In the case of these system pipelines however, there is a sitemap/
flowscript etc. that has to be executed.
As for static files, they are currently being served for 2 blocks,
Forms which has CForms Dojo Widgets, CSS and Images; Ajax which has
more Widgets etc. plus it contains Dojo libs.
Due to a recent development at AOL, it could be possible to do
without distributing Dojo from Cocoon :
http://ajaxian.com/archives/including-dojo-via-the-aol-cdn
Alex Russell has:
constructed a couple of very small “wrapper” files that will let you
include the “Ajax” build of Dojo from various versions through the
cross-domain loader.
Including the latest stable Dojo couldn’t be simpler:
script src=http://download.dojotoolkit.org/dojo_0.3.1.js;/script
It’s also trivial to test out the latest 0.4.1 Release Candidate:
script src=http://download.dojotoolkit.org/dojo_0.4.1rc2.js;/script
I have not tested this yet.
My hopes are that CForms etc. will be compatible with Dojo 0.4.n very
shortly :)
regards Jeremy
On 6 Dec 2006, at 08:04, Carsten Ziegeler wrote:
I'm wondering if it would be better to use a resource servlet for
serving resources instead of going through the sitemap?
With 2.2 we can mount servlets at mount paths through the dispatcher
servlet. So perhaps this is a way to go? (Just a rough idea)
Carsten
Jeremy Quinn wrote:
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
regards Jeremy
--
Carsten Ziegeler - Chief Architect
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
Thanks to everyone who has contributed to this thread and made encouraging noises about documentation :) Meanwhile . On 5 Dec 2006, at 17:38, Jeremy Quinn wrote: When I went to http://localhost:/_cocoon/system/ajax/upload/ status I get this error : java.io.FileNotFoundException: Could not open ServletContext resource [/resource://org/apache/cocoon/ajax/system/sitemap.xmap] Why should it say /resource:// ? (the leading slash is not in the sitemap.) Does anyone know what is going on with this error ? Thanks regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Building changes into the top level sitemap
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. Read the Maven Manuals as you've read the Ant one years ago :-) Ciao - -- Otego AG Tel: +41 (0)1 240 00 55 Giacomo Pati, CTO Mobile:+41 (0)79 262 21 04 Apache Software Foundation Member Mailto:[EMAIL PROTECTED] Hohlstrasse 216 Mailto:[EMAIL PROTECTED] CH-8004 Zuerich http://www.otego.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFFdXc/LNdJvZjjVZARAmJlAJoCunJ9CFm17/S+04n7/Bc3f0GVIwCeIUh6 DsTMtr3sN+t4/cJf6MFaOps= =Y0ix -END PGP SIGNATURE-
Re: Building changes into the top level sitemap
Jeremy Quinn wrote:
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like (and
adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap
uri-prefix=_cocoon/system//
/map:when
map:otherwise
map:mount
src=resource://org/apache/cocoon/{1}/system/sitemap.xmap
uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to the
samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know where
to start solving this.
What am I supposed to do ?
Thanks for any suggestions
One of our problems is that we use the styling resources from cocoon-webapp. We
have to move all styling related things into cocoon-samples-style-default and
use it from all our sample blocks instead of using the infamous context protocol.
For system resources we should provide a system-resources block. For now it
could be mounted at _cocoon, later we should install a
LinkRewritingTransformer that is aware of blocks.
One problem with these changes is, that they are incomptable with 2.1. As we are
sharing them across both versions. For this reason I propose to create a
cocoon-forms-samples-22 block that makes use of blocks and we have the
opportunity to tidy up a bit.
--
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: Building changes into the top level sitemap
Jeremy Quinn skrev:
Hi Guys
I am trying to get support for the new Upload Progress Bar working in
Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap
uri-prefix=_cocoon/system//
/map:when
map:otherwise
map:mount
src=resource://org/apache/cocoon/{1}/system/sitemap.xmap
uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Yes, that should be the place.
Next I am trying to get this compiled in, so that it is available for
the 'cocoon-dist-samples' and everything else that may be built from
this distribution.
I have tried to compile this in, but it never becomes available to the
samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know where
to start solving this.
What am I supposed to do ?
First, the dist samples (cocoon-dist-samples, cocoon-dist-publishing)
are really just distribution samples. They just unpack and package
together the cocoon-webapp and samples and implementations from the
various blocks. For development of samples it would be really
inconvenient to work from the dist samples as you would need to rebuild
about the whole trunk after each change.
So what I would recommend to do is to start from the cocoon-webapp
instead and to add (locally) all the block samples you need for your
work, as dependencies to cocoon-webapp. What happens then is that during
startup Cocoon will find all the COB-INF directories from the block
samples from the class path. From here two different things can happen:
if the block is in a jar at the class path, the COB-INF directory of the
block will be unpacked in a blocks/blockname directory in the temp
directory of the servlet container. If the block is in a class directory
(if you devolop in Eclipse e.g. and your cocoon-webapp depends on
another block project), Cocoon will read directly from the block without
any unpacking.
All this is done by using a new blockcontext protocol that is aware of
the locations of the blocks (see
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=116326232408386w=2).
So the above should hopefully make it easier to work on making the new
stuff functional. After that you can try to compile the dist samples and
see if it works in them as well.
The above described functionality actually make it easier and faster
than ever to develop samples, as you can test them without any copying
or jetty restarts at all in Eclipse. But some documentation about this
would probably not hurt ;)
/Daniel
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. OK, Thanks, I am trying that now . Getting NPEs from org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) now while trying to run $ mvn install or $ mvn package in dists/cocoon-dist-samples/ Trying a complete clean install from scratch. (Why does this happen in such an unpredictable way ?) core/cocoon-webapp/ dists/cocoon-dist-samples/ Neither results in the changes happening to the file at : dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap TBH I find this new build system so deeply opaque, I do not know where to start solving this. Read the Maven Manuals as you've read the Ant one years ago :-) Excuse the mild sarcasm, but I never actually had to read the Ant manual to develop for Cocoon 2.1 :-) Thanks for your reply regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:49, Reinhard Poetz wrote:
Jeremy Quinn wrote:
Hi Guys
I am trying to get support for the new Upload Progress Bar working
in Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Next I am trying to get this compiled in, so that it is available
for the 'cocoon-dist-samples' and everything else that may be
built from this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
Thanks for any suggestions
One of our problems is that we use the styling resources from
cocoon-webapp. We have to move all styling related things into
cocoon-samples-style-default and use it from all our sample blocks
instead of using the infamous context protocol.
For system resources we should provide a system-resources block.
For now it could be mounted at _cocoon, later we should install a
LinkRewritingTransformer that is aware of blocks.
The idea was that any block could provide a system pipeline. In this
case, the system pipeline is provided by the Ajax Block.
One problem with these changes is, that they are incomptable with
2.1. As we are sharing them across both versions. For this reason I
propose to create a cocoon-forms-samples-22 block that makes use of
blocks and we have the opportunity to tidy up a bit.
AFAICS this is the one and only change required to support Upload
Progress that is not shared by Trunk and Branch.
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
Jeremy Quinn wrote:
On 5 Dec 2006, at 13:49, Reinhard Poetz wrote:
For system resources we should provide a system-resources block. For
now it could be mounted at _cocoon, later we should install a
LinkRewritingTransformer that is aware of blocks.
The idea was that any block could provide a system pipeline. In this
case, the system pipeline is provided by the Ajax Block.
This shouldn't be a problem because from the Java level POV there is no
concept of blocks.
--
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: Building changes into the top level sitemap
On 5 Dec 2006, at 14:04, Daniel Fagerstrom wrote:
Jeremy Quinn skrev:
Hi Guys
I am trying to get support for the new Upload Progress Bar working
in Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Yes, that should be the place.
Good :)
Next I am trying to get this compiled in, so that it is available
for the 'cocoon-dist-samples' and everything else that may be
built from this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
First, the dist samples (cocoon-dist-samples, cocoon-dist-
publishing) are really just distribution samples. They just unpack
and package together the cocoon-webapp and samples and
implementations from the various blocks. For development of samples
it would be really inconvenient to work from the dist samples as
you would need to rebuild about the whole trunk after each change.
OK
So what I would recommend to do is to start from the cocoon-webapp
instead and to add (locally) all the block samples you need for
your work, as dependencies to cocoon-webapp. What happens then is
that during startup Cocoon will find all the COB-INF directories
from the block samples from the class path. From here two different
things can happen: if the block is in a jar at the class path, the
COB-INF directory of the block will be unpacked in a blocks/
blockname directory in the temp directory of the servlet
container. If the block is in a class directory (if you devolop in
Eclipse e.g. and your cocoon-webapp depends on another block
project), Cocoon will read directly from the block without any
unpacking.
All this is done by using a new blockcontext protocol that is aware
of the locations of the blocks (see http://marc.theaimsgroup.com/?
l=xml-cocoon-devm=116326232408386w=2).
So the above should hopefully make it easier to work on making the
new stuff functional. After that you can try to compile the dist
samples and see if it works in them as well.
The above described functionality actually make it easier and
faster than ever to develop samples, as you can test them without
any copying or jetty restarts at all in Eclipse. But some
documentation about this would probably not hurt ;)
Documentation would really help.
I have just been working on an established project that is built from
2.2 and I could see the advantages of the new platform.
However, many perceive 2.2 as almost unusable. It clearly is being
used but the procedures are very different from 2.1 . the results
can be completely unpredictable . it will compile one minute and
not the next, this is very off-putting. If the less experienced
developers like myself cannot feel confidant with the build system
for 2.2 what hope do we have of users embracing it?
Sorry this is in no way intended as a personal criticism, merely a
statement of facts as I perceive them.
From my PoV, the areas most urgently in need of documentation are :
A cookbook for how to develop 2.2 (as you describe)
Recipes for starting your own project.
Troubleshooting hint for solving common build problems.
Reading the Maven2 manual as Giacomo suggested, may well help :) but
that still leaves understanding how 2.2 performs it's built using Maven.
Thanks for your reply :)
regards Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 16:25, Reinhard Poetz wrote: Jeremy Quinn wrote: On 5 Dec 2006, at 13:49, Reinhard Poetz wrote: For system resources we should provide a system-resources block. For now it could be mounted at _cocoon, later we should install a LinkRewritingTransformer that is aware of blocks. The idea was that any block could provide a system pipeline. In this case, the system pipeline is provided by the Ajax Block. This shouldn't be a problem because from the Java level POV there is no concept of blocks. Good, that is what I thought. Thanks. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. Ever since I ran $ mvn install in core/cocoon-webapp/, I cannot get $ mvn package to work in dists/cocoon-dist-samples/. No matter how many times I run it (I also went back and did a complete clean install from root) I get this from the build : [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.apache.maven.plugin.war.AbstractWarMojo.unpack (AbstractWarMojo.java:704) at org.apache.maven.plugin.war.AbstractWarMojo.unpackWarToTempDirectory (AbstractWarMojo.java:680) at org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp (AbstractWarMojo.java:600) at org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp (AbstractWarMojo.java:379) at org.apache.cocoon.maven.deployer.AbstractDeployMojo.deployMonolithicCoco onAppAsWebapp(AbstractDeployMojo.java:182) at org.apache.cocoon.maven.deployer.DeployExplodedMojo.execute (DeployExplodedMojo.java:64) at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:412) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:534) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:475) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:454) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:273) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 322) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) And of course I don't have a clue where to start looking . regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
OK, so even though I could not get $ mvn package to run inside the dists/cocoon-dist-samples, I found that the changes to the top-level sitemap from core/cocoon-webapp/ had in fact been added to the sitemap at : dists/cocoon-dist-samples/target/cocoon-samples/ sitemap.xmap I was able to start Jetty in : dists/cocoon-dist-samples When I went to http://localhost:/_cocoon/system/ajax/upload/ status I get this error : java.io.FileNotFoundException: Could not open ServletContext resource [/resource://org/apache/cocoon/ajax/system/sitemap.xmap] Why should it say /resource:// ? (the leading slash is not in the sitemap.) Doing a $ jar -tf dists/cocoon-dist-samples/target/cocoon-samples/WEB- INF/lib/cocoon-ajax-impl-1.0.0-M2-SNAPSHOT.jar I see all of the new stuff that is needed : . . . org/apache/cocoon/ajax/system/i18n/messages.xml org/apache/cocoon/ajax/system/sitemap.xmap org/apache/cocoon/ajax/system/System.JSON.js org/apache/cocoon/ajax/system/System.Upload.js . . . Am I looking in the right place? Thanks regards Jeremy On 5 Dec 2006, at 17:08, Jeremy Quinn wrote: On 5 Dec 2006, at 13:42, Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Quinn wrote: I have tried to compile this in, but it never becomes available to the samples. I tried running $ mvn package in both : You probably have to use 'mvn install' as 'mvn package' only build the jar in you target folder of the block whareas you'll need it to be installed into your local repository so other parts of the build system can take them from there. Ever since I ran $ mvn install in core/cocoon-webapp/, I cannot get $ mvn package to work in dists/cocoon-dist-samples/. No matter how many times I run it (I also went back and did a complete clean install from root) I get this from the build : smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On 5 Dec 2006, at 17:38, Jeremy Quinn wrote: Am I looking in the right place? OK, so as Jetty starts up, it reports that it loads ~/.m2/repository/ org/apache/cocoon/cocoon-ajax-impl/1.0.0-M2-SNAPSHOT/cocoon-ajax- impl-1.0.0-M2-SNAPSHOT.jar. I can confirm that the system resources I seek exist there too. regards Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: Building changes into the top level sitemap
On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it is nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? My point would be, don't assume that nearly unusable implies a great gap to be crossed to reach fully usable. My impression is that trunk isn't pervasively unstable, it's just unstable at a few key points, and those are being ironed out by the people who also know how to work around, etc. and also how to just plain use the frigging thing without any documention. So trunk right now is like riding a wild bear, and there's only a few people who know how to ride the bear. Two things to do: (1) tame the bear, and (2) teach ordinary people how to ride a tame bear! This is my observation as a relative outsider, i.e. non-wild-bear-rider. My impression is that (1) is very close. I'm trying to learn now (even though the bear is still a little bit wild), so that I can help with (2). —ml—
Re: Building changes into the top level sitemap
Jeremy Quinn wrote: Documentation would really help. Absolutely! I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. However, many perceive 2.2 as almost unusable. It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? IIUC, the users should not build cocoon 2.2, they will just use maven to fetch an archetype, write their sitemaps and stuff there, configure their dependencies, and then use again maven to build it. Maven will fetch cocoon core, all the needed blocks, and produce a war or launch jetty with it. Sorry this is in no way intended as a personal criticism, merely a statement of facts as I perceive them. Same here, nothing wrong at all with the incredible work that has been made on 2.2. The real problem at the moment, in my opinion, are not the users, but the *developers*. I've been using 2.2 in last 4 months, experimenting with it a lot, but still don't know how many things work, things changes continuously, and we (even committers) don't know what still has to be done and how. It's not a matter of code by itself, or maven, or osgi. From my PoV, the areas most urgently in need of documentation are : A cookbook for how to develop 2.2 (as you describe) Recipes for starting your own project. Troubleshooting hint for solving common build problems. Again, absolutely, and I'd like to add also : A clear and detailed roadmap to 2.2 Currently about 3 to 5 people are *really working* on 2.2. Many other people (me for example) would like to contribute more, but we don't know exactly what has to be done. It would be a good idea, IMO, to stop developing for a few days, share knowledge with others (documentation and roadmap), assign roles to people (by block?), so that the 3/4 days lost by a small group in producing documenta can be recovered by a joint effort of more people. WDYT? Simone
Re: Building changes into the top level sitemap
Jeremy Quinn wrote:
On 5 Dec 2006, at 14:04, Daniel Fagerstrom wrote:
Jeremy Quinn skrev:
Hi Guys
I am trying to get support for the new Upload Progress Bar working
in Cocoon 2.2.
I need to add a new system pipeline to the top-level sitemap, like
(and adjacent to) the one that handles :
map:match pattern=_cocoon/resources/*/**
this is the snippet :
map:match pattern=_cocoon/system/*/**
map:select type=resource-exists
map:when test=system/{1}/sitemap.xmap
map:mount src=system/{1}/sitemap.xmap uri-
prefix=_cocoon/system//
/map:when
map:otherwise
map:mount src=resource://org/apache/cocoon/{1}/system/
sitemap.xmap uri-prefix=_cocoon/system/{1}//
/map:otherwise
/map:select
/map:match
The purpose is to mount Block-Level system pipelines.
I /think/ the place I make this change is in :
/core/cocoon-webapp/src/main/webapp/sitemap.xmap
(But TBH I am not sure)
Yes, that should be the place.
Good :)
Next I am trying to get this compiled in, so that it is available
for the 'cocoon-dist-samples' and everything else that may be built
from this distribution.
I have tried to compile this in, but it never becomes available to
the samples.
I tried running $ mvn package in both :
core/cocoon-webapp/
dists/cocoon-dist-samples/
Neither results in the changes happening to the file at :
dists/cocoon-dist-samples/target/cocoon-samples/sitemap.xmap
TBH I find this new build system so deeply opaque, I do not know
where to start solving this.
What am I supposed to do ?
First, the dist samples (cocoon-dist-samples, cocoon-dist- publishing)
are really just distribution samples. They just unpack and package
together the cocoon-webapp and samples and implementations from the
various blocks. For development of samples it would be really
inconvenient to work from the dist samples as you would need to
rebuild about the whole trunk after each change.
OK
So what I would recommend to do is to start from the cocoon-webapp
instead and to add (locally) all the block samples you need for your
work, as dependencies to cocoon-webapp. What happens then is that
during startup Cocoon will find all the COB-INF directories from the
block samples from the class path. From here two different things can
happen: if the block is in a jar at the class path, the COB-INF
directory of the block will be unpacked in a blocks/ blockname
directory in the temp directory of the servlet container. If the
block is in a class directory (if you devolop in Eclipse e.g. and
your cocoon-webapp depends on another block project), Cocoon will
read directly from the block without any unpacking.
All this is done by using a new blockcontext protocol that is aware
of the locations of the blocks (see http://marc.theaimsgroup.com/?
l=xml-cocoon-devm=116326232408386w=2).
So the above should hopefully make it easier to work on making the
new stuff functional. After that you can try to compile the dist
samples and see if it works in them as well.
The above described functionality actually make it easier and faster
than ever to develop samples, as you can test them without any
copying or jetty restarts at all in Eclipse. But some documentation
about this would probably not hurt ;)
Documentation would really help.
I have just been working on an established project that is built from
2.2 and I could see the advantages of the new platform.
However, many perceive 2.2 as almost unusable. It clearly is being used
but the procedures are very different from 2.1 . the results can be
completely unpredictable . it will compile one minute and not the
next, this is very off-putting. If the less experienced developers like
myself cannot feel confidant with the build system for 2.2 what hope do
we have of users embracing it?
Sorry this is in no way intended as a personal criticism, merely a
statement of facts as I perceive them.
From my PoV, the areas most urgently in need of documentation are :
A cookbook for how to develop 2.2 (as you describe)
Recipes for starting your own project.
I am trying to learn and compile information in that direction (Recipes).
e.g. in How to run block built with cocoon-22-archetype-block thread
Reinhard suggested me a Getting started in 5 minutes document that
explains how to connect to another block and how to use inheritance
would be welcome.
I am not there yet but I am very willing to archieve that in the near
future.
So please bear with my user stupid questions to come :)
Looking forward to test the AJAX upload widget !
Patrick
Troubleshooting hint for solving common build problems.
Reading the Maven2 manual as Giacomo suggested, may well help :) but
that still leaves understanding how 2.2 performs it's built using Maven.
Thanks for your reply :)
regards Jeremy
HTML mails (was Re: Building changes into the top level sitemap)
Mark Lundquist wrote: On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it /is/ nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) snip/ Mark, from time to time you send mails in HTML. Can you please make sure you send mails in plain text to the list? It will ease the reader's job, as HTML indentation doesn't make it easy to distinguish quoted messages (and also increases the mail's size). Thanks, Sylvain -- Sylvain Wallez - http://bluxte.net
Re: Building changes into the top level sitemap
Simone Gianni skrev: Jeremy Quinn wrote: Documentation would really help. Absolutely! I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. However, many perceive 2.2 as almost unusable. It clearly is being used but the procedures are very different from 2.1 . the results can be completely unpredictable . it will compile one minute and not the next, this is very off-putting. If the less experienced developers like myself cannot feel confidant with the build system for 2.2 what hope do we have of users embracing it? IIUC, the users should not build cocoon 2.2, they will just use maven to fetch an archetype, write their sitemaps and stuff there, configure their dependencies, and then use again maven to build it. Maven will fetch cocoon core, all the needed blocks, and produce a war or launch jetty with it. That is normally correct. Right now a user need to compile as there are so many improvements that simplifies usage since the last milestone. But we will hopefully get a new milestone release in the near future. This will make it as easy as you described above to use Cocoon. Another thing that would simplify it for developers to start work with Cocoon 2.2 would be if we went back to have a cocoon-webapp that actually does something. Now we instead have the dist samples that put everything together in a war file. But they are somewhat unstable and as I described in a previous mail, completely unusable for sample development. The cocoon-webapp doesn't contain any samples anymore, so a develper doesn't have any good examples on what a Cocoon development environment looks like anymore. I would propose that we either add some samples to the cocoon-webapp again or that we create some cocoon-sample-webapp to Cocoon that contains some samples. Sorry this is in no way intended as a personal criticism, merely a statement of facts as I perceive them. Same here, nothing wrong at all with the incredible work that has been made on 2.2. The real problem at the moment, in my opinion, are not the users, but the *developers*. I've been using 2.2 in last 4 months, experimenting with it a lot, but still don't know how many things work, things changes continuously, and we (even committers) don't know what still has to be done and how. To my knowledge nothing _has_ to be done on the code. It is perfectly usable as is (although there are of course room for plenty of improvements). What needs to be done is documenting how to use it. And that more people start to use it so that we can find bugs, stabilize it and smoothen ease of usage. It's not a matter of code by itself, or maven, or osgi. OSGi is not used at all, currently. From my PoV, the areas most urgently in need of documentation are : A cookbook for how to develop 2.2 (as you describe) Recipes for starting your own project. Troubleshooting hint for solving common build problems. Agree. Again, absolutely, and I'd like to add also : A clear and detailed roadmap to 2.2 When I have asked earlier no one had any outstanding items that we absolutely must solve. What is lacking is documentation. So what we need is a roadmap for documentation. In some sense we have that also: one can browse http://cocoon.zones.apache.org/dev-docs/ and see what is lacking. There are lots of skeleton documents, so it is just to start filling in the empty sections ;) Much of that can be done by moving documentation from 2.1 to the new documentation and correct it if needed. It is still hard to know where to start. For me at least some kind of documentation road map or priority list would be helpful. So that I could start with what is most important. /Daniel
Re: HTML mails (was Re: Building changes into the top level sitemap)
On Dec 5, 2006, at 2:49 PM, Sylvain Wallez wrote: Mark Lundquist wrote: On Dec 5, 2006, at 8:50 AM, Jeremy Quinn wrote: I have just been working on an established project that is built from 2.2 and I could see the advantages of the new platform. Yeah, it's awesome. However, many perceive 2.2 as almost unusable. Well, it /is/ nearly unusable, but I guess that will change very soon. This is why it's not been released yet :-) snip/ Mark, from time to time you send mails in HTML. Can you please make sure you send mails in plain text to the list? It will ease the reader's job, as HTML indentation doesn't make it easy to distinguish quoted messages. Ugh, yeah I see what you mean from the snip above. It's actually not HTML email, though... it's a multipart plaintext + RTF email. I see you are using Thunderbird, so... just for fun I fired up Mozilla, brought up the Gmane usenet mirror in the newreader and looked at my message (the one you replied to), and sure enough, it was doing the indenting thing. It appears that Mozilla/T-bird just doesn't render the RTF excerpt element in a very useful way, and does not let you configure anything different. Interestingly, plaintext email w/ quoted excerpts using the standard style displays beautifully; Mozilla translates that into a nice gray bar running along the side. You can configure Mozilla to default to that just by checking View Message Body As Plain Text. Try it and then look at my message again, and you should see that it looks just right. cheers, —ml—
