You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Reinhard Pötz <re...@apache.org> on 2008/08/13 01:14:34 UTC
Cocoon 2.2 classic webapp
I've just committed a sample module for a 'Classic Cocoon 2.2 webapp'
to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used
without the Servlet-Service Framework or custom blocks. Both are great
features but they are not needed in every case, e.g. if you want a
simple migration for Cocoon 2.1 to 2.2 you might not want to introduce
blocks and servlet services from the beginning.
I wrote a blog entry[1] that provides some information how you can run
the module.
If this is useful for others too, it could be moved to the trunk and
also become the base for a new Maven archetype.
Have fun!
[1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 without tears
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
Ken Starks wrote:
> Hugh Sparks wrote:
>>> Ken Starks writes:
>>> [...]
>>> I've had a second attempt at your 'Cocoon 2.2 without tears' webapp,
>>> but it isn't working for me.
>>> Reason: Cannot find parent: org.apache.cocoon:cocoon-core-modules
>>> for project:
>>> csparks.com:cocoon22:war:1.0 for project csparks.com:cocoon22:war:1.0
>>
>> I'll try to get you going in this letter, but if this takes
>> any further correspondence, we should probably switch
>> to private email because I don't want to irritate users
>> who aren't interested in this topic.
>>
>> I just tried the download myself and it worked for me.
>> There's evidently something missing in your local .m2
>> repository. I think the problem is with the parent element
>> in the pom. It looks like the cocoon-core-modules artifact
>> is not being maintained in the central maven repository
>> or I don't know how to use it properly.
>>
>> Do you have Subversion installed? I keep a checkout of
>> the cocoon 2.2 trunk that I update and build every day.
>> I think that's why it works for me and not for you.
>>
>> A quick fix is to checkout and build the cocoon 2.2 truck.
>> Then the reference to cocoon-core-modules 6-SNAPSHOT
>> will be correctly resolved.
>>
>> Otherwise, you'll have to discard the parent element
>> from the pom and dig up a consistent set of version
>> elements for the individual dependences.
>>
>> In light of your difficulty, I'll update my website
>> so others won't have this problem, but I'm not able
>> to do this immediately.
>>
>> If you don't intend to use blocks at all, I like the cocoon classic
>> method recently published by Reinhard Pötz.
>> My write-up is for uses who want to combine open content
>> but keep the option of using blocks as well.
>>
>> -Hugh Sparks
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
> Hi Hugh,
>
> Thanks for your reply.
>
> Yes, I do have Subversion installed, and I shall try the quick fix you
> suggest.
>
> " Otherwise, you'll have to discard the parent element
> from the pom and dig up a consistent set of version
> elements for the individual dependences."
> This is beyond my present skill level with Maven, I'm afraid.
> Anyway, it
> rather begs the real question, 'How can the Central Maven Repository be
> maintained in perfect working order?'
>
> I agree that there must be something missing from my .m2 repository.
> In fact
> the reason I deliberately emptied it was as a test that the project
> really would
> be 'without tears' for a new user. I did not do it to irritate anyone,
> I assure you;
> 'testing' is your friend, remember.
>
> I should be able to build 2.2 trunk without any private email advice,
> I hope. If there
> are any further problems, particularly if they might improve the
> excellent article on your
> website, I shall be in touch.
>
> I do expect to use blocks, but nearly all of my projects continue
> their development after they have been
> deployed to Tomcat. This is neither second-best nor amateurish, it is
> the correct strategy for my needs.
>
> We now have all three options:
> a. No blocks
> b. A mixture
> c. Nothing but blocks.
>
> In my opinion, your option (b), should be part of the mainstream, not
> merely an independent effort.
> This is because it could then come with a set of unit-tests and
> functional tests against which the
> developers could tweak their bleeding-edge and stable releases before
> committing them to their
> repository. Or, in the absence of such automated tests, the developers
> would at least feel a duty
> not to break your sub-project, once it was part of mainstream Cocoon.
>
> Bye for now,
>
> Ken
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
I have downloaded quite a few things from the Cocoon Subversion
Repository, and the
compile, install, package, and clean targets all work for your project.
However, the jetty:run target does not work.
-------------------------------------------------------------------------------
(The jetty:run target does work on the block archetypes provided on the
cocoon site
in the normal 2.2 way, as does cocoon:prepare which does not work on your
webapp either.)
The actual items I downloaded (just in case i missed any vital ones)
were from
http://svn.eu.apache.org/repos/asf/
cocoon/branches/cocoon2.2
(Three builds, 'mvn install' all succesful)
cocoon/trunk
( First build. mvn -P allblocks install, one missing artifact
later build. mvn -P allblocks package install, build successful )
I included the 'package target because your webapp (mvn install) complained
of missing jars when I had the right stuff, but not in jars.
I enclose the output (OK) for mvn on your project. the first file came
from mvn install > install-report.txt, and the second (not OK) from
mvn jetty:run > jetty_run_report.txt
Bye for now,
Ken.
Re: Cocoon 2.2 without tears
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
Hugh Sparks wrote:
>> Ken Starks writes:
>> [...]
>> I've had a second attempt at your 'Cocoon 2.2 without tears' webapp,
>> but it isn't working for me.
>> Reason: Cannot find parent: org.apache.cocoon:cocoon-core-modules for
>> project:
>> csparks.com:cocoon22:war:1.0 for project csparks.com:cocoon22:war:1.0
>
> I'll try to get you going in this letter, but if this takes
> any further correspondence, we should probably switch
> to private email because I don't want to irritate users
> who aren't interested in this topic.
>
> I just tried the download myself and it worked for me.
> There's evidently something missing in your local .m2
> repository. I think the problem is with the parent element
> in the pom. It looks like the cocoon-core-modules artifact
> is not being maintained in the central maven repository
> or I don't know how to use it properly.
>
> Do you have Subversion installed? I keep a checkout of
> the cocoon 2.2 trunk that I update and build every day.
> I think that's why it works for me and not for you.
>
> A quick fix is to checkout and build the cocoon 2.2 truck.
> Then the reference to cocoon-core-modules 6-SNAPSHOT
> will be correctly resolved.
>
> Otherwise, you'll have to discard the parent element
> from the pom and dig up a consistent set of version
> elements for the individual dependences.
>
> In light of your difficulty, I'll update my website
> so others won't have this problem, but I'm not able
> to do this immediately.
>
> If you don't intend to use blocks at all, I like the cocoon classic
> method recently published by Reinhard Pötz.
> My write-up is for uses who want to combine open content
> but keep the option of using blocks as well.
>
> -Hugh Sparks
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
Hi Hugh,
Thanks for your reply.
Yes, I do have Subversion installed, and I shall try the quick fix you
suggest.
" Otherwise, you'll have to discard the parent element
from the pom and dig up a consistent set of version
elements for the individual dependences."
This is beyond my present skill level with Maven, I'm afraid. Anyway, it
rather begs the real question, 'How can the Central Maven Repository be
maintained in perfect working order?'
I agree that there must be something missing from my .m2 repository. In
fact
the reason I deliberately emptied it was as a test that the project
really would
be 'without tears' for a new user. I did not do it to irritate anyone, I
assure you;
'testing' is your friend, remember.
I should be able to build 2.2 trunk without any private email advice, I
hope. If there
are any further problems, particularly if they might improve the
excellent article on your
website, I shall be in touch.
I do expect to use blocks, but nearly all of my projects continue their
development after they have been
deployed to Tomcat. This is neither second-best nor amateurish, it is
the correct strategy for my needs.
We now have all three options:
a. No blocks
b. A mixture
c. Nothing but blocks.
In my opinion, your option (b), should be part of the mainstream, not
merely an independent effort.
This is because it could then come with a set of unit-tests and
functional tests against which the
developers could tweak their bleeding-edge and stable releases before
committing them to their
repository. Or, in the absence of such automated tests, the developers
would at least feel a duty
not to break your sub-project, once it was part of mainstream Cocoon.
Bye for now,
Ken
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 without tears
Posted by Hugh Sparks <hu...@csparks.com>.
> Ken Starks writes:
> [...]
> I've had a second attempt at your 'Cocoon 2.2 without tears' webapp,
> but it isn't working for me.
> Reason: Cannot find parent: org.apache.cocoon:cocoon-core-modules for project:
> csparks.com:cocoon22:war:1.0 for project csparks.com:cocoon22:war:1.0
I'll try to get you going in this letter, but if this takes
any further correspondence, we should probably switch
to private email because I don't want to irritate users
who aren't interested in this topic.
I just tried the download myself and it worked for me.
There's evidently something missing in your local .m2
repository. I think the problem is with the parent element
in the pom. It looks like the cocoon-core-modules artifact
is not being maintained in the central maven repository
or I don't know how to use it properly.
Do you have Subversion installed? I keep a checkout of
the cocoon 2.2 trunk that I update and build every day.
I think that's why it works for me and not for you.
A quick fix is to checkout and build the cocoon 2.2 truck.
Then the reference to cocoon-core-modules 6-SNAPSHOT
will be correctly resolved.
Otherwise, you'll have to discard the parent element
from the pom and dig up a consistent set of version
elements for the individual dependences.
In light of your difficulty, I'll update my website
so others won't have this problem, but I'm not able
to do this immediately.
If you don't intend to use blocks at all, I like the cocoon classic
method recently published by Reinhard Pötz.
My write-up is for uses who want to combine open content
but keep the option of using blocks as well.
-Hugh Sparks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Cocoon 2.2 without tears
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
mostly FAO Hugh Sparks
Hi Hugh,
I've had a second attempt at your 'Cocoon 2.2 without tears' webapp,
but it isn't working for me.
This is with a completley fresh .m2/repository as I mentioned in the thread
Cocoon 2.2 classic webapp
I have attached the output, and I wonder if you (or anyone else) could
suggest what I should do next.
Re: Cocoon 2.2 classic webapp
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
Hugh Sparks wrote:
>> Hugh Sparks wrote:
>>> Many thanks to Reinhard Pötz!
>>>
>
> I'll repeat the experiment again:
>
> First, I checked out the classic webapp from the svn and verified that
> it works perfectly.
>
> Next, I edited the pom so it looks like this:
>
> ( My maven repository is freshly charged from cocoon trunk 685741)
>
>
> <snip>
>
I decided to try a totally fresh maven repository.
So I deleted _everything_ in my .m2/repository directory
Then I went to ...\cocoon22-classic-webapp and did mvn install jetty:run
It worked perfectly.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Hugh Sparks <hu...@csparks.com>.
> Hugh Sparks wrote:
>> Many thanks to Reinhard Pötz!
>>
>> To make this work with the current trunk, a few simple changes are needed:
>> [...]
> Reinhard Pötz replies:
> If you're right, this has to be fixed before the next release of Cocoon 2.2.
I'll repeat the experiment again:
First, I checked out the classic webapp from the svn and verified that it works perfectly.
Next, I edited the pom so it looks like this:
( My maven repository is freshly charged from cocoon trunk 685741)
<parent>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core-modules</artifactId>
<version>6-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core</artifactId>
</dependency>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-template-impl</artifactId>
</dependency>
</dependencies>
... jetty 6.1.7stuff...
The result from "mvn jetty:run" was:
java.lang.RuntimeException: Failed to obtain blockContexts Map.
The most probable cause is that BlockDeploymentServletContextListener
has not been executed.
at org.apache.cocoon.spring.BlockPathPropertyPlaceholderConfigurer.processProperties
(BlockPathPropertyPlaceholderConfigurer.java:50)
at org.springframework.beans.factory.config.PropertyResourceConfigurer.postProcessBeanFactory
(PropertyResourceConfigurer.java:75)
...
This lead me to try adding the BlockDeploymentServletContextListener to web.xml.
When I did that, jetty:run produced:
org.springframework.beans.factory.BeanCreationException:
Error creating bean with name 'org.apache.cocoon.jnet.URLHandlerFactoryCollector'
defined in URL [jar:file:/....m2/repository/org/apache/cocoon/cocoon-jnet/
1.1.0-SNAPSHOT/cocoon-jnet-1.1.0-SNAPSHOT.jar!
/META-INF/cocoon/spring/cocoon-jnet-collector.xml]:
Initialization of bean failed; nested exception is java.lang
java.lang.NoClassDefFoundError: org/aspectj/lang/ProceedingJoinPoint
...
At this point, I was dazed and confused, so I tried to figure out what brings in "aspectj..."
After a little trial and error, I found that adding cocoon-servlet-service-components
to the POM makes it all work.
I liked the pom and web.xml a lot better the Reinhard wrote them, so perhaps these
things can be undone?
Thanks,
-Hugh Sparks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Hugh Sparks <hu...@csparks.com>.
> Reinhard Pötz wrote:
> I've fixed this in trunk (hopefully without introducing any other incompatibilities). Now you can use the lastest snapshot
> dependencies:
> [...]
>
> Can you test it again please?
It works perfectly and no longer depends on BlockDeploymentServletContextListener
or cocoon-servlet-service-components. I used the artifact versions you suggested.
It also works without dependency versions using a parent element with cocoon-core-modules
version 6-SNAPSHOT.
Thanks!
-Hugh Sparks
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Reinhard Pötz <re...@apache.org>.
Reinhard Pötz wrote:
> Hugh Sparks wrote:
>> Many thanks to Reinhard Pötz!
>>
>> To make this work with the current trunk, a few simple changes are
>> needed:
>>
>> pom.xml: Add a dependency for cocoon-servlet-service-components
>>
>> <parent>
>> <groupId>org.apache.cocoon</groupId>
>> <artifactId>cocoon-core-modules</artifactId>
>> <version>6-SNAPSHOT</version>
>> </parent>
>>
>> <dependency>
>> <groupId>org.apache.cocoon</groupId>
>> <artifactId>cocoon-core</artifactId>
>> </dependency>
>>
>> <dependency>
>> <groupId>org.apache.cocoon</groupId>
>> <artifactId>cocoon-template-impl</artifactId>
>> </dependency>
>>
>> <dependency>
>> <groupId>org.apache.cocoon</groupId>
>> <artifactId>cocoon-servlet-service-components</artifactId>
>> </dependency>
>>
>> web.xml: Add a listener for BlockDeploymentServletContextListener
>>
>> <listener>
>> <description>Declare a context listener that installs all
>> blocks.</description>
>>
>> <listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
>>
>> </listener>
>>
>> I don't understand why these components should be required if they
>> aren't used, but this gets the webapp going without errors.
>
> If you're right, this has to be fixed before the next release of Cocoon
> 2.2.
I've fixed this in trunk (hopefully without introducing any other
incompatibilities). Now you can use the lastest snapshot dependencies:
<dependencies>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core</artifactId>
<version>2.2.1-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-template-impl</artifactId>
<version>1.2.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.4</version>
<scope>provided</scope>
</dependency>
</dependencies>
Can you test it again please?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Reinhard Pötz <re...@apache.org>.
Hugh Sparks wrote:
> Many thanks to Reinhard Pötz!
>
> To make this work with the current trunk, a few simple changes are needed:
>
> pom.xml: Add a dependency for cocoon-servlet-service-components
>
> <parent>
> <groupId>org.apache.cocoon</groupId>
> <artifactId>cocoon-core-modules</artifactId>
> <version>6-SNAPSHOT</version>
> </parent>
>
> <dependency>
> <groupId>org.apache.cocoon</groupId>
> <artifactId>cocoon-core</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.apache.cocoon</groupId>
> <artifactId>cocoon-template-impl</artifactId>
> </dependency>
>
> <dependency>
> <groupId>org.apache.cocoon</groupId>
> <artifactId>cocoon-servlet-service-components</artifactId>
> </dependency>
>
> web.xml: Add a listener for BlockDeploymentServletContextListener
>
> <listener>
> <description>Declare a context listener that installs all
> blocks.</description>
>
> <listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
>
> </listener>
>
> I don't understand why these components should be required if they
> aren't used, but this gets the webapp going without errors.
If you're right, this has to be fixed before the next release of Cocoon 2.2.
Thanks for testing!
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Hugh Sparks <hu...@csparks.com>.
Many thanks to Reinhard Pötz!
To make this work with the current trunk, a few simple changes are needed:
pom.xml: Add a dependency for cocoon-servlet-service-components
<parent>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core-modules</artifactId>
<version>6-SNAPSHOT</version>
</parent>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-core</artifactId>
</dependency>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-template-impl</artifactId>
</dependency>
<dependency>
<groupId>org.apache.cocoon</groupId>
<artifactId>cocoon-servlet-service-components</artifactId>
</dependency>
web.xml: Add a listener for BlockDeploymentServletContextListener
<listener>
<description>Declare a context listener that installs all blocks.</description>
<listener-class>org.apache.cocoon.blockdeployment.BlockDeploymentServletContextListener</listener-class>
</listener>
I don't understand why these components should be required if they
aren't used, but this gets the webapp going without errors.
-Hugh Sparks, hugh@csparks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
Ken Starks wrote:
> Ken Starks wrote:
>> Reinhard Pötz wrote:
>>>
>>> I've just committed a sample module for a 'Classic Cocoon 2.2 webapp'
>>> to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used
>>> without the Servlet-Service Framework or custom blocks. Both are
>>> great features but they are not needed in every case, e.g. if you
>>> want a simple migration for Cocoon 2.1 to 2.2 you might not want to
>>> introduce blocks and servlet services from the beginning.
>>>
>>> I wrote a blog entry[1] that provides some information how you can
>>> run the module.
>>>
>>> If this is useful for others too, it could be moved to the trunk and
>>> also become the base for a new Maven archetype.
>>>
>>> Have fun!
>>>
>>>
>>> [1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624
>>>
>> Thanks, Reinhard, this is very welcome.
>>
>> I've been a bit busy on other projects apart from cocoon for a while,
>> but
>> trying this one out moves rapidly up the TODO: list.
>>
>> Bye for now,
>> Ken.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
>> For additional commands, e-mail: users-help@cocoon.apache.org
>>
>>
>>
> Thanks again Reinhard. I managed to get this one to work first attempt.
> <snip>
It also worked when I copied the war file over to the Tomcat webapps
directory.
url:
http://localhost/cocoon22-classic-webapp-1.0-SNAPSHOT/welcome
(This is for my Tomcat, which is serving on port 80. others should
insert their local
servlet-container's port number)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
Ken Starks wrote:
> Reinhard Pötz wrote:
>>
>> I've just committed a sample module for a 'Classic Cocoon 2.2 webapp'
>> to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used
>> without the Servlet-Service Framework or custom blocks. Both are
>> great features but they are not needed in every case, e.g. if you
>> want a simple migration for Cocoon 2.1 to 2.2 you might not want to
>> introduce blocks and servlet services from the beginning.
>>
>> I wrote a blog entry[1] that provides some information how you can
>> run the module.
>>
>> If this is useful for others too, it could be moved to the trunk and
>> also become the base for a new Maven archetype.
>>
>> Have fun!
>>
>>
>> [1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624
>>
> Thanks, Reinhard, this is very welcome.
>
> I've been a bit busy on other projects apart from cocoon for a while, but
> trying this one out moves rapidly up the TODO: list.
>
> Bye for now,
> Ken.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
Thanks again Reinhard. I managed to get this one to work first attempt.
( For the information of others:
I used mvn install jetty:run
and went to http://localhost:8888/welcome
I got the welcome page, src was:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<META http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Classic Cocoon 2.2 Webapp : Welcome</title>
</head>
<body>
<h1 xmlns:jx="http://apache.org/cocoon/templates/jx/1.0">Classic Cocoon 2.2 Webapp : Welcome</h1>
If you are seeing this page, this minimal Cocoon 2.2 based web application is running correctly.
<br>
<br>
<br>
<br>
<br>
<div id="footer">
<div style="float: right;">Wed Aug 13 19:38:14 BST 2008</div> Apache Cocoon
2.2.0
</div>
</body>
)
</html>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Ken Starks <ke...@lampsacos.demon.co.uk>.
Reinhard Pötz wrote:
>
> I've just committed a sample module for a 'Classic Cocoon 2.2 webapp'
> to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used
> without the Servlet-Service Framework or custom blocks. Both are great
> features but they are not needed in every case, e.g. if you want a
> simple migration for Cocoon 2.1 to 2.2 you might not want to introduce
> blocks and servlet services from the beginning.
>
> I wrote a blog entry[1] that provides some information how you can run
> the module.
>
> If this is useful for others too, it could be moved to the trunk and
> also become the base for a new Maven archetype.
>
> Have fun!
>
>
> [1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624
>
Thanks, Reinhard, this is very welcome.
I've been a bit busy on other projects apart from cocoon for a while, but
trying this one out moves rapidly up the TODO: list.
Bye for now,
Ken.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Cocoon 2.2 classic webapp
Posted by Alessandro Vincelli <av...@alessandro.vincelli.name>.
Nice "archetype",
I think is useful a maven archetype like this for the community.
+1 :)
In the last months, I worked hard with cocoon 2.2.
I want share with community some mini blocks like:
cocoon-2.2-hibernate
cocoon-2.2-jackrabbit
cocoon-2.2-custom-reader
...
I think in a week, I can release these simple/sample blocks.
Bye
Alessandro
Reinhard Pötz wrote:
>
> I've just committed a sample module for a 'Classic Cocoon 2.2 webapp'
> to the Cocoon whiteboard. Classic mode means that Cocoon 2.2 is used
> without the Servlet-Service Framework or custom blocks. Both are great
> features but they are not needed in every case, e.g. if you want a
> simple migration for Cocoon 2.1 to 2.2 you might not want to introduce
> blocks and servlet services from the beginning.
>
> I wrote a blog entry[1] that provides some information how you can run
> the module.
>
> If this is useful for others too, it could be moved to the trunk and
> also become the base for a new Maven archetype.
>
> Have fun!
>
>
> [1] http://www.indoqa.com/en/people/reinhard.poetz/blog/624
>