Re: Cocoon 2.2 documentation online!
Reinhard Poetz schrieb: > > While I was creating all the release artifacts of Cocoon 2.2RC2 I also > published our 2.2 docs. See http://cocoon.apache.org/2.2/ > > I have to say that I'm really proud of seeing this long-term effort > finally materializing :-) Thanks to all the involved helping hands! > > The only missing part is the main site (http://cocoon.apache.org). If > nobody speaks up over the weekend, I will also publish it (see > http://cocoon.zones.apache.org/dev-docs/) on Monday. It would be great > if a native speaker could proof-read it in the meantime. > It's great to see the new site online :-) ! Just a small note: I noticed a simular problem on both sites (c.z.a.o/dev-docs/ and c.a.o/2.2/) under Linux/Firefox and Windows/MSIE: When you click into the search field ontop right corner the text is still there. It would be nice if we could clean the field when clicking into ()Remove the hint text from the box) as it is on the 'old' page http://cocoon.apache.org/2.1/. Regards Felix
Re: Code freeze - over
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
Thanks Reinhard for taking care!
It's nice that we will be able to start creating buzz about Cocoon 2.2
shortly! :-)
;-)
btw, I've forgotten to mention that I'm waiting for the solution(s) that
fix(es) Giacomo's bug and the cocoon:/ problem. Then I will recreate the
affected core modules and then call for the vote.
Oups, I forgot about it too.
I'll give this a thorough look this weekend so there is a humble ask: if you,
Giacomo, Reinhard and others could monitor our mailing list during this
weekend more often than usually I would be grateful. It's very likely I will
be having additional questions.
I'm sorry, but I will be offline over the weekend. Maybe I have a chance to
check the mails on Sunday afternoon but can't promise.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Code freeze - over
Reinhard Poetz pisze: > Grzegorz Kossakowski wrote: >> Reinhard Poetz pisze: >> >> Thanks Reinhard for taking care! >> >> It's nice that we will be able to start creating buzz about Cocoon 2.2 >> shortly! :-) > > ;-) > > btw, I've forgotten to mention that I'm waiting for the solution(s) > that fix(es) Giacomo's bug and the cocoon:/ problem. Then I will > recreate the affected core modules and then call for the vote. Oups, I forgot about it too. I'll give this a thorough look this weekend so there is a humble ask: if you, Giacomo, Reinhard and others could monitor our mailing list during this weekend more often than usually I would be grateful. It's very likely I will be having additional questions. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze - over
Grzegorz Kossakowski wrote:
Reinhard Poetz pisze:
All release artifacts and their docs have been created. This means that
the code freeze is over and our SVN is happily awaiting your commits again!
Currently trunk doesn't build because the parent pom references are not
set correctly. I will take care for this tommorrow morning if nobody
else is doing it in the meantime:
You would just have to use tools/pom-updater/pu.sh and set
org.apache.cocoon:cocoon
org.apache.cocoon:cocoon-blocks-modules
org.apache.cocoon:cocoon-core-modules
org.apache.cocoon:cocoon-tools-modules
to 6-SNAPSHOT.
Thanks Reinhard for taking care!
It's nice that we will be able to start creating buzz about Cocoon 2.2 shortly!
:-)
;-)
btw, I've forgotten to mention that I'm waiting for the solution(s) that
fix(es) Giacomo's bug and the cocoon:/ problem. Then I will recreate the
affected core modules and then call for the vote.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Renewing Apache Fop processor
Vadim Gritsenko reverycodes.com> writes: > >> ... I forgot to mention we are working with cocoon-2.1.10. Did somebody > >> already try to use a newer version of FOP for this cocoon version?... > > > > I think that's what http://issues.apache.org/jira/browse/COCOON-1795 > > does - some assembly required probably. > > IIUC, this thing is already in svn and called "fop-ng". It's another implementation. fop-ng was done on the CocoonGT last year by Jeremias and Lars as far as I remember. Joerg
Re: Cocoon 2.2 documentation online!
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
While I was creating all the release artifacts of Cocoon 2.2RC2 I also
published our 2.2 docs. See http://cocoon.apache.org/2.2/
I have to say that I'm really proud of seeing this long-term effort
finally materializing :-) Thanks to all the involved helping hands!
The only missing part is the main site (http://cocoon.apache.org). If
nobody speaks up over the weekend, I will also publish it (see
http://cocoon.zones.apache.org/dev-docs/) on Monday. It would be great
if a native speaker could proof-read it in the meantime.
I noticed that component's basic information table is incorrect. For
example
http://cocoon.apache.org/2.2/core-modules/core/2.2/889_1_1.html
Should read:
Component typeAction
Cocoon blockcore
Java classorg.apache.cocoon.acting.LocaleAction
Cachable
This is probably error in the template? Also, "Cachable" should be
"Cacheable". Where would I fix it?
see
https://svn.apache.org/repos/asf/cocoon/trunk/tools/cocoon-daisy-export-strategy/src/main/resources/org/apache/cocoon/tools/maven/daisy/export/strategy/cocoon-doc-2-xdoc.xslt
This stylesheet transforms the documents which are read from the Daisy
repository into something the Maven 2 site plugin can deal with.
If you want to test it, change the stylesheet, then install the Daisy export
plugin into your local Maven repository by running 'mvn install', go into a
module that contains sitemap components and run 'mvn site -P daisy'
But before make sure that you've configured Maven as explained in
http://cocoon.zones.apache.org/daisy/cdocs/g3/1256.html so that you can access
the Daisy repository. (@vadim: it should work with your Daisy user because it
already has administration rights granted.)
- o -
http://cocoon.zones.apache.org/daisy/cdocs/g3/1256.html also explains how you
can create (and/or deploy) all docs at one go.
- o -
One note: As soon as I have some time I will write a Maven 2 plugin which
removes all non-Daisy docs from ./target/site before they are deployed.
Otherwise we would overwrite all reports with reports that refer to a snapshot
versions.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: BookDefinition instead of NavigationDocument
Grzegorz Kossakowski wrote:
Grzegorz Kossakowski pisze:
Hi,
You have probably noticed that I'm doing some documentation work. I wanted to
have better
(meaningful) URLs for documents I create and recalled that Daisy has support
for this. Then I found
that we use BookDefinition instead of NavigationDocument for our navigations.
AFAIK, BookDefinition
does not support giving explicit IDs for its nodes thus nice URLs are
impossible to achieve. Is it true?
I found a very nice e-mail[1] from Reinhard that provides very good overview
(thanks Reinhard!) of
our current documentation system. Use of BookDefinition has been mentioned in
that e-mail in
following way:
"I recommend that you use the BookDefinition instead of the NavigationDocument
type which is more
powerful as it allows the creation of books."
Unfortunately there was no elaboration on BookDefinition power.
How my problem can be solved?
Reinhard, could you comment on this?
There are long discussions in our archives about the pros and cons and I was on
the side of those who prefer IDs because sooner or later the content doesn't
match this ID. Hence I have never missed speaking document names in URLs. I also
think that the Maven Daisy plugin wouldn't support them.
Answering your question: I think that's a restriction of book definitions
because for the creation of a book it doesn't add any value to set alternative IDs.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Cocoon 2.2 documentation online!
Reinhard Poetz wrote: While I was creating all the release artifacts of Cocoon 2.2RC2 I also published our 2.2 docs. See http://cocoon.apache.org/2.2/ I have to say that I'm really proud of seeing this long-term effort finally materializing :-) Thanks to all the involved helping hands! The only missing part is the main site (http://cocoon.apache.org). If nobody speaks up over the weekend, I will also publish it (see http://cocoon.zones.apache.org/dev-docs/) on Monday. It would be great if a native speaker could proof-read it in the meantime. I noticed that component's basic information table is incorrect. For example http://cocoon.apache.org/2.2/core-modules/core/2.2/889_1_1.html Should read: Component typeAction Cocoon block core Java classorg.apache.cocoon.acting.LocaleAction Cachable This is probably error in the template? Also, "Cachable" should be "Cacheable". Where would I fix it? Vadim
Re: BookDefinition instead of NavigationDocument
Grzegorz Kossakowski pisze: > Hi, > > You have probably noticed that I'm doing some documentation work. I wanted to > have better > (meaningful) URLs for documents I create and recalled that Daisy has support > for this. Then I found > that we use BookDefinition instead of NavigationDocument for our navigations. > AFAIK, BookDefinition > does not support giving explicit IDs for its nodes thus nice URLs are > impossible to achieve. Is it true? > > I found a very nice e-mail[1] from Reinhard that provides very good overview > (thanks Reinhard!) of > our current documentation system. Use of BookDefinition has been mentioned in > that e-mail in > following way: > > "I recommend that you use the BookDefinition instead of the > NavigationDocument type which is more > powerful as it allows the creation of books." > > Unfortunately there was no elaboration on BookDefinition power. > > How my problem can be solved? Reinhard, could you comment on this? -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Cocoon 2.2 documentation online!
While I was creating all the release artifacts of Cocoon 2.2RC2 I also published
our 2.2 docs. See http://cocoon.apache.org/2.2/
I have to say that I'm really proud of seeing this long-term effort finally
materializing :-) Thanks to all the involved helping hands!
The only missing part is the main site (http://cocoon.apache.org). If nobody
speaks up over the weekend, I will also publish it (see
http://cocoon.zones.apache.org/dev-docs/) on Monday. It would be great if a
native speaker could proof-read it in the meantime.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Java 1.5
Reinhard Poetz wrote: I think for 2.2 it is fine to stick with Java 1.4 and go for Java 5 with 2.3. This should also give the Websphere 6 users enough time and is for all the Java 5 fans motivation to make 2.3 happen soon ;-) Exactly. Vadim
Re: Branching cocoon-forms
Giacomo Pati wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: Grzegorz Kossakowski wrote: Hmmm, does such structure and directory naming makes sense? I would expect creation of directory like this: cocoon/branches/cocoon-forms-1.0.x Putting Cocoon Forms 1.0.0 into cocoon-2.2 does not make sense because form block wouldn't be necessary tied to 2.2 of core. That might be true but e.g. for the documentation we agreed to put all blocks unter http://cocoon.apache.org/2.2 because we also can't say that cocoon-forms-1.0.x will work with all future Cocoon releases. When cocoon-forms-1.0.x is still compatible with e.g. Cocoon 2.3, then we create just another branch cocoon/branches/cocoon-2.3/cocoon-forms-1.0.x/ (though I hardly believe that this will happen ...) So, where to put it now! Is this in need for a vote ;-) cocoon/branches/cocoon-2.2/cocoon-forms-1.0.x! Vadim
Re: Renewing Apache Fop processor
Bertrand Delacretaz wrote: On 9/28/07, Robby Pelssers <[EMAIL PROTECTED]> wrote: ... I forgot to mention we are working with cocoon-2.1.10. Did somebody already try to use a newer version of FOP for this cocoon version?... I think that's what http://issues.apache.org/jira/browse/COCOON-1795 does - some assembly required probably. IIUC, this thing is already in svn and called "fop-ng". Vadim
Re: Renewing Apache Fop processor
Robby Pelssers wrote: Hi Vadim, I forgot to mention we are working with cocoon-2.1.10. Did somebody already try to use a newer version of FOP for this cocoon version? It _should_ work fine with it, even with 2.1.9. Vadim Cheers, Robby -Oorspronkelijk bericht- Van: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Verzonden: donderdag, september 2007 19:18 Aan: dev@cocoon.apache.org Onderwerp: Re: Renewing Apache Fop processor Robby Pelssers wrote: Hi, I regularly seem to have problems because the current distributed version of apache fop processor (fop-0.5.20.jar) does not support a lot of needed attributes like for instance "linefeed-treatment". http://xmlgraphics.apache.org/fop/compliance.html#fo-object-block-sect io n How difficult/easy would it be to use a newer version (0.93 or 0.94)? Is it only a matter of replacing the jar with a newer jar or do I run into problems in that case? Easy: just use fop-ng block. You also have to update your fop config file, if you are using it. Vadim
Re: Renewing Apache Fop processor
On 9/28/07, Robby Pelssers <[EMAIL PROTECTED]> wrote: >... I forgot to mention we are working with cocoon-2.1.10. Did somebody > already try to use a newer version of FOP for this cocoon version?... I think that's what http://issues.apache.org/jira/browse/COCOON-1795 does - some assembly required probably. -Bertrand
Re: Branching cocoon-forms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Reinhard Poetz wrote: > Grzegorz Kossakowski wrote: >> Hmmm, does such structure and directory naming makes sense? I would >> expect creation of directory >> like this: >> cocoon/branches/cocoon-forms-1.0.x >> >> Putting Cocoon Forms 1.0.0 into cocoon-2.2 does not make sense because >> form block wouldn't be >> necessary tied to 2.2 of core. > > That might be true but e.g. for the documentation we agreed to put all > blocks unter http://cocoon.apache.org/2.2 because we also can't say that > cocoon-forms-1.0.x will work with all future Cocoon releases. > > When cocoon-forms-1.0.x is still compatible with e.g. Cocoon 2.3, then > we create just another branch > cocoon/branches/cocoon-2.3/cocoon-forms-1.0.x/ (though I hardly believe > that this will happen ...) So, where to put it now! Is this in need for a vote ;-) - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG/OnuLNdJvZjjVZARAoprAKDOiPizDaxIbUcDp8OjMboS+AISfgCgtODM wUT5Ohwx5db8kALhlzB4nLc= =OcuM -END PGP SIGNATURE-
Re: svn commit: r580303 - /cocoon/branches/cocoon-2.2/cocoon-forms-avalon-based/
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Grzegorz Kossakowski wrote: > [EMAIL PROTECTED] pisze: >> Author: giacomo >> Date: Fri Sep 28 04:13:23 2007 >> New Revision: 580303 >> >> URL: http://svn.apache.org/viewvc?rev=580303&view=rev >> Log: >> branch Avalon based CForm blocks >> >> Added: >> cocoon/branches/cocoon-2.2/cocoon-forms-avalon-based/ >> - copied from r580301, cocoon/trunk/blocks/cocoon-forms/ > > Hmmm, does such structure and directory naming makes sense? I would expect > creation of directory > like this: > cocoon/branches/cocoon-forms-1.0.x > > Putting Cocoon Forms 1.0.0 into cocoon-2.2 does not make sense because form > block wouldn't be > necessary tied to 2.2 of core. No problem, just anybody has made any suggestions. I'll move it away to ../branches/cocoon-forms-1.0.0 Ciao and thanks - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.6 (GNU/Linux) iD8DBQFG/OmILNdJvZjjVZARAshbAKDllPbtGBDk9L4ZOBeBMAFYjqRo5gCgt+Cl JUR5727JnnifK15ro5inwfs= =nP9h -END PGP SIGNATURE-
Re: Renewing Apache Fop processor
On 28.09.2007 5:05 Uhr, Robby Pelssers wrote: I forgot to mention we are working with cocoon-2.1.10. Did somebody already try to use a newer version of FOP for this cocoon version? So far it should still be pretty straight-forward to use a 2.2 block in 2.1 as long as it has not been converted to Spring yet. There are probably some differences in directory structures, but they should be easy to figure out. You are also not the first one asking for FOP 0.9.x in Cocoon 2.1, so you might repeat your question on the users list (or search the archives). Joerg
Branching cocoon-forms
Grzegorz Kossakowski wrote:
[EMAIL PROTECTED] pisze:
Author: giacomo
Date: Fri Sep 28 04:13:23 2007
New Revision: 580303
URL: http://svn.apache.org/viewvc?rev=580303&view=rev
Log:
branch Avalon based CForm blocks
Added:
cocoon/branches/cocoon-2.2/cocoon-forms-avalon-based/
- copied from r580301, cocoon/trunk/blocks/cocoon-forms/
Hmmm, does such structure and directory naming makes sense? I would expect
creation of directory
like this:
cocoon/branches/cocoon-forms-1.0.x
Putting Cocoon Forms 1.0.0 into cocoon-2.2 does not make sense because form
block wouldn't be
necessary tied to 2.2 of core.
That might be true but e.g. for the documentation we agreed to put all blocks
unter http://cocoon.apache.org/2.2 because we also can't say that
cocoon-forms-1.0.x will work with all future Cocoon releases.
When cocoon-forms-1.0.x is still compatible with e.g. Cocoon 2.3, then we create
just another branch cocoon/branches/cocoon-2.3/cocoon-forms-1.0.x/ (though I
hardly believe that this will happen ...)
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: svn commit: r580303 - /cocoon/branches/cocoon-2.2/cocoon-forms-avalon-based/
[EMAIL PROTECTED] pisze: > Author: giacomo > Date: Fri Sep 28 04:13:23 2007 > New Revision: 580303 > > URL: http://svn.apache.org/viewvc?rev=580303&view=rev > Log: > branch Avalon based CForm blocks > > Added: > cocoon/branches/cocoon-2.2/cocoon-forms-avalon-based/ > - copied from r580301, cocoon/trunk/blocks/cocoon-forms/ Hmmm, does such structure and directory naming makes sense? I would expect creation of directory like this: cocoon/branches/cocoon-forms-1.0.x Putting Cocoon Forms 1.0.0 into cocoon-2.2 does not make sense because form block wouldn't be necessary tied to 2.2 of core. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Code freeze - over
Reinhard Poetz pisze: > > All release artifacts and their docs have been created. This means that > the code freeze is over and our SVN is happily awaiting your commits again! > > Currently trunk doesn't build because the parent pom references are not > set correctly. I will take care for this tommorrow morning if nobody > else is doing it in the meantime: > > You would just have to use tools/pom-updater/pu.sh and set > > org.apache.cocoon:cocoon > org.apache.cocoon:cocoon-blocks-modules > org.apache.cocoon:cocoon-core-modules > org.apache.cocoon:cocoon-tools-modules > > to 6-SNAPSHOT. Thanks Reinhard for taking care! It's nice that we will be able to start creating buzz about Cocoon 2.2 shortly! :-) -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: ObjectModel exception
Leszek Gawron pisze: > Grzegorz Kossakowski wrote: >> Leszek Gawron pisze: >> >> Because comparison is made by low-level class like ArrayList that is >> unaware of wrapping objects. >> >> Do you want to say that NativeObjects should be unwrapped always >> whenever they are used in Java code? > > Seems natural to me. Otherwise anything put into object model from flow > would be a native object - would you like to work with these in your > java code? Nope but I wonder why Rhino does not return unwrapped objects already if they should always be unwrapped? Anyway feel free to create issue in JIRA and start working on this if you wish. -- Grzegorz Kossakowski Committer and PMC Member of Apache Cocoon http://reflectingonthevicissitudes.wordpress.com/
Re: Java 1.5
Hi, On 28 Sep 2007, at 05:38, Joerg Heinicke wrote: And what's the use of it? I just don't get it why a framework should set restrictions on its user base. Well, by that argument we should make cocoon work with Ruby, C++, Lisp, Erlang, etc etc ... don't want to restrict our users to just one language ;-) There's a strong argument for not adding restrictions to an existing tree (2.1), but for an unreleased framework (2.2+), it makes sense that the best available solutions should be used -- otherwise there's never an incentive for those using it to upgrade. Thanks, Andrew. -- Sourcesense: Making sense of Open Source Tel: +44 (0)870 741 6658 Fax: +44 (0)700 598 1135 Web: http://www.sourcesense.com/
RE: Renewing Apache Fop processor
Hi Vadim, I forgot to mention we are working with cocoon-2.1.10. Did somebody already try to use a newer version of FOP for this cocoon version? Cheers, Robby -Oorspronkelijk bericht- Van: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Verzonden: donderdag, september 2007 19:18 Aan: dev@cocoon.apache.org Onderwerp: Re: Renewing Apache Fop processor Robby Pelssers wrote: > Hi, > > I regularly seem to have problems because the current distributed > version of apache fop processor (fop-0.5.20.jar) does not support a > lot of needed attributes like for instance "linefeed-treatment". > > http://xmlgraphics.apache.org/fop/compliance.html#fo-object-block-sect > io > n > > How difficult/easy would it be to use a newer version (0.93 or 0.94)? > Is it only a matter of replacing the jar with a newer jar or do I run > into problems in that case? Easy: just use fop-ng block. You also have to update your fop config file, if you are using it. Vadim
