You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/07/25 18:43:06 UTC
HttpServletRequest vs o.a.c.e.Request saga continues
Hi guys,
============ Background ============
My recent commit r559394[1] broke Cocoon again. More specifically, you will get
java.lang.NoClassDefFoundError: org/apache/commons/beanutils/ConvertUtils
or JXPath's error that it can't find org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper function. This error has been
mentioned[2] by Reinhard long time ago and Daniel gave response[3]:
You are only supposed to have direct access to java.*, IIUC, packages
from FOM for other packages you must have a "Package." prefix, i.e.
value="#{Package.org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}
This is the behaviour that is implemented in
o.a.c.environment.TemplateObjectModelHelper.addJavaPackages.
So I thought that I messed some initialization and wasted handful amount of time to track down the problem. I was wrong. JXPath uses it's
default set of functions if none is registered (and it *is* the case, so Daniel's response was completely misleading) that gives access to
all Java classes. The error I'm getting is because of createHelper signature:
public static JXMacrosHelper createHelper(XMLConsumer consumer, Request request, String locale)
It expects o.a.c.e.Request but after applying[1] object model contains HttpServletRequest thus JXPath's evaluation fails.
============ Possible solutions ============
The half of the work is already done - we know why it is broken, now I would like to discuss with you possible fixes. We have three distinct
options:
1. Store o.a.c.e.Request implementation in Object Model and provide wrappers that would be manually created in places where needed.
HttpRequest (which is only implementation of Request interface that we can consider) wraps HttpServletRequest. It means we could have
several wrapping levels. *Messy* to my taste.
2. Make a o.a.c.e.Request interface extend HttpServletRequest interface. That would be a solution, because we could store such
implementation in Object Model as HttpServletRequest and cast where its needed to o.a.c.e.Request (JXPath would do it automatically for us).
Such solution was mentioned several times before, like here[4] by Carsten. I haven't evaluated this option much. Does it still makes sense,
what about concerns raised by Carsten? Are there any other?
3. Forget about back compatibility and clean up the mess, start switching to HttpServletRequest *right away*. In most cases the changes
would be trivial (changing imports in various classes). Of course I don't want to get rid of Cocoon's Request interface everywhere at once
because it's not in scope of my GSoC work. I only want to get rid of it where it's needed.
Ok, you guessed it I prefer third option. I've performed already incompatible changes like Ajax and Forms migration to servlet-service-fw[5]
and provided quite good migration guides like[6]. People were happy with it... I think that the key was they clearly knew what to do with
their applications in order to get back them to usable state. Isn't it a case, Felix?
I could provide such guide for incompatible changes if they occurred. After playing with Cocoon's internals for some time I think that there
is no way that I can improve something significantly and stay 100% back-compliant because current functionality relies on hacks, plumbing,
bungs and other weird things. Undoubtedly, we are approaching to my sermonizing.
============ Sermonizing ============
I must confess that I'm fed up with Cocoon's internals.
Cocoon's internal are fucking crazy.
Sorry for strong words but I must give vent to my emotions. Now more matter-of-fact arguments:
* We have two different request objects original servlet's one and our own one. The problems that this situation causes has been
discussed above.
* We have at least four different object models!
a) objectModel map that is passed to components
b) FlowscriptObjectModel
c) TemplateObjectModel (if template was called by flowscript)
d) TemplateObjectModel (if template wasn't called by flowscript)
Items c) and d) do not differ only in data user puts while calling sendPage, it would be too obvious. It differs in some internal,
obscure areas so some functionality working in template called from flowscript (like constructing new objects) will not work if you just
call it out of flow execution scope.
* Have you been aware of "this" variable in object model? (argh need to be specific, in object model available in template). Take a look
at this:
<jx:set var="cformsDummy" value="${cformsHelper.generateRepeaterWidgetLabel(widget, id, this['widget-id'])}"/> (from jx-macros.xml)
I guess that it's the only place that is used, it was implemented in bug-possibly way (don't want to bore you with details) and was
not covered by tests nor documented ANYWHERE.
This lists could be much longer. This lists make me sick because it was never as much painful to develop something Cocoon-related as this
GSoC work. I was prepared to some obstacles, world is not perfect, I knew that our internals are far from perfection. Now I know that they
are fucking crazy, period.
WDYT?
[1] http://article.gmane.org/gmane.text.xml.cocoon.cvs/24848
[2] http://article.gmane.org/gmane.text.xml.cocoon.devel/50595
[3] http://article.gmane.org/gmane.text.xml.cocoon.devel/50621
[4] http://article.gmane.org/gmane.text.xml.cocoon.devel/59143
[5] https://issues.apache.org/jira/browse/COCOON-1991
[6] http://cocoon.zones.apache.org/daisy/cdocs-forms/g1/1351.html
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
>>
>> Good point. I agree that we should keep these methods available but,
>> AFAIK, they are used only to handle cocoon: source and sitemap mounts.
>
> They might be used by users in JXTemplate and flowscripts as well.
>
>> This functionality should be replaced by cocoon-servlet-service-fw and
>> cocoon: source plus map:mount should be deprecated in the near future,
>> right?
>
> I think we should recommend people using servlet services instead of
> cocoon: and map:mount. But deprecating cocoon: source and map:mount
> would probably affect tons of existing webapps. I don't think it would
> be worth it.
I would like to deprecate them in 2.3.x version of cocoon's core so they would be removed in 2.4.x.
I hardly can imagine application developed with Cocoon 2.1.x that anyone could want to run with 2.4.x.
What about Marc's opinion[1] on dragging our history with us? I really agree with his opinion.
Thanks to your work we can let cocoon: and map:mount rest in peace and remove a decent amount of code handling cocoon: calls.
>>> Four options with the one I described above.
>>
>> Where exactly? Do I miss something?
>
> What I mean (above) is that in CocoonEntryObjectModelProvider you are
> filling the request and response fields with HttpSevletRequest and
> HttpServletResponse objects. This is in contrast with the previous floW
> and template object models who used Request and Response objects for
> these fields. And as you have seen your change is backward incompatible.
>
> You could easily fix the problem by using the Request and Response
> objects from the processInfoProvider.getObjectModel().
>
> Actually this should be enough. While I would love to let our
> environment abstractions extend the http servlet ones and phase out the
> use of them where ever possible this would be orthogonal to your GSoC
> needs. So it could be done later.
Eureka! ;) Thanks Daniel for your suggestion. I cannot wait to try it out.
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74314
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Daniel Fagerstrom pisze:
>> Grzegorz Kossakowski skrev:
>>
>> My response wasn't misleading when I wrote it, but the code has
>> changed since then:
>> http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java?r1=307119&r2=321148,
>> http://svn.apache.org/viewvc?view=rev&revision=416391.
>
> I hope that you don't treat my statements as offending ones.
No problem.
> I think that we are speaking about two different things. It does not
> matter that signature of any method changed since your response. What
> matters is that you said that one can access classes registered by
> o.a.c.environment.TemplateObjectModelHelper.addJavaPackages. I'm not
> sure about other expression languages, but when it comes to the JXPath
> all classes are available by default thanks to GENERIC_FUNCTIONS static
> instance. Take a look at
> org.apache.commons.jxpath.JXPathContext#getFunctions() for details.
You are right, addJavaPackages is not used for function calling in JXPath.
> Packages added by
> o.a.c.environment.TemplateObjectModelHelper.addJavaPackages seems to be
> used in JS expressions (but I'm not 100% sure). I have no clue about JEXL.
But the added packages are AFAICS used for JEXL and JS.
>>> It expects o.a.c.e.Request but after applying[1] object model
>>> contains HttpServletRequest thus JXPath's evaluation fails.
>>
>> I'm not certain that it is such a good idea to use HttpServletRequest
>> instead of o.a.c.e.Request in your new object model. By doing that
>> you, except for breaking some code, miss info about the path of the
>> current sub sitemap which might be useful. Request contains the
>> following methods that not is part of HttpServletRequest:
>>
>> String getSitemapURI();
>> String getSitemapURIPrefix();
>> String getSitemapPath();
>
> Good point. I agree that we should keep these methods available but,
> AFAIK, they are used only to handle cocoon: source and sitemap mounts.
They might be used by users in JXTemplate and flowscripts as well.
> This functionality should be replaced by cocoon-servlet-service-fw and
> cocoon: source plus map:mount should be deprecated in the near future,
> right?
I think we should recommend people using servlet services instead of
cocoon: and map:mount. But deprecating cocoon: source and map:mount
would probably affect tons of existing webapps. I don't think it would
be worth it.
>> Four options with the one I described above.
>
> Where exactly? Do I miss something?
What I mean (above) is that in CocoonEntryObjectModelProvider you are
filling the request and response fields with HttpSevletRequest and
HttpServletResponse objects. This is in contrast with the previous floW
and template object models who used Request and Response objects for
these fields. And as you have seen your change is backward incompatible.
You could easily fix the problem by using the Request and Response
objects from the processInfoProvider.getObjectModel().
Actually this should be enough. While I would love to let our
environment abstractions extend the http servlet ones and phase out the
use of them where ever possible this would be orthogonal to your GSoC
needs. So it could be done later.
/Daniel
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>
> My response wasn't misleading when I wrote it, but the code has changed
> since then:
> http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java?r1=307119&r2=321148,
> http://svn.apache.org/viewvc?view=rev&revision=416391.
I hope that you don't treat my statements as offending ones.
I think that we are speaking about two different things. It does not matter that signature of any method changed since your response. What
matters is that you said that one can access classes registered by o.a.c.environment.TemplateObjectModelHelper.addJavaPackages. I'm not sure
about other expression languages, but when it comes to the JXPath all classes are available by default thanks to GENERIC_FUNCTIONS static
instance. Take a look at org.apache.commons.jxpath.JXPathContext#getFunctions() for details.
Packages added by o.a.c.environment.TemplateObjectModelHelper.addJavaPackages seems to be used in JS expressions (but I'm not 100% sure). I
have no clue about JEXL.
>> It expects o.a.c.e.Request but after applying[1] object model contains
>> HttpServletRequest thus JXPath's evaluation fails.
>
> I'm not certain that it is such a good idea to use HttpServletRequest
> instead of o.a.c.e.Request in your new object model. By doing that you,
> except for breaking some code, miss info about the path of the current
> sub sitemap which might be useful. Request contains the following
> methods that not is part of HttpServletRequest:
>
> String getSitemapURI();
> String getSitemapURIPrefix();
> String getSitemapPath();
Good point. I agree that we should keep these methods available but, AFAIK, they are used only to handle cocoon: source and sitemap mounts.
This functionality should be replaced by cocoon-servlet-service-fw and cocoon: source plus map:mount should be deprecated in the near
future, right?
>
> Four options with the one I described above.
Where exactly? Do I miss something?
>> 3. Forget about back compatibility and clean up the mess, start
>> switching to HttpServletRequest *right away*. In most cases the
>> changes would be trivial (changing imports in various classes). Of
>> course I don't want to get rid of Cocoon's Request interface
>> everywhere at once because it's not in scope of my GSoC work. I only
>> want to get rid of it where it's needed.
>
> "Cleaning up the mess" sounds like a rather vague plan to me ;) I would
> prefer some suggestions about how it could be done and what consequences
> it would have. You still need to handle the sub sitemap path stuff that
> is part of Request but not HttpServletRequest.
Ok, let's forget about it. I just wanted to get rid of our interface Request by any means because it was a pain for me. No insightful
proposal supported this option. ;)
> My proposal would be to combine my option in the beginning with option
> 2, and follow option 3 in the sense that Request can be switched to
> HttpServletRequest everywhere in the code where the sub sitemap path
> methods not are used.
Agreed!
> I agree. As you see there is some reason that only a few dare to touch
> it. But it is nothing unique for Cocoon, most projects that has been
> around for many years suffers from the same problems. Continuous
> refactoring and rearchetecturing is needed to keep the code manageable.
> While it might be hard to believe, it has been even worse, we have
> considerably simplified the code in several areas (the setup sequence
> i.e. was complicated beyond belief before). And now you are working to
> simplify another significant area. Still it is from time to time a
> deeply frustrating experience to clean up the mess.
Yes, and I'm not used to such situation. I'm learning a lot, though!
>> * We have at least four different object models!
>> a) objectModel map that is passed to components
>
> I think we should deprecate (or at least discourage) the use of the
> object model. With a sitemap scoped beans for the environment objects
> (as described in
> http://marc.info/?l=xml-cocoon-dev&m=118578691800176&w=2) we have a
> mechanism for getting environment objects with DI, which is much
> preferable IMO.
>
+100
>> b) FlowscriptObjectModel
>> c) TemplateObjectModel (if template was called by flowscript)
>> d) TemplateObjectModel (if template wasn't called by flowscript)
>
> That is part of the scope of your GSoC to clean up isn't it?
>
Yes, but it turned out to be more complicated than I thought so I'm not saying that I don't want to do this but I'm saying that current
situation is horrible. I shared my feeling in a hope that we can avoid such situations in the future.
>> Items c) and d) do not differ only in data user puts while
>> calling sendPage, it would be too obvious. It differs in some
>> internal, obscure areas so some functionality working in template
>> called from flowscript (like constructing new objects) will not work
>> if you just call it out of flow execution scope.
>
> Is the differences intentional or are they bugs?
I would say that they are limitation of current architecture. Some initialization takes place when flowscript is called and has impact of
further calls of template. When template is used outside flowscript scope not all methods of these plenty Helper classes are called.
I cannot give you details because in the rush of debugging I forgot which methods are called and which are not in both cases. I'll try to
sort out it just after resolving current issues.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Hi guys,
>
> ============ Background ============
>
> My recent commit r559394[1] broke Cocoon again. More specifically, you
> will get
>
> java.lang.NoClassDefFoundError: org/apache/commons/beanutils/ConvertUtils
>
> or JXPath's error that it can't find
> org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper function.
> This error has been mentioned[2] by Reinhard long time ago and Daniel
> gave response[3]:
>
> You are only supposed to have direct access to java.*, IIUC, packages
> from FOM for other packages you must have a "Package." prefix, i.e.
>
> value="#{Package.org.apache.cocoon.forms.generation.JXMacrosHelper.createHelper($cocoon/consumer,$cocoon/request)}
>
>
> This is the behaviour that is implemented in
> o.a.c.environment.TemplateObjectModelHelper.addJavaPackages.
>
> So I thought that I messed some initialization and wasted handful amount
> of time to track down the problem. I was wrong. JXPath uses it's default
> set of functions if none is registered (and it *is* the case, so
> Daniel's response was completely misleading) that gives access to all
> Java classes. The error I'm getting is because of createHelper signature:
>
> public static JXMacrosHelper createHelper(XMLConsumer consumer,
> Request request, String locale)
My response wasn't misleading when I wrote it, but the code has changed
since then:
http://svn.apache.org/viewvc/cocoon/trunk/blocks/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java?r1=307119&r2=321148,
http://svn.apache.org/viewvc?view=rev&revision=416391.
> It expects o.a.c.e.Request but after applying[1] object model contains
> HttpServletRequest thus JXPath's evaluation fails.
I'm not certain that it is such a good idea to use HttpServletRequest
instead of o.a.c.e.Request in your new object model. By doing that you,
except for breaking some code, miss info about the path of the current
sub sitemap which might be useful. Request contains the following
methods that not is part of HttpServletRequest:
String getSitemapURI();
String getSitemapURIPrefix();
String getSitemapPath();
> ============ Possible solutions ============
>
> The half of the work is already done - we know why it is broken, now I
> would like to discuss with you possible fixes. We have three distinct
> options:
Four options with the one I described above.
> 1. Store o.a.c.e.Request implementation in Object Model and provide
> wrappers that would be manually created in places where needed.
> HttpRequest (which is only implementation of Request interface that we
> can consider) wraps HttpServletRequest. It means we could have several
> wrapping levels. *Messy* to my taste.
We already has these wrapping levels in current Cocoon so you don't add
any "messiness", AFAICS. But some way to differ between the Request and
the HttpServletRequest would be needed while accessing the object model.
One could use e.g. "cocoon.request" and "cocoon.httpservletrequest". But
that does not exactly simplifying the object model, which is your task,
so I don't like this option.
> 2. Make a o.a.c.e.Request interface extend HttpServletRequest interface.
> That would be a solution, because we could store such implementation in
> Object Model as HttpServletRequest and cast where its needed to
> o.a.c.e.Request (JXPath would do it automatically for us). Such solution
> was mentioned several times before, like here[4] by Carsten. I haven't
> evaluated this option much. Does it still makes sense, what about
> concerns raised by Carsten? Are there any other?
This is the preferred option IMO. It is simple, easy to understand and
essentially back compatible. As I discussed in
http://marc.info/?l=xml-cocoon-dev&m=118578978307510&w=2 I think the
minor incompatibilities that we would get is well worth the advantages.
> 3. Forget about back compatibility and clean up the mess, start
> switching to HttpServletRequest *right away*. In most cases the changes
> would be trivial (changing imports in various classes). Of course I
> don't want to get rid of Cocoon's Request interface everywhere at once
> because it's not in scope of my GSoC work. I only want to get rid of it
> where it's needed.
"Cleaning up the mess" sounds like a rather vague plan to me ;) I would
prefer some suggestions about how it could be done and what consequences
it would have. You still need to handle the sub sitemap path stuff that
is part of Request but not HttpServletRequest.
My proposal would be to combine my option in the beginning with option
2, and follow option 3 in the sense that Request can be switched to
HttpServletRequest everywhere in the code where the sub sitemap path
methods not are used.
> Ok, you guessed it I prefer third option. I've performed already
> incompatible changes like Ajax and Forms migration to
> servlet-service-fw[5] and provided quite good migration guides like[6].
> People were happy with it... I think that the key was they clearly knew
> what to do with their applications in order to get back them to usable
> state. Isn't it a case, Felix?
>
> I could provide such guide for incompatible changes if they occurred.
> After playing with Cocoon's internals for some time I think that there
> is no way that I can improve something significantly and stay 100%
> back-compliant because current functionality relies on hacks, plumbing,
> bungs and other weird things. Undoubtedly, we are approaching to my
> sermonizing.
>
> ============ Sermonizing ============
>
> I must confess that I'm fed up with Cocoon's internals.
>
> Cocoon's internal are fucking crazy.
I agree. As you see there is some reason that only a few dare to touch
it. But it is nothing unique for Cocoon, most projects that has been
around for many years suffers from the same problems. Continuous
refactoring and rearchetecturing is needed to keep the code manageable.
While it might be hard to believe, it has been even worse, we have
considerably simplified the code in several areas (the setup sequence
i.e. was complicated beyond belief before). And now you are working to
simplify another significant area. Still it is from time to time a
deeply frustrating experience to clean up the mess.
> Sorry for strong words but I must give vent to my emotions. Now more
> matter-of-fact arguments:
>
> * We have two different request objects original servlet's one and
> our own one. The problems that this situation causes has been discussed
> above.
Option 2, solves the involved problems. The sub sitemap paths still
require us to have some custom interfaces.
> * We have at least four different object models!
> a) objectModel map that is passed to components
I think we should deprecate (or at least discourage) the use of the
object model. With a sitemap scoped beans for the environment objects
(as described in
http://marc.info/?l=xml-cocoon-dev&m=118578691800176&w=2) we have a
mechanism for getting environment objects with DI, which is much
preferable IMO.
> b) FlowscriptObjectModel
> c) TemplateObjectModel (if template was called by flowscript)
> d) TemplateObjectModel (if template wasn't called by flowscript)
That is part of the scope of your GSoC to clean up isn't it?
> Items c) and d) do not differ only in data user puts while calling
> sendPage, it would be too obvious. It differs in some internal, obscure
> areas so some functionality working in template called from flowscript
> (like constructing new objects) will not work if you just call it out of
> flow execution scope.
Is the differences intentional or are they bugs?
/Daniel
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
>
> The point is that both I and Reinhard want you to succeed with your GSoC
> project. I'm completely assured that you are capable of succeeding. But
> as you have become aware of the task isn't trivial. So to succeed you
> need focus on tasks that is necessary for your project and wait with all
> the rest of the interesting tasks that pops up until later.
>
> Priority and focus is everything for successful projects. The hard thing
> is not to choose what to do, but to chose what not to do.
I agree wholeheartedly - the temptation to fix everything what demands fixing is really high.
Daniel and the rest, I really want to say that I enjoy and appreciate your personal and social comments. All in all, Apache is about
building community first and code as a second goal; you really understand this principle, IMHO.
>> I wanted to work on C2.2 release because current state of things
>> effectively stops me from continuing my work.
>
> It doesn't ;)
;)
>> On the other hand, I cannot (and wouldn't want to) release 2.2 only
>> myself so even there are folks willing to help whole process demands
>> some time and it cannot be speeded up by my full commitment. Thus I
>> think the quickest and most effective solution is:
>> 1. Revert changes in r559394 that broke the trunk
>
> We found a solution on that didn't we?
Yes, but this mail was sent before you explained what you meant. :-)
> For me it took a long time before I felt that I had the right to touch
> the core. So while refactoring the template stuff I did everything
> within the template block and worked on own copies of the object models
> rather than fixing the core ones. In retrorespect this was clearly
> counterproductive and I'm sure you wish that I had acted more confident
> back then. Now you have to clean up instead ;)
YES :)
> Anyway, *you have the right to work in the core*. And I'm pushing you
> beyond your comfort zone to accelerate the process in making you
> understand it. Actually, if you think about it, you are probably already
> the greatest expert on some parts of the core.
Thanks! It's really encouraging.
> Now, if you feel that it is absolutely necessary, you can of course
> branch the trunk. But think about the consequences. If you break
> something in your branch it is much less likely that you will notice as
> you are the only tester. You will get less feedback. And when you merge
> back to the trunk you will get feedback and error reports on things
> where you don't remember the details anymore. So in the end I would
> think that you don't win anything, quite the opposite.
OK.
> I think limited branching for testing an idea as you did a couple of
> weeks ago is fine as long as you merge back soon. But I think that
> working in a branch for more than a few days is a mistake.
I feel more comfortable in branch because I can commit often (and that is what I prefer) so code can even not compile (it was a case in my
latest branch). I was really disappointed by the fact that svn log is lost during merging back to the trunk so I was trying to find other
solution. It was a weird attempt, I must admit.
Since, I have green light for more braver actions in the trunk so I'm going to stay there.
>
> Don't know if the added complexity is worthwhile. What I would like to
> see is that we have a time boxed release scheme where we ship more or
> less automatically every sixth week. This would give a natural community
> rhythm where we can do experimental stuff in the beginning of the period
> and need to focus on making everything work in the end of the period.
> Eclipse does something like that and it seem to work really well
> http://www.artima.com/lejava/articles/eclipse_culture.html.
Already read this article. I agree with it.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Reinhard Poetz pisze:
>> Daniel Fagerstrom wrote:
>>> If you feel that you can spend some time on the 2.2 release without
>>> endangering your GSoC task, feel free to do that. If not, focus on
>>> your GSoC task.
>>
>> Although I think that a C22 release would be more than necessary, I
>> have to agree with Daniel. It's not only you who currently has a more
>> important goal (GSoC) but others have too - otherwise the release
>> would be out for months. So don't worry too much.
>>
>> At the end of August Daniel will evaluate your GSoC work. If you push
>> forward the final release or the documentation it will be great for
>> the project in general but (as you certainly know) doesn't have any
>> relevance for your GSoC evaluation.
>
> I can agree with you both, but you have missed the point, IMHO.
The point is that both I and Reinhard want you to succeed with your GSoC
project. I'm completely assured that you are capable of succeeding. But
as you have become aware of the task isn't trivial. So to succeed you
need focus on tasks that is necessary for your project and wait with all
the rest of the interesting tasks that pops up until later.
Priority and focus is everything for successful projects. The hard thing
is not to choose what to do, but to chose what not to do.
> I wanted to work on C2.2 release because current state of things
> effectively stops me from continuing my work.
It doesn't ;)
> We have already released RC1
> so I think that major changes (even internal) should not come into 2.2
> final.
In principle yes, but it wouldn't work for Cocoon. Anyway, 99.9% of the
contracts in Cocoon will be unchanged by your work.
> Moreover, I'm almost sure that my work will destabilize trunk
> from time to time because I've already learned that it's impossible (or,
> ineffective in a case if you wait for perfection before committing)
> to keep everything stable and working.
It is no big deal if you destabilize or break something from time to
time. In all cases this far you or we have been able to fix it quickly.
And if somethings takes to long to fix, it can always be reverted.
> This could lead to the situation
> that we want to release 2.2 but my stuff is "half-baked" and since
> it is in the core it stops the release.
We have to keep this in mind when we are approaching a code freeze. But
as long as we not even have a release date, you shouldn't worry about it
and just contimue your work.
> On the other hand, I cannot (and wouldn't want to) release 2.2 only
> myself so even there are folks willing to help whole process demands
> some time and it cannot be speeded up by my full commitment. Thus I
> think the quickest and most effective solution is:
> 1. Revert changes in r559394 that broke the trunk
We found a solution on that didn't we?
> 2. Branch whole trunk for my GSoC work and start work there
For me it took a long time before I felt that I had the right to touch
the core. So while refactoring the template stuff I did everything
within the template block and worked on own copies of the object models
rather than fixing the core ones. In retrorespect this was clearly
counterproductive and I'm sure you wish that I had acted more confident
back then. Now you have to clean up instead ;)
Anyway, *you have the right to work in the core*. And I'm pushing you
beyond your comfort zone to accelerate the process in making you
understand it. Actually, if you think about it, you are probably already
the greatest expert on some parts of the core.
Now, if you feel that it is absolutely necessary, you can of course
branch the trunk. But think about the consequences. If you break
something in your branch it is much less likely that you will notice as
you are the only tester. You will get less feedback. And when you merge
back to the trunk you will get feedback and error reports on things
where you don't remember the details anymore. So in the end I would
think that you don't win anything, quite the opposite.
I think limited branching for testing an idea as you did a couple of
weeks ago is fine as long as you merge back soon. But I think that
working in a branch for more than a few days is a mistake.
> While considering second step I'm starting to think that it would more
> make sense to branch modules that we are going to release so they can
> stabilize and others could continue work in the trunk. What worries me
> is that our modules are not self-contained (they need parent poms, for
> example) so I don't have an idea how to branch a subset of our modules.
> Branching whole trunk does not make sense because some modules are ready
> for a release and some are not. Do you have an idea how to manage two
> versioning (maintenance and developer's) lines of our Maven modules?
Don't know if the added complexity is worthwhile. What I would like to
see is that we have a time boxed release scheme where we ship more or
less automatically every sixth week. This would give a natural community
rhythm where we can do experimental stuff in the beginning of the period
and need to focus on making everything work in the end of the period.
Eclipse does something like that and it seem to work really well
http://www.artima.com/lejava/articles/eclipse_culture.html.
/Daniel
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Daniel Fagerstrom wrote:
>> If you feel that you can spend some time on the 2.2 release without
>> endangering your GSoC task, feel free to do that. If not, focus on
>> your GSoC task.
>
> Although I think that a C22 release would be more than necessary, I have
> to agree with Daniel. It's not only you who currently has a more
> important goal (GSoC) but others have too - otherwise the release would
> be out for months. So don't worry too much.
>
> At the end of August Daniel will evaluate your GSoC work. If you push
> forward the final release or the documentation it will be great for the
> project in general but (as you certainly know) doesn't have any
> relevance for your GSoC evaluation.
I can agree with you both, but you have missed the point, IMHO.
I wanted to work on C2.2 release because current state of things effectively stops me from continuing my work. We have already released RC1
so I think that major changes (even internal) should not come into 2.2 final. Moreover, I'm almost sure that my work will destabilize trunk
from time to time because I've already learned that it's impossible (or, ineffective in a case if you wait for perfection before committing)
to keep everything stable and working. This could lead to the situation that we want to release 2.2 but my stuff is "half-baked" and since
it is in the core it stops the release.
On the other hand, I cannot (and wouldn't want to) release 2.2 only myself so even there are folks willing to help whole process demands
some time and it cannot be speeded up by my full commitment. Thus I think the quickest and most effective solution is:
1. Revert changes in r559394 that broke the trunk
2. Branch whole trunk for my GSoC work and start work there
While considering second step I'm starting to think that it would more make sense to branch modules that we are going to release so they can
stabilize and others could continue work in the trunk. What worries me is that our modules are not self-contained (they need parent poms,
for example) so I don't have an idea how to branch a subset of our modules. Branching whole trunk does not make sense because some modules
are ready for a release and some are not. Do you have an idea how to manage two versioning (maintenance and developer's) lines of our Maven
modules?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Reinhard Poetz <re...@apache.org>.
Daniel Fagerstrom wrote:
> If
> you feel that you can spend some time on the 2.2 release without
> endangering your GSoC task, feel free to do that. If not, focus on your
> GSoC task.
Although I think that a C22 release would be more than necessary, I have to
agree with Daniel. It's not only you who currently has a more important goal
(GSoC) but others have too - otherwise the release would be out for months. So
don't worry too much.
At the end of August Daniel will evaluate your GSoC work. If you push forward
the final release or the documentation it will be great for the project in
general but (as you certainly know) doesn't have any relevance for your GSoC
evaluation.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
[I comment on the release plan in the appropriately named thread.]
...
> Now, we have to decide what to do. I would be very happy to help with
> documentation but it means I would have to neglect my GSoC tasks. I have
> no problem with it because days without Cocoon's internals could be much
> brighter ;)
GSoC is your first priority. You are making good progress, don't let
some temporary frustration hinder you and diffuse your goals.
> However, investing my GSoC time into writing documentation seems to
> violate agreement with both Cocoon community and Google Summer of Code
> organizers. I made a promise to work on unification of Object Model and
> Expression handling to Cocoon community. Moreover, SoC has its own
> opinion on working on documentation[1]. Of course we could say that I've
> already contributed some code and it does not harms that much if I spend
> few days only on documentation. What's your opinion?
We cannot trade your GSoC scope for other tasks. That is not part of the
agreement, and I'm certain that you in the end would be disappointed on
your self if you did.
You have defined the scope and plan for the project and have to make
sure that you succeed with your goals. Of course, if the plan needs to
be revised to become relevant and/or reasonable, you can revise it and
we can discuss the new plan. If you need to revise it you should start
discussing that very soon. In the end it is your responsibility to
finish the scope that we have agreed on. Remember that it is much better
to have completed a small scope than to have "nearly finished" a much
larger scope.
Now, I have not the slightest interest in micro managing your work. If
you feel that you can spend some time on the 2.2 release without
endangering your GSoC task, feel free to do that. If not, focus on your
GSoC task.
/Daniel
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Peter Hunsberger <pe...@gmail.com>.
On 7/26/07, Carsten Ziegeler <cz...@apache.org> wrote:
> Grzegorz Kossakowski wrote:
> >
>
> Now all you really need are some more committers who would like to
> support this plan - and that's the really hard part. One indication of
> interest is the very low participation in this thread....
>
I can say +1 to everything you've discussed. However, I haven't had a
chance to try and build 2.2 recently since we're closing in on a
deadline for a huge project (3 years in development) at the end of the
month. It will be another month of bug shooting before I even get a
chance to sync up SVN on the dev branch again.
I bet a lot of other people are on vacation and doing summer type
stuff and just nnot paying a lot of attention to Cocoon at the
moment...
--
Peter Hunsberger
Re: Releasing Cocoon 2.2 final
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz pisze:
> Felix Knecht wrote:
>>> To that I would add a release plan:
>>>
>>> RC2 - in a week, this time with an anouncement (given that we have a
>>> willing release manager)
>
> Unfortunatly most likely I won't have time for a further release until
> the mid of September. I hope to find the time to publish the website
> next week and write the announcement mail for the RC1 but I can't even
> promise this. I'm sorry but that's all I can do at the moment.
Who else is capable of performing a release? Despite my GSoC work I cannot do it because I don't have my PGP key confirmed by others.
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Releasing Cocoon 2.2 final
Posted by Reinhard Poetz <re...@apache.org>.
Felix Knecht wrote:
>> To that I would add a release plan:
>>
>> RC2 - in a week, this time with an anouncement (given that we have a
>> willing release manager)
Unfortunatly most likely I won't have time for a further release until the mid
of September. I hope to find the time to publish the website next week and write
the announcement mail for the RC1 but I can't even promise this. I'm sorry but
that's all I can do at the moment.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Releasing Cocoon 2.2 final
Posted by Felix Knecht <fe...@apache.org>.
>
> To that I would add a release plan:
>
> RC2 - in a week, this time with an anouncement (given that we have a
> willing release manager)
> RC3 - a month after RC2
> 2.2 - a month after RC3
Definitely +1
I (even when I'm not a new user of cocoon, but I haven't fully followed
the migration to C22) managed with the existing docs to migrate
applications from C21 to C22.
Many parts of the C21 documentations are still usable for C22 or can
give at least good starting point for help.
>
> We can skip RC3 and go directly to 2.2 if we are in a hurry. The idea is
> that we release unconditionally as is on these dates. If we decide for a
> certain feature or piece of documentation we will continue to just wait
> for ever.
>
> OK, we could go for 2.2 directly without any RCs, I will not vote
> against it. But one or two RCs will give us some valuable user feedback
> and it will also increase the interest during a longer period.
I wonder if it wouldn't make sense to publish the existing documentation
to the productive area with the next RC to get more valuable user feedback.
How many user feedback we got after releasing RC1 and having the
documentation only on daisy's site and on cocoon.zones.apache.org? I
haven't seen much feedback about documentation on these sites.
I'm pretty sure this will not change when keeping the documentation on
these 'developer' sites.
Felix
Re: Releasing Cocoon 2.2 final
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom pisze:
> Grzegorz Kossakowski skrev:
>
> We just set an unconditional release date. If people are motivated to
> improve documentation that is fine. Otherwise we release with
> documentation as is. The only thing that is strictly necessary is that
> we publish the existing 2.2 documentation.
After revising our docs I can agree with you.
> To that I would add a release plan:
>
> RC2 - in a week, this time with an anouncement (given that we have a
> willing release manager)
> RC3 - a month after RC2
> 2.2 - a month after RC3
>
> We can skip RC3 and go directly to 2.2 if we are in a hurry. The idea is
> that we release unconditionally as is on these dates. If we decide for a
> certain feature or piece of documentation we will continue to just wait
> for ever.
>
> OK, we could go for 2.2 directly without any RCs, I will not vote
> against it. But one or two RCs will give us some valuable user feedback
> and it will also increase the interest during a longer period.
I think that RC2 will be enough. I have been playing with Cocoon for my hobby purposes and it seems to work ok. If there are some serious
problems (that are currently uknown) we can always make a new, fix release *after* releasing 2.2. Further testing does not give us much, IMO.
The only question remaining[1] is who will perform the release?
>
> I ignored the thread because I have no Internet on my sailing boat ;)
:-)
[1] http://article.gmane.org/gmane.text.xml.cocoon.devel/74337
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Releasing Cocoon 2.2 final
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Carsten Ziegeler pisze:
>> Grzegorz Kossakowski wrote:
>>> Do you remember that we have released RC1 but have not announced it yet?
>> Yes, so the release is actually worthless - releasing without anyone
>> telling is like writing a book and never publishing it.
>
> On the other hand, without docs such an announcement can spoil our hard
> work. Imagine flood of mails on user mailing list asking, where on the
> hell are docs for C2.2. We need something published.
Not everyone is going to start to use it at the same time and some
already has experience and can help others. Also real users and real
questions will show us what needs to improve and create motivation for
us to actually improve it.
>>> The only reason for this situation is that we don't have new site
>>> published yet. There is no documentation about C2.2 officially published
>>> so it's nonsense to announce it.
>> Yes, so why not just publish the docs and release? What are we *really*
>> waiting for? I really doubt that the documentation situation will get
>> better the longer we wait. So let's just use what is there - we will see
>> if it's sufficient or not.
>
> What we really waiting for? My own list is:
> 1. Creating docs (or at least one document) for cocoon-servlet-service.
> I assign this task to myself and I'm willing to provide some prototype
> *today*.
> 2. Structure adjustments. There are already some documents that are at
> wrong locations or are unreachable at all. It's really task for few
> hours of clicking around Daisy.
> 3. AFAIK, there are some infrastructure glitches but I don't know details.
>
> There is a document
> http://cocoon.zones.apache.org/daisy/cdocs/g4/1346.html describing the
> status of our documentation.
>
> My personal opinion is that if few folks started to work on docs right
> away, we could have it in shape within one or two days because really
> thin work is left.
>
> I hope that Reinhard can comment more on this.
We just set an unconditional release date. If people are motivated to
improve documentation that is fine. Otherwise we release with
documentation as is. The only thing that is strictly necessary is that
we publish the existing 2.2 documentation.
>>> <snip/>
>>> I'm speaking about it because I would like to release Cocoon 2.2 soon,
>>> too.
>> Once i had the dream that we could release 2.2 in 2005, then i had this
>> very realistic dream of releasing it by the end of 2006 - but in the end
>> these were all just dreams, so i stopped dreaming.
>
> Yes, I've seen these dreams. Cocoon has a long tradition of being unable
> to make releases timely. Currently, I'm very motivated to abandon this
> hurting-all-of-us tradition.
>
>>> Then my preference is to take following steps:
>>> 1. Release 2.1.11 and almost completely freeze 2.1.x branch. We could
>>> agree to allow only critical fixes to go there.
>> +1
>>
>>> 2. Release 2.2 version of core and 1.0 version of various blocks. Move
>>> cocoon-core:2.2 to maintenance branch and allow bug fixes and small
>>> improvements. Same for blocks released as 1.0.
>> +1
>>
>>> 3. We could start development of cocoon-core:2.3 in trunk. Blocks that
>>> would depend on cocoon-core:2.3 could be released as 1.1.0 because it's
>>> a major change to their dependency. Of course, if block is changed
>>> significantly in some other way than change in dependencies it would be
>>> released as 1.1.0 too.
>> +1
>>
>>> I also think that we could release cocoon-core:2.3 just after I finish
>>> changes to Object Model and Expression handling so people can benefit
>>> from it right away.
>> +1
+1 for the above.
To that I would add a release plan:
RC2 - in a week, this time with an anouncement (given that we have a
willing release manager)
RC3 - a month after RC2
2.2 - a month after RC3
We can skip RC3 and go directly to 2.2 if we are in a hurry. The idea is
that we release unconditionally as is on these dates. If we decide for a
certain feature or piece of documentation we will continue to just wait
for ever.
OK, we could go for 2.2 directly without any RCs, I will not vote
against it. But one or two RCs will give us some valuable user feedback
and it will also increase the interest during a longer period.
>> Now all you really need are some more committers who would like to
>> support this plan - and that's the really hard part. One indication of
>> interest is the very low participation in this thread....
>
> No matter how sad is it, you are right. I have nothing good to say about
> this situation. I only hope that people ignored this thread because of
> highly technical subject. I changed it hoping I'm right...
I ignored the thread because I have no Internet on my sailing boat ;)
/Daniel
Re: Releasing Cocoon 2.2 final
Posted by jo...@verona.se.
Grzegorz Kossakowski <gk...@apache.org> writes:
I'm working on a hobby project with Cocoon 2.2. I have previously
worked on comerial cocoon projects, but it was some time ago.
On returning, I dont think the documentation available now is all that
bad. There are, however, some holes that makes it difficult to get
started. I think you need user feedback to find these holes.
For instance, I spent quite some time yesterday trying to get a simple
cforms application working becaue of these reasons:
- It is not clear where to get forms-samples-styling.xsl
- it is not clear how to propagate the dojo uri to the styling xsl:s
- I failed to propagate a simple jx-flow list to a selectionlist
field( I still dont understand why)
(I followed the forms examples btw)
So to summarize, I think cocoon needs quite some more user feedback,
and the problems can then be fixed rather easily to improve perceived
quality a lot. Quality will not improve a lot at this point by trying
to guess what users will do when cocoon is released.
(also i had a problem with memory not being returned by the cache,
described in other thread)
> Carsten Ziegeler pisze:
>> Grzegorz Kossakowski wrote:
>>> Do you remember that we have released RC1 but have not announced it yet?
>> Yes, so the release is actually worthless - releasing without anyone
>> telling is like writing a book and never publishing it.
>
> On the other hand, without docs such an announcement can spoil our
> hard work. Imagine flood of mails on user mailing list asking, where
> on the hell are docs for C2.2. We need something published.
>
>>> The only reason for this situation is that we don't have new site
>>> published yet. There is no documentation about C2.2 officially published
>>> so it's nonsense to announce it.
>> Yes, so why not just publish the docs and release? What are we *really*
>> waiting for? I really doubt that the documentation situation will get
>> better the longer we wait. So let's just use what is there - we will see
>> if it's sufficient or not.
>
> What we really waiting for? My own list is:
> 1. Creating docs (or at least one document) for
> cocoon-servlet-service. I assign this task to myself and I'm willing
> to provide some prototype *today*.
> 2. Structure adjustments. There are already some documents that are at
> wrong locations or are unreachable at all. It's really task for few
> hours of clicking around Daisy.
> 3. AFAIK, there are some infrastructure glitches but I don't know details.
>
> There is a document http://cocoon.zones.apache.org/daisy/cdocs/g4/1346.html describing the status of our documentation.
>
> My personal opinion is that if few folks started to work on docs right
> away, we could have it in shape within one or two days because really
> thin work is left.
>
> I hope that Reinhard can comment more on this.
>
>>> <snip/>
>>> I'm speaking about it because I would like to release Cocoon 2.2 soon,
>>> too.
>> Once i had the dream that we could release 2.2 in 2005, then i had this
>> very realistic dream of releasing it by the end of 2006 - but in the end
>> these were all just dreams, so i stopped dreaming.
>
> Yes, I've seen these dreams. Cocoon has a long tradition of being
> unable to make releases timely. Currently, I'm very motivated to
> abandon this hurting-all-of-us tradition.
>
>>> Then my preference is to take following steps:
>>> 1. Release 2.1.11 and almost completely freeze 2.1.x branch. We could
>>> agree to allow only critical fixes to go there.
>> +1
>>
>>> 2. Release 2.2 version of core and 1.0 version of various blocks. Move
>>> cocoon-core:2.2 to maintenance branch and allow bug fixes and small
>>> improvements. Same for blocks released as 1.0.
>> +1
>>
>>> 3. We could start development of cocoon-core:2.3 in trunk. Blocks that
>>> would depend on cocoon-core:2.3 could be released as 1.1.0 because it's
>>> a major change to their dependency. Of course, if block is changed
>>> significantly in some other way than change in dependencies it would be
>>> released as 1.1.0 too.
>> +1
>>
>>> I also think that we could release cocoon-core:2.3 just after I finish
>>> changes to Object Model and Expression handling so people can benefit
>>> from it right away.
>> +1
>>
>> Now all you really need are some more committers who would like to
>> support this plan - and that's the really hard part. One indication of
>> interest is the very low participation in this thread....
>
> No matter how sad is it, you are right. I have nothing good to say
> about this situation. I only hope that people ignored this thread
> because of highly technical subject. I changed it hoping I'm right...
>
> --
> Grzegorz Kossakowski
> http://reflectingonthevicissitudes.wordpress.com/
--
Joakim Verona
Releasing Cocoon 2.2 final (was: Re: HttpServletRequest vs o.a.c.e.Request
saga continues)
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
> Grzegorz Kossakowski wrote:
>> Do you remember that we have released RC1 but have not announced it yet?
> Yes, so the release is actually worthless - releasing without anyone
> telling is like writing a book and never publishing it.
On the other hand, without docs such an announcement can spoil our hard work. Imagine flood of mails on user mailing list asking, where on
the hell are docs for C2.2. We need something published.
>> The only reason for this situation is that we don't have new site
>> published yet. There is no documentation about C2.2 officially published
>> so it's nonsense to announce it.
> Yes, so why not just publish the docs and release? What are we *really*
> waiting for? I really doubt that the documentation situation will get
> better the longer we wait. So let's just use what is there - we will see
> if it's sufficient or not.
What we really waiting for? My own list is:
1. Creating docs (or at least one document) for cocoon-servlet-service. I assign this task to myself and I'm willing to provide some
prototype *today*.
2. Structure adjustments. There are already some documents that are at wrong locations or are unreachable at all. It's really task for few
hours of clicking around Daisy.
3. AFAIK, there are some infrastructure glitches but I don't know details.
There is a document http://cocoon.zones.apache.org/daisy/cdocs/g4/1346.html describing the status of our documentation.
My personal opinion is that if few folks started to work on docs right away, we could have it in shape within one or two days because really
thin work is left.
I hope that Reinhard can comment more on this.
>> <snip/>
>> I'm speaking about it because I would like to release Cocoon 2.2 soon,
>> too.
> Once i had the dream that we could release 2.2 in 2005, then i had this
> very realistic dream of releasing it by the end of 2006 - but in the end
> these were all just dreams, so i stopped dreaming.
Yes, I've seen these dreams. Cocoon has a long tradition of being unable to make releases timely. Currently, I'm very motivated to abandon
this hurting-all-of-us tradition.
>> Then my preference is to take following steps:
>> 1. Release 2.1.11 and almost completely freeze 2.1.x branch. We could
>> agree to allow only critical fixes to go there.
> +1
>
>> 2. Release 2.2 version of core and 1.0 version of various blocks. Move
>> cocoon-core:2.2 to maintenance branch and allow bug fixes and small
>> improvements. Same for blocks released as 1.0.
> +1
>
>> 3. We could start development of cocoon-core:2.3 in trunk. Blocks that
>> would depend on cocoon-core:2.3 could be released as 1.1.0 because it's
>> a major change to their dependency. Of course, if block is changed
>> significantly in some other way than change in dependencies it would be
>> released as 1.1.0 too.
> +1
>
>> I also think that we could release cocoon-core:2.3 just after I finish
>> changes to Object Model and Expression handling so people can benefit
>> from it right away.
> +1
>
> Now all you really need are some more committers who would like to
> support this plan - and that's the really hard part. One indication of
> interest is the very low participation in this thread....
No matter how sad is it, you are right. I have nothing good to say about this situation. I only hope that people ignored this thread because
of highly technical subject. I changed it hoping I'm right...
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
>
> Do you remember that we have released RC1 but have not announced it yet?
Yes, so the release is actually worthless - releasing without anyone
telling is like writing a book and never publishing it.
> The only reason for this situation is that we don't have new site
> published yet. There is no documentation about C2.2 officially published
> so it's nonsense to announce it.
Yes, so why not just publish the docs and release? What are we *really*
waiting for? I really doubt that the documentation situation will get
better the longer we wait. So let's just use what is there - we will see
if it's sufficient or not.
> <snip/>
> I'm speaking about it because I would like to release Cocoon 2.2 soon,
> too.
Once i had the dream that we could release 2.2 in 2005, then i had this
very realistic dream of releasing it by the end of 2006 - but in the end
these were all just dreams, so i stopped dreaming.
> Then my preference is to take following steps:
> 1. Release 2.1.11 and almost completely freeze 2.1.x branch. We could
> agree to allow only critical fixes to go there.
+1
> 2. Release 2.2 version of core and 1.0 version of various blocks. Move
> cocoon-core:2.2 to maintenance branch and allow bug fixes and small
> improvements. Same for blocks released as 1.0.
+1
> 3. We could start development of cocoon-core:2.3 in trunk. Blocks that
> would depend on cocoon-core:2.3 could be released as 1.1.0 because it's
> a major change to their dependency. Of course, if block is changed
> significantly in some other way than change in dependencies it would be
> released as 1.1.0 too.
+1
>
> I also think that we could release cocoon-core:2.3 just after I finish
> changes to Object Model and Expression handling so people can benefit
> from it right away.
+1
Now all you really need are some more committers who would like to
support this plan - and that's the really hard part. One indication of
interest is the very low participation in this thread....
Carsten
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Carsten Ziegeler pisze:
>
> Ok, all this is definitly not optimal and it now pays back that we never
> paid enough attention when the various parts were developed by different
> people.
>
> I understand your frustration and I would opt for clearing everything up
> in your situation as well.
>
> I personally have no problems with breaking the contracts for 2.2 in
> some places if it makes sense. We changed already a lot of things, so
> why not changing some more? The question is do we loose users just
> because of this? I don't think so.
>
> BUT, there is still no final release of 2.2 and it's not even visible
> when this will happen. Such changes will create the nice and easy
> argument to delay the release further. I still would prefer to release
> 2.2 *today* (well today is not feasible, but let's say in the next 7
> days) and directly afterwards do this refactoring.
+10000.
>
> Not changing the environment abstraction is a mistake, but not releasing
> is imho a much bigger one.
Do you remember that we have released RC1 but have not announced it yet? The only reason for this situation is that we don't have new site
published yet. There is no documentation about C2.2 officially published so it's nonsense to announce it.
Now, we have to decide what to do. I would be very happy to help with documentation but it means I would have to neglect my GSoC tasks. I
have no problem with it because days without Cocoon's internals could be much brighter ;)
However, investing my GSoC time into writing documentation seems to violate agreement with both Cocoon community and Google Summer of Code
organizers. I made a promise to work on unification of Object Model and Expression handling to Cocoon community. Moreover, SoC has its own
opinion on working on documentation[1]. Of course we could say that I've already contributed some code and it does not harms that much if I
spend few days only on documentation. What's your opinion?
I'm speaking about it because I would like to release Cocoon 2.2 soon, too. Then my preference is to take following steps:
1. Release 2.1.11 and almost completely freeze 2.1.x branch. We could agree to allow only critical fixes to go there.
2. Release 2.2 version of core and 1.0 version of various blocks. Move cocoon-core:2.2 to maintenance branch and allow bug fixes and
small improvements. Same for blocks released as 1.0.
3. We could start development of cocoon-core:2.3 in trunk. Blocks that would depend on cocoon-core:2.3 could be released as 1.1.0 because
it's a major change to their dependency. Of course, if block is changed significantly in some other way than change in dependencies it would
be released as 1.1.0 too.
I also think that we could release cocoon-core:2.3 just after I finish changes to Object Model and Expression handling so people can benefit
from it right away.
WDYT?
[1] http://code.google.com/support/bin/answer.py?answer=60315&topic=10727
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: HttpServletRequest vs o.a.c.e.Request saga continues
Posted by Carsten Ziegeler <cz...@apache.org>.
Grzegorz Kossakowski wrote:
> Hi guys,
>
> <SNIP/>
>
> This lists could be much longer. This lists make me sick because it was
> never as much painful to develop something Cocoon-related as this GSoC
> work. I was prepared to some obstacles, world is not perfect, I knew
> that our internals are far from perfection. Now I know that they are
> fucking crazy, period.
>
:)
Ok, all this is definitly not optimal and it now pays back that we never
paid enough attention when the various parts were developed by different
people.
I understand your frustration and I would opt for clearing everything up
in your situation as well.
I personally have no problems with breaking the contracts for 2.2 in
some places if it makes sense. We changed already a lot of things, so
why not changing some more? The question is do we loose users just
because of this? I don't think so.
BUT, there is still no final release of 2.2 and it's not even visible
when this will happen. Such changes will create the nice and easy
argument to delay the release further. I still would prefer to release
2.2 *today* (well today is not feasible, but let's say in the next 7
days) and directly afterwards do this refactoring.
Not changing the environment abstraction is a mistake, but not releasing
is imho a much bigger one.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org