You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by bart remmerie <re...@gmail.com> on 2007/12/29 14:30:28 UTC
best wishes for 2008: 2.1 vs. 2.2
Dear all,
During the past couple of months, I've been reading about "install issues"
with cocoon 2.2 all the time.
There seem to be hardcore users, convinced that cocoon 2.2 is superior now
that it's linked with maven and spring, ...
but there also are novice and/or less expert users, who are having a lot of
problems with the new 2.2 configuration & installation.
Some years ago, the steep learning curve for cocoon was seen as one of the
major problems to overcome while creating a larger user-base.
Shifting towards the integration with maven & spring doesn't simplify
things.
Another issue was the lack of documentation... but in the past, the
installation worked when you followed the instructions & you had a load of
samples to get to know cocoon...
Now, cocoon seems to become so complicated that no-one has the time to
document it properly.
Whatever the "hardcore" users may pretend, the perception of beginning user
will define the evolution of cocoon.
Therefore my wishes for 2008:
listen to & learn from the novice users:
* simplify the installation & ease of use (in the perception of beginners)
* document your framework (in such a way that beginners consider it
documented)
a little frustrated but hoping for the best,
Bart
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Romain Slootmaekers pisze:
> ah, I just followed the guides on the web site. maybe you can just add
> references to the source code there. or tweak your maven site generation
> to include the correct code samples there.
Good idea. I will do about it as soon as I get some free time.
> The use case is actually quite simple:
> I want to be able to route all requests with a path of a certain regexp
> to a servlet, and the config of the routing in the sitemap, instead of
> being in the servlet service config or in the web.xml.
> All request routing in 1 place. otherwise it's difficult to keep track,
> especially overlaps in regexps (a request mapped in a pipeline AND in
> the servlet service config, now what happens ? might this cause the
> 'commited' Exception described below ?)
I don't think so it caused the exception.
I think you misunderstand how Servlet Service Framework works. If you configure servlet with
context-path="/foo" and have request with URL "/foo/bar/baz" SSF will match it and route the request
to your servlet but with stripped prefix out of URL so servlet sees only "/bar/baz" URL. For such
URL your fancy regexps can be applied.
There is no place for ambiguity.
> hm, yes, I found that one, but the case in which my exception happens is
> totally different. I don't have any exception in the flow, nor have I
> the 500 internal error code set earlier...
Then create another bug report. :)
The best would be if you could attach simple block that exhibits the problem.
> Well I suppose it's enough if your an experienced 2.1 user. I never used
> 2.1 so a diff doesn't mean a lot (unless i need to port 2.1 examples ;))
>
> I just would like to have a reference guide of 2.2 that contains just
> that: the reference.
Yep... I try to add as much documentation as I can but you know, it takes time and effort.
Oh, and I fixed docs publishing so small documentation of expression language module should appear
within ours.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Carsten Ziegeler <cz...@apache.org>.
Before we continue to discuss the pros and cons of maven (which I'm
really really tired of) a very important clarification:
Cocoon 2.2 does not require Maven. Period.
and
The Cocoon project uses Maven for developing Cocoon itself.
While there might be advantages in using Maven for building own
applications with Cocoon like the archetypes, it's not a requirement. I
think we took great care to allow users to use their favorite build
system. I built Cocoon 2.2 web based applications without maven by using
a simple ant script copying jars into the WEB-INF/lib folder. All you
need are the binary artifacts of Cocoon (and the required third party jars).
Now, I agree that we currently fail in providing a convenient download
for these use cases - but that's a totally different thing and has
nothing to do with maven. I hope that this will change with a final 2.2
release - which is hopefully coming in the near future...
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Romain Slootmaekers <ro...@inuron.com>.
Grzegorz Kossakowski wrote:
> Romain Slootmaekers pisze:
>
>> Ok, I can considered to be a novice user so I think my experiences are
>> relevant here:
>> (when reading back what I wrote below, I might sound a bit cynic and
>> chaotic, so be warned)
>>
>> - installation: since I know maven, that was not too difficult. but I
>> really don't like the fact that I get a +100MB repository just to tinker
>> a bit with cocoon 2.2. this is too much for someone who just wants to
>> play with it before you do real development. also, getting maven shoved
>> down my throat is not my idea of a good time (maven is really an awful
>> build tool, really, the only thing you gain is that standardization
>> saves you explicit configuration). But hey, all in all I was really
>> surprised that just by following the instructions on the site, I got it
>> working (no twiddling required).
>>
>
> Even I'm not Maven lover anymore because I think this software is just too buggy and developers are
> not eager enough to fix these annoying bugs and it is just written in a bad programming style in
> many places. Nevertheless, I really think Maven improves situation not only for developers of
> Cocoon.
Don't confuse standardisation with maven. The advantages stem from the
fact everybody has the same project layout. A builder (be it maven or
whatever) then just needs minimal input to do what it needs to do.
BTW, in a previous project, we rewrote what we needed from maven in +/-
1500 lines of python. we kept the project layout of maven 90% of the
config was IN the python code. So custumizing a project was just
subclassing in python instead of writing an xml. a major improvement.
XML is good for structure, but bad for behaviour, so you should not try
to capture behaviour in it. (Anyone who ever tried a conditional in ant
knows what I mean)
<cut some text>
> Rest examples (samples) is available in our SVN. You just need to check out source code of Cocoon,
> call mvn install from root directory and then go to core/cocoon-webapp and call mvn jetty:run to see
> many, many samples working out of the box. What minor twiddling do you refer to?
>
>
ah, I just followed the guides on the web site. maybe you can just add
references to the source code there. or tweak your maven site generation
to include the correct code samples there.
> I think that configuration in 2.2 is much, much better than in C2.1 but I agree it needs more
> attention when it comes to documentation. Especially we need to explain how to fit all puzzles.
>
> I will have something to show related to this topic very soon.
>
>
Great
>> Details are in Daisy already. I'm not sure why these documents has been not published on official
>> site. I will have a look at it as soon as Daisy is back (it's down currently).
>>
>> For such things it's good to report ASAP so we have a chance to fix it as it's usually trivial to do.
>>
>>
ah eh. great.
> I promised to Reinhard to create documentation of Servlet Service Framework a few days ago. I was
> more passionate about bug fixes and infrastructure work but I got back to this. Currently, I create
> a few simple applications to figure out what would user need to know in order to create them. I made
> a lot of notes, expect them all to be dumped into some kind of documentation quite soon. It will
> certainly cover context-path property.
>
>
yes, yes, I'm eager to have it ;)
>> -- I would like the servlet functionality to be mapped using the site
>> map (why else have a site map) but I still have to figure out how to do
>> it. :( documentation does not cover this.
>>
>
> I'm not sure if I understand you in detail but I fear it's not possible due to architecture
> constraints. Servlet Service Framework covers such advanced concepts like polymorphism of servlets
> when it comes to services identified by URIs. In order to make it working we needed a bit of static
> configuration.
>
> If you describe your use-case in detail I'm sure someone (including me) will give you an advice.
>
>
The use case is actually quite simple:
I want to be able to route all requests with a path of a certain regexp
to a servlet, and the config of the routing in the sitemap, instead of
being in the servlet service config or in the web.xml.
All request routing in 1 place. otherwise it's difficult to keep track,
especially overlaps in regexps (a request mapped in a pipeline AND in
the servlet service config, now what happens ? might this cause the
'commited' Exception described below ?)
>> -- My application has a different mapping when running the "mvn
>> jetty:run" way and as a .war file in the same jetty (the servlet mapping
>> is different) :(
>> The thing here is that although strictly this might not be a cocoon
>> problem but a jetty plugin problem or a spring configuration problem,
>> the documentation is lacking. The only thing that is more or less
>> correctly documented is the jetty-plugin.
>>
>
> Can you elaborate on this? It's the first time I hear about such an issue. I recommend you to be
> more open when it comes to sharing your problems. You could write an e-mail describing your troubles
> or even create a bug report.
> If you did it you would probably get a quick response because it's a close to my main interests in
> Cocoon and I try hard to not miss any mail/report related to topics like SSF or Maven.
>
>
I will split this out in a separate posting.
>> --I still have from time to time Exceptions:
>> java.lang.IllegalStateException: Committed
>> at org.mortbay.jetty.Response.resetBuffer(Response.java:972)
>> at org.mortbay.jetty.Response.reset(Response.java:921)
>> at
>> javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
>> at
>> org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:574)
>>
>> at
>> org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
>>
>> at
>> org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
>>
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
>>
>> at
>> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>>
>> at $Proxy5.service(Unknown Source)
>> at
>> org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
>>
>> As the application works, I can ignore it for know but again, I'm
>> quite clueless as to what I'm doing wrong
>> (maybe the request is given to the pipeline after the servlet has
>> done its job, but that's just a guess)
>>
>
> It is a bug caused by me when I committed some contribution. It has been already discussed on dev
> list and will be addressed soon, see:
> https://issues.apache.org/jira/browse/COCOON-2150
>
hm, yes, I found that one, but the case in which my exception happens is
totally different. I don't have any exception in the flow, nor have I
the 500 internal error code set earlier...
>
>> -- half of the 2.2 documentation is none existing and using the 2.1
>> documentation is fraud with danger as it sometimes works, sometimes not.
>> Most of the misfits come of Classes that now have a different name or
>> package, but it takes ages to figure that out.
>>
>
> Lack of migration guides like this:
> http://cocoon.apache.org/2.2/blocks/forms/1.0/1351_1_1.html
> or these:
> http://cocoon.apache.org/2.2/blocks/databases/1.0/1409_1_1.html
>
> Just asking because being curious if something like this is enough.
>
Well I suppose it's enough if your an experienced 2.1 user. I never used
2.1 so a diff doesn't mean a lot (unless i need to port 2.1 examples ;))
I just would like to have a reference guide of 2.2 that contains just
that: the reference.
>
>> - Architectural overview ?
>> didn't find any.
>>
>
> Yep, noted added to give even one simple page that would help a bit.
>
Yes, the early cocoon days (somewhere around 2001) had a nice overview
of the reactor and how it worked.
> Your criticism was very, very constructive and it brought a lot value to the discussion. I would
> love to always see such concrete e-mails. I'm very grateful for your e-mail.
>
>
ok, so I'll chew and spit some more when I'm blocked.
Anyway, I think cocoon is one of the best concepts to be found in the
Java world. It is just a shame Java webapp development (even with
spring/ cocoon/...) medieval compared to something like Zope
(http://zope.org/).
Just a simple example of a more advanced feature :
- Versioning is there inside the application server, so you can debug on
the application server in production in your own private coding session,
without disturbing the real production users. and then just 'commit'
your changes after you fixed it, and the next created user session will
use the latest (fixed) code.
This was introduced in Zope somewhere in the year 2000.
I'm also pretty sure SeaSide developers are laughing their asses off
when they see the current state of j2ee development.
But that's a different rant ;)
have fun,
Romain.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Romain Slootmaekers pisze:
> Ok, I can considered to be a novice user so I think my experiences are
> relevant here:
> (when reading back what I wrote below, I might sound a bit cynic and
> chaotic, so be warned)
>
> - installation: since I know maven, that was not too difficult. but I
> really don't like the fact that I get a +100MB repository just to tinker
> a bit with cocoon 2.2. this is too much for someone who just wants to
> play with it before you do real development. also, getting maven shoved
> down my throat is not my idea of a good time (maven is really an awful
> build tool, really, the only thing you gain is that standardization
> saves you explicit configuration). But hey, all in all I was really
> surprised that just by following the instructions on the site, I got it
> working (no twiddling required).
Even I'm not Maven lover anymore because I think this software is just too buggy and developers are
not eager enough to fix these annoying bugs and it is just written in a bad programming style in
many places. Nevertheless, I really think Maven improves situation not only for developers of
Cocoon. In 2.1 (as I remember it) there was no standard procedure for creating applications based on
C2.1 and it was everyone's burden to figure out best practices. In C2.2 all has been much more
standardized and in long term it will result in a better health of whole life-system.
When someone has a problem with C2.2 I can always ask him to provide a minimal block that exposes
problem/bug. When user attaches such block to JIRA issue all I have to do is to extract and call one
command:
mvn jetty:run
I can be sure in 99.99% of cases that I will see exactly the same behavior with minimal effort of me
so I can focus on figuring out what's going wrong. For user it is also trivial to create such block
because it has infrastructure (archetype) already in place.
> - playing with examples: yes, the miniature examples (your first block,
> adding an extra block) on the site work, but that's it. the rest of them
> hasn't been ported from 2.1 yet and no, they don't work out of the box,
> they need minor twiddling.
Rest examples (samples) is available in our SVN. You just need to check out source code of Cocoon,
call mvn install from root directory and then go to core/cocoon-webapp and call mvn jetty:run to see
many, many samples working out of the box. What minor twiddling do you refer to?
> - configuration: this is a complete disaster.
>
> -- it is just too difficult to let the average web developer do it, or
> change it. So whenever a junior web developer needs something, you need
> the senior java guru come in, waste some time fighting various .xml
> config files before the "webbie" can continue. Thing here is that yes,
> you can figure it out, but what you'ld like to have is the documentation
> telling you what to do.
I think that configuration in 2.2 is much, much better than in C2.1 but I agree it needs more
attention when it comes to documentation. Especially we need to explain how to fit all puzzles.
I will have something to show related to this topic very soon.
> -- most of the cocoon sub projects have a site, but most of the sites
> just are a bunch of nice looking, empty, maven generated, pages.
> for example:
> "Core modules in detail"
> fe
> http://cocoon.apache.org/2.2/core-modules/expression-language-impl/1.0/project-info.html
>
> http://cocoon.apache.org/2.2/core-modules/store-impl/1.0/project-info.html
>
> now where are the details ?
Details are in Daisy already. I'm not sure why these documents has been not published on official
site. I will have a look at it as soon as Daisy is back (it's down currently).
For such things it's good to report ASAP so we have a chance to fix it as it's usually trivial to do.
> Even when there is something there, it sometimes just does not work
> (Cocoon Authentication is such an example)
> The advantage is that before you have discovered it just doesn't work
> with the given documentation , you have learned enough new tricks to
> solve other problems.
>
> -- I had some legacy servlets I needed to use, it took me ages to
> discover I can set them up in servlet-service.xml instead of the usual
> j2ee web.xml ... no documentation about the collusion between the name
> of the block and the context-path parameter :(
> I must admit here that my unhappiness here is also caused by j2ee
> standards that get interpreted differently by each and every application
> server out there. I haven't done the effort yet of trying to run my app
> with JBoss yet, but I'm certain I'll be fighting xml config files for
> more than a working day.
I promised to Reinhard to create documentation of Servlet Service Framework a few days ago. I was
more passionate about bug fixes and infrastructure work but I got back to this. Currently, I create
a few simple applications to figure out what would user need to know in order to create them. I made
a lot of notes, expect them all to be dumped into some kind of documentation quite soon. It will
certainly cover context-path property.
> -- I would like the servlet functionality to be mapped using the site
> map (why else have a site map) but I still have to figure out how to do
> it. :( documentation does not cover this.
I'm not sure if I understand you in detail but I fear it's not possible due to architecture
constraints. Servlet Service Framework covers such advanced concepts like polymorphism of servlets
when it comes to services identified by URIs. In order to make it working we needed a bit of static
configuration.
If you describe your use-case in detail I'm sure someone (including me) will give you an advice.
> -- My application has a different mapping when running the "mvn
> jetty:run" way and as a .war file in the same jetty (the servlet mapping
> is different) :(
> The thing here is that although strictly this might not be a cocoon
> problem but a jetty plugin problem or a spring configuration problem,
> the documentation is lacking. The only thing that is more or less
> correctly documented is the jetty-plugin.
Can you elaborate on this? It's the first time I hear about such an issue. I recommend you to be
more open when it comes to sharing your problems. You could write an e-mail describing your troubles
or even create a bug report.
If you did it you would probably get a quick response because it's a close to my main interests in
Cocoon and I try hard to not miss any mail/report related to topics like SSF or Maven.
> --I still have from time to time Exceptions:
> java.lang.IllegalStateException: Committed
> at org.mortbay.jetty.Response.resetBuffer(Response.java:972)
> at org.mortbay.jetty.Response.reset(Response.java:921)
> at
> javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
> at
> org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:574)
>
> at
> org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
>
> at
> org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
>
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
>
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
>
> at $Proxy5.service(Unknown Source)
> at
> org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
>
> As the application works, I can ignore it for know but again, I'm
> quite clueless as to what I'm doing wrong
> (maybe the request is given to the pipeline after the servlet has
> done its job, but that's just a guess)
It is a bug caused by me when I committed some contribution. It has been already discussed on dev
list and will be addressed soon, see:
https://issues.apache.org/jira/browse/COCOON-2150
> -- half of the 2.2 documentation is none existing and using the 2.1
> documentation is fraud with danger as it sometimes works, sometimes not.
> Most of the misfits come of Classes that now have a different name or
> package, but it takes ages to figure that out.
Lack of migration guides like this:
http://cocoon.apache.org/2.2/blocks/forms/1.0/1351_1_1.html
or these:
http://cocoon.apache.org/2.2/blocks/databases/1.0/1409_1_1.html
Just asking because being curious if something like this is enough.
> - Architectural overview ?
> didn't find any.
Yep, noted added to give even one simple page that would help a bit.
>
> So the summary is,
> cocoon might be great, but loosing half a day finding out where to add 2
> lines in a .xml file (problem is always: which .xml file and which
> lines) is no fun.
> It might just be that the steep learning curve is just total lack of
> good documentation. And i'm pretty sure 90% of the developers just can't
> afford to waste so much time on trivial configuration stuff.
Agreed.
> I'm sorry to have written such a negative mail, since I do believe in
> (what I think to be) the concept of cocoon.
Your criticism was very, very constructive and it brought a lot value to the discussion. I would
love to always see such concrete e-mails. I'm very grateful for your e-mail.
I'm also thinking if our users couldn't be more active when it comes to documentation. I'm wondering
why people all not so eager to share their findings if they finally figure out some annoying
problem. I don't want to criticize anyone but I'm wondering if users sometimes do not demand too
much from developers...
> have fun,
Certainly I have now! I'm just capturing some goodies with Wink related to Cocoon...
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Grzegorz Kossakowski <gr...@tuffmail.com>.
Ralph Goers pisze:
>>
>> Can 2.2 be fixed to work with and without Maven so people can choose
>> whether to use Maven? Can this be handled so both versions are easily
>> maintained?
>>
> As you already know, you have commit rights. If you can come up with a
> way to do that that still meets the goals no one is going to stop you.
It's is already planned, see:
http://article.gmane.org/gmane.text.xml.cocoon.devel/75670
point "- provide a binary release of Cocoon 2.2".
Of course, help is always appreciated.
--
Grzegorz Kossakowski
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
solprovider@apache.org wrote:
> This thread highlights the strangeness of developer-driven development.
>
> Cocoon users want easy: easy creation of applications, easy
> integration with web servers, and easy addition of new components.
> Cocoon devs want Maven to better organize blocks. (Blocks are
> standard groups of components provided by the Cocoon project. Users
> focus on applications and rarely create blocks.)
>
I wouldn't characterize it quite that way. What has motivated Cocoon
developers for years was the desire to stop requiring that Cocoon be
downloaded and built from source. Maven and Spring provided the first
workable solution for that.
> Lenya users want less bugs, more functions, better control of URLs,
> and expansion without compiling.
> Lenya devs want Jackrabbit and a ClassLoader to add Java in blocks
> like Cocoon but without restarting Lenya.
>
> Both projects are releasing new versions that scare users.
>
> Using Cocoon within Maven should be provided as an optional wrapper.
> Maven users can use Maven to create Cocoon projects. Everybody else
> can:
> 1. Download Cocoon,
> 2.a Fix the the new lines in BAT files. (Microsoft OSes)
> 2.b Fix the file permissions for SH files. (Real OSes)
> 3. Create an application with a new XMAP and some supporting files.
> 4. Build and run without problems.
>
> Can 2.2 be fixed to work with and without Maven so people can choose
> whether to use Maven? Can this be handled so both versions are easily
> maintained?
>
As you already know, you have commit rights. If you can come up with a
way to do that that still meets the goals no one is going to stop you.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by so...@apache.org.
This thread highlights the strangeness of developer-driven development.
Cocoon users want easy: easy creation of applications, easy
integration with web servers, and easy addition of new components.
Cocoon devs want Maven to better organize blocks. (Blocks are
standard groups of components provided by the Cocoon project. Users
focus on applications and rarely create blocks.)
Lenya users want less bugs, more functions, better control of URLs,
and expansion without compiling.
Lenya devs want Jackrabbit and a ClassLoader to add Java in blocks
like Cocoon but without restarting Lenya.
Both projects are releasing new versions that scare users.
Using Cocoon within Maven should be provided as an optional wrapper.
Maven users can use Maven to create Cocoon projects. Everybody else
can:
1. Download Cocoon,
2.a Fix the the new lines in BAT files. (Microsoft OSes)
2.b Fix the file permissions for SH files. (Real OSes)
3. Create an application with a new XMAP and some supporting files.
4. Build and run without problems.
Can 2.2 be fixed to work with and without Maven so people can choose
whether to use Maven? Can this be handled so both versions are easily
maintained?
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Romain Slootmaekers <ro...@inuron.com>.
Ok,
I can considered to be a novice user so I think my experiences are
relevant here:
(when reading back what I wrote below, I might sound a bit cynic and
chaotic, so be warned)
- installation: since I know maven, that was not too difficult. but I
really don't like the fact that I get a +100MB repository just to tinker
a bit with cocoon 2.2. this is too much for someone who just wants to
play with it before you do real development. also, getting maven shoved
down my throat is not my idea of a good time (maven is really an awful
build tool, really, the only thing you gain is that standardization
saves you explicit configuration). But hey, all in all I was really
surprised that just by following the instructions on the site, I got it
working (no twiddling required).
- playing with examples: yes, the miniature examples (your first block,
adding an extra block) on the site work, but that's it. the rest of them
hasn't been ported from 2.1 yet and no, they don't work out of the box,
they need minor twiddling.
- configuration: this is a complete disaster.
-- it is just too difficult to let the average web developer do it, or
change it. So whenever a junior web developer needs something, you need
the senior java guru come in, waste some time fighting various .xml
config files before the "webbie" can continue. Thing here is that yes,
you can figure it out, but what you'ld like to have is the documentation
telling you what to do.
-- most of the cocoon sub projects have a site, but most of the sites
just are a bunch of nice looking, empty, maven generated, pages.
for example:
"Core modules in detail"
fe
http://cocoon.apache.org/2.2/core-modules/expression-language-impl/1.0/project-info.html
http://cocoon.apache.org/2.2/core-modules/store-impl/1.0/project-info.html
now where are the details ?
Even when there is something there, it sometimes just does not work
(Cocoon Authentication is such an example)
The advantage is that before you have discovered it just doesn't work
with the given documentation , you have learned enough new tricks to
solve other problems.
-- I had some legacy servlets I needed to use, it took me ages to
discover I can set them up in servlet-service.xml instead of the usual
j2ee web.xml ... no documentation about the collusion between the name
of the block and the context-path parameter :(
I must admit here that my unhappiness here is also caused by j2ee
standards that get interpreted differently by each and every application
server out there. I haven't done the effort yet of trying to run my app
with JBoss yet, but I'm certain I'll be fighting xml config files for
more than a working day.
-- I would like the servlet functionality to be mapped using the site
map (why else have a site map) but I still have to figure out how to do
it. :( documentation does not cover this.
-- My application has a different mapping when running the "mvn
jetty:run" way and as a .war file in the same jetty (the servlet mapping
is different) :(
The thing here is that although strictly this might not be a cocoon
problem but a jetty plugin problem or a spring configuration problem,
the documentation is lacking. The only thing that is more or less
correctly documented is the jetty-plugin.
--I still have from time to time Exceptions:
java.lang.IllegalStateException: Committed
at org.mortbay.jetty.Response.resetBuffer(Response.java:972)
at org.mortbay.jetty.Response.reset(Response.java:921)
at
javax.servlet.ServletResponseWrapper.reset(ServletResponseWrapper.java:193)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:574)
at
org.apache.cocoon.servletservice.ServletServiceContext$PathDispatcher.forward(ServletServiceContext.java:544)
at
org.apache.cocoon.servletservice.spring.ServletFactoryBean$ServiceInterceptor.invoke(ServletFactoryBean.java:230)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:166)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy5.service(Unknown Source)
at
org.apache.cocoon.servletservice.DispatcherServlet.service(DispatcherServlet.java:102)
As the application works, I can ignore it for know but again, I'm
quite clueless as to what I'm doing wrong
(maybe the request is given to the pipeline after the servlet has
done its job, but that's just a guess)
-- half of the 2.2 documentation is none existing and using the 2.1
documentation is fraud with danger as it sometimes works, sometimes not.
Most of the misfits come of Classes that now have a different name or
package, but it takes ages to figure that out.
- Architectural overview ?
didn't find any.
So the summary is,
cocoon might be great, but loosing half a day finding out where to add 2
lines in a .xml file (problem is always: which .xml file and which
lines) is no fun.
It might just be that the steep learning curve is just total lack of
good documentation. And i'm pretty sure 90% of the developers just can't
afford to waste so much time on trivial configuration stuff.
I'm sorry to have written such a negative mail, since I do believe in
(what I think to be) the concept of cocoon.
have fun,
Romain.
Ralph Goers wrote:
> My "wish" for Cocoon 2.2 has always been that
> 1. The "download" of Cocoon would be nothing more than installing a
> maven plugin.
> 2. You'd use a Maven archetype to create a starter project. Ideally,
> this is how the sample site should get created.
> 3. Building your project would automatically download the rest of
> cocoon based upon the dependencies specified in the created project.
> 4. Building a project thus requires documentation on all the available
> blocks, the services they provide, and how to invoke them.
>
> Unfortunately, I am still almost entirely focused on Cocoon 2.1 so I'm
> not certain how close we have gotten to my wish, but I have a feeling
> that if we can't do this today the effort to get there is pretty minimal.
>
> Ralph
>
> bart remmerie wrote:
>> Dear all,
>>
>> During the past couple of months, I've been reading about "install
>> issues" with cocoon 2.2 all the time.
>> There seem to be hardcore users, convinced that cocoon 2.2 is
>> superior now that it's linked with maven and spring, ...
>> but there also are novice and/or less expert users, who are having a
>> lot of problems with the new 2.2 configuration & installation.
>>
>> Some years ago, the steep learning curve for cocoon was seen as one
>> of the major problems to overcome while creating a larger user-base.
>> Shifting towards the integration with maven & spring doesn't simplify
>> things.
>> Another issue was the lack of documentation... but in the past, the
>> installation worked when you followed the instructions & you had a
>> load of samples to get to know cocoon...
>> Now, cocoon seems to become so complicated that no-one has the time
>> to document it properly.
>>
>> Whatever the "hardcore" users may pretend, the perception of
>> beginning user will define the evolution of cocoon.
>>
>> Therefore my wishes for 2008:
>> listen to & learn from the novice users:
>> * simplify the installation & ease of use (in the perception of
>> beginners)
>> * document your framework (in such a way that beginners consider it
>> documented)
>>
>> a little frustrated but hoping for the best,
>>
>> Bart
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Reinhard Poetz <re...@apache.org>.
Ralph Goers wrote:
> My "wish" for Cocoon 2.2 has always been that
> 1. The "download" of Cocoon would be nothing more than installing a
> maven plugin.
> 2. You'd use a Maven archetype to create a starter project. Ideally,
> this is how the sample site should get created.
> 3. Building your project would automatically download the rest of cocoon
> based upon the dependencies specified in the created project.
> 4. Building a project thus requires documentation on all the available
> blocks, the services they provide, and how to invoke them.
>
> Unfortunately, I am still almost entirely focused on Cocoon 2.1 so I'm
> not certain how close we have gotten to my wish, but I have a feeling
> that if we can't do this today the effort to get there is pretty minimal.
1-3 is already in place.
@4: There is already documentation available but it's not as complete as I would
like to see it :-(
What kind of documentation is missing most of all?
--
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, PMC Chair reinhard@apache.org
_________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: best wishes for 2008: 2.1 vs. 2.2
Posted by Ralph Goers <Ra...@dslextreme.com>.
My "wish" for Cocoon 2.2 has always been that
1. The "download" of Cocoon would be nothing more than installing a
maven plugin.
2. You'd use a Maven archetype to create a starter project. Ideally,
this is how the sample site should get created.
3. Building your project would automatically download the rest of cocoon
based upon the dependencies specified in the created project.
4. Building a project thus requires documentation on all the available
blocks, the services they provide, and how to invoke them.
Unfortunately, I am still almost entirely focused on Cocoon 2.1 so I'm
not certain how close we have gotten to my wish, but I have a feeling
that if we can't do this today the effort to get there is pretty minimal.
Ralph
bart remmerie wrote:
> Dear all,
>
> During the past couple of months, I've been reading about "install
> issues" with cocoon 2.2 all the time.
> There seem to be hardcore users, convinced that cocoon 2.2 is superior
> now that it's linked with maven and spring, ...
> but there also are novice and/or less expert users, who are having a
> lot of problems with the new 2.2 configuration & installation.
>
> Some years ago, the steep learning curve for cocoon was seen as one of
> the major problems to overcome while creating a larger user-base.
> Shifting towards the integration with maven & spring doesn't simplify
> things.
> Another issue was the lack of documentation... but in the past, the
> installation worked when you followed the instructions & you had a
> load of samples to get to know cocoon...
> Now, cocoon seems to become so complicated that no-one has the time to
> document it properly.
>
> Whatever the "hardcore" users may pretend, the perception of beginning
> user will define the evolution of cocoon.
>
> Therefore my wishes for 2008:
> listen to & learn from the novice users:
> * simplify the installation & ease of use (in the perception of beginners)
> * document your framework (in such a way that beginners consider it
> documented)
>
> a little frustrated but hoping for the best,
>
> Bart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org