You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@apache.org> on 2005/10/10 09:49:07 UTC
Releasing 2.1.8
We wanted to release 2.1.8 as soon as possible after the GT.
Now the question is, are there any open issues?
I'm currently aware of two problems:
1) Documentation - 2.1.8 does not contain the docs anymore, so we should
find a way to add them in the distribution. I think a directory
containing just the html docs (or pdf?) should be fine.
In addition I think we should remove the targets for adding the docs
and the api docs to the webapp.
2) Logging of exceptions - currently correct stacktraces are tied to our
own logkit formatter (if I'm not mistaken), so as soon as you're not
using logkit or not using this formatter, you don't get the correct
stacktraces.
Is there anything else?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* Jorg Heymans:
>
> Jean-Baptiste Quenot wrote:
>
> > Bug 36907 Missing dependency on commons-beanutils
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=36907
>
> isn't this fixed by r314825 from yesterday by Bruno ?
Yes, thank you.
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
Re: Releasing 2.1.8
Posted by Jorg Heymans <jh...@domek.be>.
Jean-Baptiste Quenot wrote:
> Bug 36907 Missing dependency on commons-beanutils
> http://issues.apache.org/bugzilla/show_bug.cgi?id=36907
isn't this fixed by r314825 from yesterday by Bruno ?
Jorg
Re: Releasing 2.1.8
Posted by Jean-Baptiste Quenot <jb...@anyware-tech.com>.
* Carsten Ziegeler:
> Is there anything else?
Yes, the four following issues are critical before releasing:
Bug 36462 JXPath expressions within <jx:forEach> are broken
http://issues.apache.org/bugzilla/show_bug.cgi?id=36462
Bug 36907 Missing dependency on commons-beanutils
http://issues.apache.org/bugzilla/show_bug.cgi?id=36907
Bug 36949 [PATCH] SendMailTransformer and HTML body
http://issues.apache.org/bugzilla/show_bug.cgi?id=36949
Bug 37049 Calling SitemapSource.getInputStream() twice
http://issues.apache.org/bugzilla/show_bug.cgi?id=37049
Otherwise, I'd be glad to see these simple patches applied:
Bug 36371 [PATCH] Improve WebDAVSource error messages
http://issues.apache.org/bugzilla/show_bug.cgi?id=36371
Bug 36686 [PATCH] Add method makeCollection() in XMLDBSource
http://issues.apache.org/bugzilla/show_bug.cgi?id=36686
Thanks in advance,
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Vadim Gritsenko wrote:
> Leszek Gawron wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> making the "include.block = true" overload "exclude.block.all = true"
>>> would go a long way to make things easier for users, IMO and should
>>> not but such a big change.
>>
>>
>> want it - got it.
>> check the trunk - if it's ok - I'll port it back to 2.1.
>
>
> Wow! It worked!
Yep, it amazes me how short change that was (and now relatively huge
amount of time I spent because of Ant's approach to properties and
conditionals).
>
>> one simple gotcha:
>> if there is a conflict on the same level of granularity:
>>
>> include.block.template=true vs. exclude.block.template=true,
>> include.all.blocks=true vs. exclude.all.blocks=true
>>
>> it is always resolved in favour of include.* properties.
>
>
> Above is short enough - can be documented in blocks.properties itself.
>
> Vadim
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Leszek Gawron wrote:
> Stefano Mazzocchi wrote:
>
>> making the "include.block = true" overload "exclude.block.all = true"
>> would go a long way to make things easier for users, IMO and should
>> not but such a big change.
>
> want it - got it.
> check the trunk - if it's ok - I'll port it back to 2.1.
Wow! It worked!
> one simple gotcha:
> if there is a conflict on the same level of granularity:
>
> include.block.template=true vs. exclude.block.template=true,
> include.all.blocks=true vs. exclude.all.blocks=true
>
> it is always resolved in favour of include.* properties.
Above is short enough - can be documented in blocks.properties itself.
Vadim
Re: Releasing 2.1.8
Posted by Jorg Heymans <jh...@domek.be>.
Leszek Gawron wrote:
>
> Slightly OT: why don't we make eclipse-customized-project a default
> target for eclipse IDE? Since eclipse-customized-project was introduced
> this is the only one I use.
makes sense yes, +1
Jorg
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Leszek Gawron wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> The thing is eclipse-project and eclipse-customized-project were out
>>>> of sync (doing different things regardles of being
>>>> inclusion/exclusion aware)
>>>>
>>>> how about:
>>>>
>>>> build -Dinclude.all.blocks=true eclipse-project
>>>>
>>>
>>> I assume that include has precedence over exclude, right? Then I'm fine
>>> with the solution.
>>
>>
>> exactly
>
> one thing:
>
> this will work for:
>
> exclude.all.blocks=true
> include.block.template=true
> include.block.forms=true
>
> because -Dinclude.all.blocks=true will override exclude.all.blocks=true
>
> still -Dinclude.all.blocks=true does not override an explicit
> exclude.block.something=true so this could work:
>
> include.all.blocks=true
> exclude.block.theOnlyOneIDoNotUse=true
>
> If this is a problem for you I can some up with
> unconditional.include.all.blocks=true which will disregard
> exclude.block.theOnlyOneIDoNotUse=true.
>
> This variable could be honoured only in build eclipse-project as I do
> not see any sense to add it to standard build.
>
Hate to correct myself. Unfortunately this will not work for explicit
include.block.something=false. I have introduced following syntax:
build eclipse-project
build eclipse-customized-project
both honour local.blocks.properties
you also have
build full-eclipse-project which does the following:
<target name="init-eclipse-full-project">
<property name="unconditional.include.all.blocks" value="true"/>
</target>
<target name="full-eclipse-project"
depends="init-eclipse-full-project, eclipse-project"/>
so we have a single generation code and the power of previous solution.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Carsten Ziegeler wrote:
>
>> Leszek Gawron wrote:
>>
>>> The thing is eclipse-project and eclipse-customized-project were out
>>> of sync (doing different things regardles of being
>>> inclusion/exclusion aware)
>>>
>>> how about:
>>>
>>> build -Dinclude.all.blocks=true eclipse-project
>>>
>>
>> I assume that include has precedence over exclude, right? Then I'm fine
>> with the solution.
>
> exactly
one thing:
this will work for:
exclude.all.blocks=true
include.block.template=true
include.block.forms=true
because -Dinclude.all.blocks=true will override exclude.all.blocks=true
still -Dinclude.all.blocks=true does not override an explicit
exclude.block.something=true so this could work:
include.all.blocks=true
exclude.block.theOnlyOneIDoNotUse=true
If this is a problem for you I can some up with
unconditional.include.all.blocks=true which will disregard
exclude.block.theOnlyOneIDoNotUse=true.
This variable could be honoured only in build eclipse-project as I do
not see any sense to add it to standard build.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>
>>The thing is eclipse-project and eclipse-customized-project were out of
>>sync (doing different things regardles of being inclusion/exclusion aware)
>>
>>how about:
>>
>>build -Dinclude.all.blocks=true eclipse-project
>>
>
> I assume that include has precedence over exclude, right? Then I'm fine
> with the solution.
exactly
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
>
> The thing is eclipse-project and eclipse-customized-project were out of
> sync (doing different things regardles of being inclusion/exclusion aware)
>
> how about:
>
> build -Dinclude.all.blocks=true eclipse-project
>
I assume that include has precedence over exclude, right? Then I'm fine
with the solution.
> That should make you happy.
>
Yepp.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>
>
>>I will remove the standard eclipse-project (It also seems outdated
>>comparing to eclipse-customized-project). eclipse-customized-project has
>>all the functionality of the former one so this should be no problem for
>>anyone.
>>
>
> Please don't - I'm using the project to always get *all* blocks in
> eclipse regardless what I'm using for the build. Please just rename it.
The thing is eclipse-project and eclipse-customized-project were out of
sync (doing different things regardles of being inclusion/exclusion aware)
how about:
build -Dinclude.all.blocks=true eclipse-project
That should make you happy.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Carsten Ziegeler <cz...@apache.org>.
Leszek Gawron wrote:
>
> I will remove the standard eclipse-project (It also seems outdated
> comparing to eclipse-customized-project). eclipse-customized-project has
> all the functionality of the former one so this should be no problem for
> anyone.
>
Please don't - I'm using the project to always get *all* blocks in
eclipse regardless what I'm using for the build. Please just rename it.
Thanks
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8
Posted by Antonio Gallardo <ag...@agssa.net>.
Leszek Gawron wrote:
> Reinhard Poetz wrote:
>
>> Antonio Gallardo wrote:
>>
>>> Sorry for the long name. I was unable to find quickly a better name.
>>> ;-)
>>>
>>> Seriously, since the long name for customized eclipse build seems to
>>> be used only by you and me, then I think we can also deprecate it
>>> now and remove it in 2.2.
>>>
>>> WDYT?
>>
>>
>>
>> I've been using it since day one it exists. If people don't
>> participate in a discussion doesn't mean that they don't use the
>> discussed stuff ;-)
>>
> As the code behind eclipse-customized-project was moved over to
> eclipse-project target we can easily show a deprecation message when
> eclipse-customized-project is used:
>
<echo>
> ** The eclipse builds have been unified. Plase use eclipse-project or
> full-eclipse-project target from now on. **
</echo>
+1
;-)
Best Regards,
Antonio Gallardo.
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Reinhard Poetz wrote:
> Antonio Gallardo wrote:
>
>> Sorry for the long name. I was unable to find quickly a better name. ;-)
>>
>> Seriously, since the long name for customized eclipse build seems to
>> be used only by you and me, then I think we can also deprecate it now
>> and remove it in 2.2.
>>
>> WDYT?
>
>
> I've been using it since day one it exists. If people don't participate
> in a discussion doesn't mean that they don't use the discussed stuff ;-)
>
As the code behind eclipse-customized-project was moved over to
eclipse-project target we can easily show a deprecation message when
eclipse-customized-project is used:
** The eclipse builds have been unified. Plase use eclipse-project or
full-eclipse-project target from now on. **
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Reinhard Poetz <re...@apache.org>.
Antonio Gallardo wrote:
> Sorry for the long name. I was unable to find quickly a better name. ;-)
>
> Seriously, since the long name for customized eclipse build seems to be
> used only by you and me, then I think we can also deprecate it now and
> remove it in 2.2.
>
> WDYT?
I've been using it since day one it exists. If people don't participate in a
discussion doesn't mean that they don't use the discussed stuff ;-)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Releasing 2.1.8
Posted by Antonio Gallardo <ag...@agssa.net>.
Leszek Gawron wrote:
> Upayavira wrote:
>
>> Leszek Gawron wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> Jorg Heymans wrote:
>>>>
>>>>> Leszek Gawron wrote:
>>>>>
>>>>>> want it - got it.
>>>>>> check the trunk - if it's ok - I'll port it back to 2.1.
>>>>>>
>>>>>
>>>>>
>>>>> I don't have time to check myself, but are these new properties
>>>>> respected by the eclipse-customized-project target ?
>>>>
>>>>
>>>>
>>>>
>>>> They should but ... to tell you the truth I do not know. I will
>>>> check that.
>>>>
>>>> Slightly OT: why don't we make eclipse-customized-project a default
>>>> target for eclipse IDE? Since eclipse-customized-project was
>>>> introduced this is the only one I use.
>>>
>>>
>>>
>>> I will remove the standard eclipse-project (It also seems outdated
>>> comparing to eclipse-customized-project). eclipse-customized-project
>>> has all the functionality of the former one so this should be no
>>> problem for anyone.
>>
>>
>>
>> But what happens now if someone runs the old eclipse-project? Does it
>> output an error saying to use eclipse-customized-project and what has
>> changed? Or does it just say "no such target"?
>
>
> <!-- for those who like long names.. -->
> <target name="eclipse-customized-project" depends="eclipse-project"/>
Sorry for the long name. I was unable to find quickly a better name. ;-)
Seriously, since the long name for customized eclipse build seems to be
used only by you and me, then I think we can also deprecate it now and
remove it in 2.2.
WDYT?
Best Regards,
Antonio Gallardo
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Upayavira wrote:
> Leszek Gawron wrote:
>
>> Leszek Gawron wrote:
>>
>>> Jorg Heymans wrote:
>>>
>>>> Leszek Gawron wrote:
>>>>
>>>>> want it - got it.
>>>>> check the trunk - if it's ok - I'll port it back to 2.1.
>>>>>
>>>>
>>>>
>>>> I don't have time to check myself, but are these new properties
>>>> respected by the eclipse-customized-project target ?
>>>
>>>
>>>
>>> They should but ... to tell you the truth I do not know. I will check
>>> that.
>>>
>>> Slightly OT: why don't we make eclipse-customized-project a default
>>> target for eclipse IDE? Since eclipse-customized-project was
>>> introduced this is the only one I use.
>>
>>
>> I will remove the standard eclipse-project (It also seems outdated
>> comparing to eclipse-customized-project). eclipse-customized-project
>> has all the functionality of the former one so this should be no
>> problem for anyone.
>
>
> But what happens now if someone runs the old eclipse-project? Does it
> output an error saying to use eclipse-customized-project and what has
> changed? Or does it just say "no such target"?
<!-- for those who like long names.. -->
<target name="eclipse-customized-project" depends="eclipse-project"/>
<!-- Build the Eclipse customized project's files -->
<target name="eclipse-project" description="Generate the Eclipse
customized project files (using local.block.properties)">
<echo message="Building Eclipse Customized Project Files"/>
<xslt in="${gump.descriptor}"
out="${build.temp}/blocks-eclipse.xml"
style="${tools}/ide/eclipse/blocks-classpath.xsl"/>
<ant antfile="${build.temp}/blocks-eclipse.xml"
inheritAll="true"
inheritRefs="false"
target="generate-customized-eclipse-project"/>
</target>
both targets point to the same one so noone gets nasty error.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Upayavira <uv...@odoko.co.uk>.
Leszek Gawron wrote:
> Leszek Gawron wrote:
>
>> Jorg Heymans wrote:
>>
>>> Leszek Gawron wrote:
>>>
>>>> want it - got it.
>>>> check the trunk - if it's ok - I'll port it back to 2.1.
>>>>
>>>
>>>
>>> I don't have time to check myself, but are these new properties
>>> respected by the eclipse-customized-project target ?
>>
>>
>> They should but ... to tell you the truth I do not know. I will check
>> that.
>>
>> Slightly OT: why don't we make eclipse-customized-project a default
>> target for eclipse IDE? Since eclipse-customized-project was
>> introduced this is the only one I use.
>
> I will remove the standard eclipse-project (It also seems outdated
> comparing to eclipse-customized-project). eclipse-customized-project has
> all the functionality of the former one so this should be no problem for
> anyone.
But what happens now if someone runs the old eclipse-project? Does it
output an error saying to use eclipse-customized-project and what has
changed? Or does it just say "no such target"?
Upayavira
Re: Releasing 2.1.8
Posted by Jorg Heymans <jh...@domek.be>.
Leszek Gawron wrote:
> I will remove the standard eclipse-project (It also seems outdated
> comparing to eclipse-customized-project). eclipse-customized-project has
> all the functionality of the former one so this should be no problem for
as the standard eclipse-project is more known, why not keep that one and
just rename eclipse-customized-project instead ?
Jorg
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Leszek Gawron wrote:
> Jorg Heymans wrote:
>
>> Leszek Gawron wrote:
>>
>>> want it - got it.
>>> check the trunk - if it's ok - I'll port it back to 2.1.
>>>
>>
>>
>> I don't have time to check myself, but are these new properties
>> respected by the eclipse-customized-project target ?
>
> They should but ... to tell you the truth I do not know. I will check that.
>
> Slightly OT: why don't we make eclipse-customized-project a default
> target for eclipse IDE? Since eclipse-customized-project was introduced
> this is the only one I use.
I will remove the standard eclipse-project (It also seems outdated
comparing to eclipse-customized-project). eclipse-customized-project has
all the functionality of the former one so this should be no problem for
anyone.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jorg Heymans wrote:
> Leszek Gawron wrote:
>
>>want it - got it.
>>check the trunk - if it's ok - I'll port it back to 2.1.
>>
>
>
> I don't have time to check myself, but are these new properties
> respected by the eclipse-customized-project target ?
They should but ... to tell you the truth I do not know. I will check that.
Slightly OT: why don't we make eclipse-customized-project a default
target for eclipse IDE? Since eclipse-customized-project was introduced
this is the only one I use.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jorg Heymans wrote:
> Leszek Gawron wrote:
>
>>want it - got it.
>>check the trunk - if it's ok - I'll port it back to 2.1.
>>
>
>
> I don't have time to check myself, but are these new properties
> respected by the eclipse-customized-project target ?
Unfortunately it does not - I'll look into that.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jorg Heymans wrote:
> Leszek Gawron wrote:
>
>>want it - got it (I will (tm) this ! :))
>>
>
> mighty cool, thanks Leszek !
>
> So what about those 300 outstanding bugzilla issues :P
Hmmm you know ... I do impossible things in no time. Still you'll have
to wait a little bit for miracles.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Antonio Gallardo <ag...@agssa.net>.
Jorg Heymans wrote:
>Leszek Gawron wrote:
>
>
>>want it - got it (I will (tm) this ! :))
>>
>>
>>
>mighty cool, thanks Leszek !
>
>So what about those 300 outstanding bugzilla issues :P
>
>
lol. :-D Jorg, are you now committer, then you can get them only for
you! ;-)
Best Regards,
Antonio Gallardo.
>
>
>
>
Re: Releasing 2.1.8
Posted by Jorg Heymans <jh...@domek.be>.
Leszek Gawron wrote:
>
> want it - got it (I will (tm) this ! :))
>
mighty cool, thanks Leszek !
So what about those 300 outstanding bugzilla issues :P
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Jorg Heymans wrote:
> Leszek Gawron wrote:
>
>>want it - got it.
>>check the trunk - if it's ok - I'll port it back to 2.1.
>>
>
>
> I don't have time to check myself, but are these new properties
> respected by the eclipse-customized-project target ?
want it - got it (I will (tm) this ! :))
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Jorg Heymans <jh...@domek.be>.
Leszek Gawron wrote:
>>
> want it - got it.
> check the trunk - if it's ok - I'll port it back to 2.1.
>
I don't have time to check myself, but are these new properties
respected by the eclipse-customized-project target ?
Jorg
Re: Releasing 2.1.8
Posted by Stefano Mazzocchi <st...@apache.org>.
Leszek Gawron wrote:
> I do not understand... No plate then ? :)
Oh, no, you got it :-)
--
Stefano.
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Stefano Mazzocchi wrote:
> Leszek Gawron wrote:
>
>> Stefano Mazzocchi wrote:
>>
>>> Carsten Ziegeler wrote:
>>>
>>>> We wanted to release 2.1.8 as soon as possible after the GT.
>>>> Now the question is, are there any open issues?
>>>>
>>>> I'm currently aware of two problems:
>>>> 1) Documentation - 2.1.8 does not contain the docs anymore, so we
>>>> should
>>>> find a way to add them in the distribution. I think a directory
>>>> containing just the html docs (or pdf?) should be fine.
>>>> In addition I think we should remove the targets for adding the docs
>>>> and the api docs to the webapp.
>>>>
>>>> 2) Logging of exceptions - currently correct stacktraces are tied to
>>>> our
>>>> own logkit formatter (if I'm not mistaken), so as soon as you're not
>>>> using logkit or not using this formatter, you don't get the correct
>>>> stacktraces.
>>>>
>>>> Is there anything else?
>>>
>>>
>>>
>>>
>>> making the "include.block = true" overload "exclude.block.all = true"
>>> would go a long way to make things easier for users, IMO and should
>>> not but such a big change.
>>>
>> want it - got it.
>
>
> Stefano's Hero Plate of October goes to Leszek :-)
Wow, I'm honoured! Thank you.
>> check the trunk - if it's ok - I'll port it back to 2.1.
>
>
> Sorry, should have read this first.
I do not understand... No plate then ? :)
> I looked at the code and should be ok, I say move it to 2.1.x already.
done it. have fun.
>
>> one simple gotcha:
>> if there is a conflict on the same level of granularity:
>>
>> include.block.template=true vs. exclude.block.template=true,
>> include.all.blocks=true vs. exclude.all.blocks=true
>>
>> it is always resolved in favour of include.* properties.
>
>
> Yeah, makes perfect sense.
>
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Stefano Mazzocchi <st...@apache.org>.
Leszek Gawron wrote:
> Stefano Mazzocchi wrote:
>
>> Carsten Ziegeler wrote:
>>
>>> We wanted to release 2.1.8 as soon as possible after the GT.
>>> Now the question is, are there any open issues?
>>>
>>> I'm currently aware of two problems:
>>> 1) Documentation - 2.1.8 does not contain the docs anymore, so we should
>>> find a way to add them in the distribution. I think a directory
>>> containing just the html docs (or pdf?) should be fine.
>>> In addition I think we should remove the targets for adding the docs
>>> and the api docs to the webapp.
>>>
>>> 2) Logging of exceptions - currently correct stacktraces are tied to our
>>> own logkit formatter (if I'm not mistaken), so as soon as you're not
>>> using logkit or not using this formatter, you don't get the correct
>>> stacktraces.
>>>
>>> Is there anything else?
>>
>>
>>
>> making the "include.block = true" overload "exclude.block.all = true"
>> would go a long way to make things easier for users, IMO and should
>> not but such a big change.
>>
> want it - got it.
Stefano's Hero Plate of October goes to Leszek :-)
> check the trunk - if it's ok - I'll port it back to 2.1.
Sorry, should have read this first.
I looked at the code and should be ok, I say move it to 2.1.x already.
> one simple gotcha:
> if there is a conflict on the same level of granularity:
>
> include.block.template=true vs. exclude.block.template=true,
> include.all.blocks=true vs. exclude.all.blocks=true
>
> it is always resolved in favour of include.* properties.
Yeah, makes perfect sense.
--
Stefano.
Re: Releasing 2.1.8
Posted by Leszek Gawron <lg...@mobilebox.pl>.
Stefano Mazzocchi wrote:
> Carsten Ziegeler wrote:
>
>> We wanted to release 2.1.8 as soon as possible after the GT.
>> Now the question is, are there any open issues?
>>
>> I'm currently aware of two problems:
>> 1) Documentation - 2.1.8 does not contain the docs anymore, so we should
>> find a way to add them in the distribution. I think a directory
>> containing just the html docs (or pdf?) should be fine.
>> In addition I think we should remove the targets for adding the docs
>> and the api docs to the webapp.
>>
>> 2) Logging of exceptions - currently correct stacktraces are tied to our
>> own logkit formatter (if I'm not mistaken), so as soon as you're not
>> using logkit or not using this formatter, you don't get the correct
>> stacktraces.
>>
>> Is there anything else?
>
>
> making the "include.block = true" overload "exclude.block.all = true"
> would go a long way to make things easier for users, IMO and should not
> but such a big change.
>
want it - got it.
check the trunk - if it's ok - I'll port it back to 2.1.
one simple gotcha:
if there is a conflict on the same level of granularity:
include.block.template=true vs. exclude.block.template=true,
include.all.blocks=true vs. exclude.all.blocks=true
it is always resolved in favour of include.* properties.
--
Leszek Gawron lgawron@mobilebox.pl
IT Manager MobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Releasing 2.1.8
Posted by Stefano Mazzocchi <st...@apache.org>.
Carsten Ziegeler wrote:
> We wanted to release 2.1.8 as soon as possible after the GT.
> Now the question is, are there any open issues?
>
> I'm currently aware of two problems:
> 1) Documentation - 2.1.8 does not contain the docs anymore, so we should
> find a way to add them in the distribution. I think a directory
> containing just the html docs (or pdf?) should be fine.
> In addition I think we should remove the targets for adding the docs
> and the api docs to the webapp.
>
> 2) Logging of exceptions - currently correct stacktraces are tied to our
> own logkit formatter (if I'm not mistaken), so as soon as you're not
> using logkit or not using this formatter, you don't get the correct
> stacktraces.
>
> Is there anything else?
making the "include.block = true" overload "exclude.block.all = true"
would go a long way to make things easier for users, IMO and should not
but such a big change.
--
Stefano.
Re: Releasing 2.1.8
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>2) Logging of exceptions - currently correct stacktraces are tied to our
>>> own logkit formatter (if I'm not mistaken), so as soon as you're not
>>> using logkit or not using this formatter, you don't get the correct
>>> stacktraces.
>>
>>This problem only happens in places where we wrap an exception in a
>>SAXException and log that SAXException. This is because SAXException
>>doesn't provide the getCause() method that's used by JDK 1.4's exception
>>chaining.
>>
>>However, if the exception is wrapped in e.g. a ProcessingException, the
>>problem doesn't exist.
>>
>>A solution to this problem is to define our own "class XMLException
>>extends SAXException" that will provide this getCause() and change all
>>"throw new SAXException()" in our code with "throw new XMLException".
>
> If it solves the problem, well fine :) But I'm wondering if this is
> necessary as
> it worked in 2.1.7.
IMHO, this could be fixed by using
return ExceptionUtils.getFullStackTrace(throwable);
instead of
return ExceptionUtils.getStackTrace(throwable);
Vadim
Re: Releasing 2.1.8
Posted by Carsten Ziegeler <cz...@apache.org>.
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
>
>>We wanted to release 2.1.8 as soon as possible after the GT.
>>Now the question is, are there any open issues?
>>
>>I'm currently aware of two problems:
>>1) Documentation - 2.1.8 does not contain the docs anymore, so we should
>> find a way to add them in the distribution. I think a directory
>> containing just the html docs (or pdf?) should be fine.
>> In addition I think we should remove the targets for adding the docs
>> and the api docs to the webapp.
>>
>>2) Logging of exceptions - currently correct stacktraces are tied to our
>> own logkit formatter (if I'm not mistaken), so as soon as you're not
>> using logkit or not using this formatter, you don't get the correct
>> stacktraces.
>>
>>
>
>
> This problem only happens in places where we wrap an exception in a
> SAXException and log that SAXException. This is because SAXException
> doesn't provide the getCause() method that's used by JDK 1.4's exception
> chaining.
>
> However, if the exception is wrapped in e.g. a ProcessingException, the
> problem doesn't exist.
>
> A solution to this problem is to define our own "class XMLException
> extends SAXException" that will provide this getCause() and change all
> "throw new SAXException()" in our code with "throw new XMLException".
>
If it solves the problem, well fine :) But I'm wondering if this is
necessary as
it worked in 2.1.7.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8
Posted by Sylvain Wallez <sy...@apache.org>.
Carsten Ziegeler wrote:
>We wanted to release 2.1.8 as soon as possible after the GT.
>Now the question is, are there any open issues?
>
>I'm currently aware of two problems:
>1) Documentation - 2.1.8 does not contain the docs anymore, so we should
> find a way to add them in the distribution. I think a directory
> containing just the html docs (or pdf?) should be fine.
> In addition I think we should remove the targets for adding the docs
> and the api docs to the webapp.
>
>2) Logging of exceptions - currently correct stacktraces are tied to our
> own logkit formatter (if I'm not mistaken), so as soon as you're not
> using logkit or not using this formatter, you don't get the correct
> stacktraces.
>
>
This problem only happens in places where we wrap an exception in a
SAXException and log that SAXException. This is because SAXException
doesn't provide the getCause() method that's used by JDK 1.4's exception
chaining.
However, if the exception is wrapped in e.g. a ProcessingException, the
problem doesn't exist.
A solution to this problem is to define our own "class XMLException
extends SAXException" that will provide this getCause() and change all
"throw new SAXException()" in our code with "throw new XMLException".
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Releasing 2.1.8
Posted by Andrew Savory <an...@luminas.co.uk>.
Hi,
On 10 Oct 2005, at 08:49, Carsten Ziegeler wrote:
> Is there anything else?
This one effectively means SQL Transformer is unusable in combination
with sitemap parameters: http://issues.apache.org/bugzilla/
show_bug.cgi?id=36573
I didn't get to fix it at the hackathon :-(
Andrew.
--
Andrew Savory, Managing Director, Luminas Limited
Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135
Web: http://www.luminas.co.uk/
Orixo alliance: http://www.orixo.com/
Bug 32762 (was Re: Releasing 2.1.8)
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Oct 21, 2005, at 8:43 AM, Sylvain Wallez wrote:
> <snip>
I just pasted your comments into the bug and will follow up there. Now
I am thinking I probably should have just left it here, since I think
Jörg and I went through all this before (see the comments to that bug),
but what's done's done :-)...
—ml—
Re: Releasing 2.1.8
Posted by Sylvain Wallez <sy...@apache.org>.
Mark Lundquist wrote:
>
> On Oct 10, 2005, at 12:49 AM, Carsten Ziegeler wrote:
>
>> We wanted to release 2.1.8 as soon as possible after the GT.
>> Now the question is, are there any open issues?
>
> I know it's just a little thing, but then I could stop maintaining
> this local patch... any chance of getting this committed into 2.1.8?:
> http://issues.apache.org/bugzilla/show_bug.cgi?id=32762
IMO we don't even need complicated URL-scheme checking machinery, as by
definition cocoon.sendPage() calls a pipeline, which translates to
redirecting to a "cocoon:" URL.
So we may (but why?) want to allow people to explicitely write the full
URL in their flowscript, but then we just have to check if the given URL
starts with "cocoon:/" to avoid prepending the prefix twice.
So the code would simply be:
forwardTo(String uri...) {
if (!uri.startsWith("cocoon:/")) {
uri = "cocoon:/" + uri;
}
etc...
Thoughts?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
Re: Releasing 2.1.8
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Oct 10, 2005, at 12:49 AM, Carsten Ziegeler wrote:
> We wanted to release 2.1.8 as soon as possible after the GT.
> Now the question is, are there any open issues?
I know it's just a little thing, but then I could stop maintaining
this local patch... any chance of getting this committed into 2.1.8?:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32762
thx,
—ml—
Re: Releasing 2.1.8
Posted by hepabolu <he...@gmail.com>.
> The simpler alternative would be a wget of the docs on cocoon.apache.org.
>
> My argument would be that there's no bad thing keeping the new docs
> system for 2.2.
>
> Helma, are there any glaring mistakes in the currently live docs?
The updates that have been put into the xdocs/Daisy are not in the live
docs and the FAQ is empty.
Also, some javadoc extraction process has resulted in a few duplicates
of sitemap components where one of them points to minor information and
the other results in a 404.
I've already added FAQ to Daisy, so going the Daisy book route and
getting the PDF and/or HTML will in any case result in all the
documentation you would expect from the navigation bar on the site.
OTOH: a few pages that I could not find in the obvious place in the xdoc
directory of the repository are included as a link in Daisy.
These pages are:
under section "Status"
- changes
- todo
most of section "Community" and "Project" and "Links". Most of these are
external links anyway and are thus repeated.
So my take on this would be: include the Daisy book PDF and/or HTML and
make sure that the few pages that are not included (i.e. those described
above), are still available on the web, and updated if necessary.
As a user I'd rather see updated documentation that is completely
different from the previous release than the current crippled version
that has the familiar look.
Bye, Helma
Re: Releasing 2.1.8
Posted by Upayavira <uv...@odoko.co.uk>.
hepabolu wrote:
> Carsten Ziegeler wrote:
>
>> We wanted to release 2.1.8 as soon as possible after the GT.
>> Now the question is, are there any open issues?
>>
>> I'm currently aware of two problems:
>> 1) Documentation - 2.1.8 does not contain the docs anymore, so we should
>> find a way to add them in the distribution. I think a directory
>> containing just the html docs (or pdf?) should be fine.
>> In addition I think we should remove the targets for adding the docs
>> and the api docs to the webapp.
>
>
> * As a temporary substitute we could indeed provide the
> - PDF: simple, because 1 file to extract and include in docs dir.
> - HTML: less simple, because it's a bunch of files, I could ask Bruno
> what the best way to do this is.
>
> I'd do the PDF in any case, since it's so easy. HTML is probably not
> necessary then.
>
> * removal of doc building tags is ok.
> * api docs building tags should be left in as that is not addressed in
> Daisy.
>
> Note that, although 80% - 90% of the "legacy" docs is currently in
> Daisy, there are some smaller parts missing, a.o. the snippets. And for
> some parts of the docs (those not yet removed from the repository) I
> have to check if they have been updated since the import in Daisy.
>
> I'll see what I can do, but I think it's best to make sure ALL current
> docs are in Daisy (updated if necessary) before we do this release.
The simpler alternative would be a wget of the docs on cocoon.apache.org.
My argument would be that there's no bad thing keeping the new docs
system for 2.2.
Helma, are there any glaring mistakes in the currently live docs?
Regards, Upayavira
Re: Releasing 2.1.8
Posted by Joerg Heinicke <jo...@gmx.de>.
Carsten Ziegeler <cziegeler <at> apache.org> writes:
> I agree that we still should build the
> api docs, but we shouldn't copy them in the webapps directory anymore.
> Just storing them in a directory should be enough, I think. So I want to
> remove the build targets for copying/integrating them into the Cocoon
> webapp.
+1
This took always so much time that I always switched it off immediately.
Jörg
Re: Releasing 2.1.8
Posted by Ralph Goers <Ra...@dslextreme.com>.
Antonio Gallardo wrote:
> Antonio Gallardo wrote:
>
>> Ralph Goers wrote:
>>
>>>>
>>> If I understand you correctly, that would save a bout 5 minutes off
>>> a normal build as that is how long it takes to copy the 6000+ files
>>> on my lowly 3.3Mhz laptop.
>>
>>
>>
>> A 3.3 MHz. laptop is really a very slow one! ;-)
>>
>> /me wondering if Ralph laptop has enough free HD space to deploy the
>> 6,000 files too. ;-)
>
>
> Actually, it was a small joke on the typo in the original mail. There
> was stated MHz. instead of GHz. ;-)
Sheesh. I ddn't notice that.
Ralph
Re: Releasing 2.1.8
Posted by Antonio Gallardo <ag...@agssa.net>.
Antonio Gallardo wrote:
> Ralph Goers wrote:
>
>>>
>> If I understand you correctly, that would save a bout 5 minutes off a
>> normal build as that is how long it takes to copy the 6000+ files on
>> my lowly 3.3Mhz laptop.
>
>
> A 3.3 MHz. laptop is really a very slow one! ;-)
>
> /me wondering if Ralph laptop has enough free HD space to deploy the
> 6,000 files too. ;-)
Actually, it was a small joke on the typo in the original mail. There
was stated MHz. instead of GHz. ;-)
Best Regards,
Antonio Gallardo.
Re: Releasing 2.1.8
Posted by Ralph Goers <Ra...@dslextreme.com>.
Antonio Gallardo wrote:
> Ralph Goers wrote:
>
>>>
>> If I understand you correctly, that would save a bout 5 minutes off a
>> normal build as that is how long it takes to copy the 6000+ files on
>> my lowly 3.3Mhz laptop.
>
>
> A 3.3 MHz. laptop is really a very slow one! ;-)
>
> /me wondering if Ralph laptop has enough free HD space to deploy the
> 6,000 files too. ;-)
100 GB and 2GB of memory.
Lugging it around Amsterdam was so much fun! (It weighs a lot!)
>
> Best Regards,
>
> Antonio Gallardo.
Ralph
>
>>
>>
>> Ralph
>
>
>
Re: Releasing 2.1.8
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>
>Now, actually you must have seen Ralph's laptop and then you know how
>powerful it is. I guess you can do a lot of usefull things with it, like
>hammering nails into the wall, effectively throwing it at people making
>dumb comments etc :) (just kidding, Ralph, but your "laptop" is really huge)
>
>Carsten
>
>
LOL! Yeah, you really can't call it a laptop. It is useless on a plane
cause it won't really fit on those small little trays - especially when
the person in front of you leans back. But having a 17 inch monitor is
really great - especially when I also hook it up to my other flatscreen
at home.
On the other hand, I probably lost a few pounds (badly needed) lugging
it around!
Ralph
Re: Releasing 2.1.8
Posted by Carsten Ziegeler <cz...@apache.org>.
Antonio Gallardo wrote:
> Ralph Goers wrote:
>
>
>>If I understand you correctly, that would save a bout 5 minutes off a
>>normal build as that is how long it takes to copy the 6000+ files on
>>my lowly 3.3Mhz laptop.
>
Yepp, exactly :)
>
> A 3.3 MHz. laptop is really a very slow one! ;-)
>
> /me wondering if Ralph laptop has enough free HD space to deploy the
> 6,000 files too. ;-)
>
Now, actually you must have seen Ralph's laptop and then you know how
powerful it is. I guess you can do a lot of usefull things with it, like
hammering nails into the wall, effectively throwing it at people making
dumb comments etc :) (just kidding, Ralph, but your "laptop" is really huge)
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8
Posted by Antonio Gallardo <ag...@agssa.net>.
Ralph Goers wrote:
>>
> If I understand you correctly, that would save a bout 5 minutes off a
> normal build as that is how long it takes to copy the 6000+ files on
> my lowly 3.3Mhz laptop.
A 3.3 MHz. laptop is really a very slow one! ;-)
/me wondering if Ralph laptop has enough free HD space to deploy the
6,000 files too. ;-)
Best Regards,
Antonio Gallardo.
>
>
> Ralph
Re: Releasing 2.1.8
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
>
>
>Ah, sorry, I wasn't very clear. I agree that we still should build the
>api docs, but we shouldn't copy them in the webapps directory anymore.
>Just storing them in a directory should be enough, I think. So I want to
>remove the build targets for copying/integrating them into the Cocoon
>webapp.
>
>Carsten
>
>
If I understand you correctly, that would save a bout 5 minutes off a
normal build as that is how long it takes to copy the 6000+ files on my
lowly 3.3Mhz laptop.
Ralph
Re: Releasing 2.1.8
Posted by Carsten Ziegeler <cz...@apache.org>.
hepabolu wrote:
>
> * As a temporary substitute we could indeed provide the
> - PDF: simple, because 1 file to extract and include in docs dir.
> - HTML: less simple, because it's a bunch of files, I could ask Bruno
> what the best way to do this is.
>
> I'd do the PDF in any case, since it's so easy. HTML is probably not
> necessary then.
>
Agreed, I think a PDF is sufficient.
> * removal of doc building tags is ok.
> * api docs building tags should be left in as that is not addressed in
> Daisy.
>
Ah, sorry, I wasn't very clear. I agree that we still should build the
api docs, but we shouldn't copy them in the webapps directory anymore.
Just storing them in a directory should be enough, I think. So I want to
remove the build targets for copying/integrating them into the Cocoon
webapp.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Releasing 2.1.8
Posted by hepabolu <he...@gmail.com>.
Carsten Ziegeler wrote:
> We wanted to release 2.1.8 as soon as possible after the GT.
> Now the question is, are there any open issues?
>
> I'm currently aware of two problems:
> 1) Documentation - 2.1.8 does not contain the docs anymore, so we should
> find a way to add them in the distribution. I think a directory
> containing just the html docs (or pdf?) should be fine.
> In addition I think we should remove the targets for adding the docs
> and the api docs to the webapp.
* As a temporary substitute we could indeed provide the
- PDF: simple, because 1 file to extract and include in docs dir.
- HTML: less simple, because it's a bunch of files, I could ask Bruno
what the best way to do this is.
I'd do the PDF in any case, since it's so easy. HTML is probably not
necessary then.
* removal of doc building tags is ok.
* api docs building tags should be left in as that is not addressed in
Daisy.
Note that, although 80% - 90% of the "legacy" docs is currently in
Daisy, there are some smaller parts missing, a.o. the snippets. And for
some parts of the docs (those not yet removed from the repository) I
have to check if they have been updated since the import in Daisy.
I'll see what I can do, but I think it's best to make sure ALL current
docs are in Daisy (updated if necessary) before we do this release.
Bye, Helma