[docs] docs Ant target
David and I have talked what has to be done to integrate the automatically
generated docs into the new docs repository. He reminded me that we shouldn't
lead this discussion in private but on [EMAIL PROTECTED] (Sorry guys, it started with
a slightly off-topic question and it has grown bigger, and bigger )
David Crossley wrote:
Reinhard Poetz wrote:
After looking at cocoon/trunk/tools/targets/docs-build.xml I have to admit
that I don't understand the purpose of this, except that it builds the
sitemap-components docs.
It copies all the source xml docs to a work directory, generates the
important source for installing/jars.xml file, runs the SitemapTask to
read the userdocs/*/*.xml and append other content that gets generated
from the java sources, and i think that it might also copy the generated
javadocs. Then the user runs 'forrest' which is configured in forrest.properties
to read the sources from the temporary directory which was generated by
the 'build docs'. The process to build
I cannot properly see from here, but if you have re-arranged the location
of the sources, then the cocoon/trunk/forrest.properties will need to be
modified. The forrestbot config might not need to be changed.
There is no point making changes to the forrestbot until this
can be run locally. If you can do 'build docs; forrest' .
I'm going to be off-line until Wednesday next week, but then I will have a look
again at the doc target and will try to fix it. If somebody misses the old 2.2
documentation - it moved to cocoon/whiteboard.
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
[heads up] Moving all blocks into /cocoon/blocks
I plan to move all blocks from /cocoon/trunk/src/blocks into
/cocoon/blocks/[status]/name/trunk the same way as I did it with cron,
authentication-fw, session-fw and html. As nobody complained, I think that there
haven't been any problems.
If you want to avoid problems with pending changes that wait to be committed,
please check them in *before Thursday* next week - otherwise you will probably
get some mess when you want to update your working copy again after the move.
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
DO NOT REPLY [Bug 33836] - JXTemplateGenerator cache thread safety problem
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33836. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33836 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [docs] docs Ant target
Le 4 mars 05, à 09:26, Reinhard Poetz a écrit : David and I have talked what has to be done to integrate the automatically generated docs into the new docs repository... Just FYI, yesterday night in my very-scarce-free-time-these-days I wanted to have a look at the state of the new docs, and didn't find an easy way to look at them (what build targets to use, which version of forrest, etc.) - I ended up grepping the documentation tree for content_en.* files and opening these in a browser ;-) I might have been looking in the wrong places, but it might be good to have a wiki page or bugzilla entry to show the current status of the move, and explain how to generate the docs to get a feel of how they look. Or just say they can't be easily generated currently if it's the case (don't flame me, I've been a bit disconnected recently ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [docs] docs Ant target
Bertrand Delacretaz wrote: Le 4 mars 05, à 09:58, Upayavira a écrit : ...You can see the pages built on Brutus:.. Thanks. These are updated by manually running stuff, right? Automatically twice a day (or so) and can be manually triggered too. David is the expert here. Regards, Upayavira
Re: [docs] docs Ant target
Le 4 mars 05, à 10:23, Upayavira a écrit : Automatically twice a day (or so) and can be manually triggered too. David is the expert here. Thanks - I have added this info to http://wiki.apache.org/cocoon/22NewDocumentsGeneration and linked to that page to have this info in one place. -Bertrand smime.p7s Description: S/MIME cryptographic signature
[OT] Mini Cocoon available...at last
its-friday We're all waiting for a streamlined Cocoon right? http://www.macminute.com/2005/03/04/radtech/ /its-friday -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] A Unified Environment Model?
Vadim Gritsenko wrote:
IMHO, there is no point in such input modules anymore. All you need is
* JS and EL firendly object model with object factories
(modules is banned word)
* Support of the EL in the sitemap
Once these two points are here, all existing input modules can be (deprecated
and) removed. And all that they did can be then done in the sitemap with EL:
{/request/attributes/user}
So would I be able to do something like {/request/attributes/user=testuser}?
Re: [RT] A Unified Environment Model?
On Fri, 04 Mar 2005 10:10:05 +0100, Sylvain Wallez [EMAIL PROTECTED] wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
Isn't it too restrictive compared to the variety of what modules do?
Don't think so (returning an Object does not to restrict things that
much ;) ), but I haven't thought in detail about all modules, any
examples where it wouldn't work?
E.g. those modules that do some xpath extraction on XML data. But
maybe that isn't a problem if we consider my JS-as-the-only-EL
proposal as we could write 'xpath(om.xmlmodule, /path/to/element[1])'.
IMHO, there is no point in such input modules anymore. All you need is
* JS and EL firendly object model with object factories
(modules is banned word)
Not sure object _factories_ is the right word either, as they don't
create the object, but give access to them (creation is a particular
case of giving access). Something like object accessor would be better.
* Support of the EL in the sitemap
Once these two points are here, all existing input modules can be
(deprecated and) removed. And all that they did can be then done in
the sitemap with EL:
{/request/attributes/user}
WDYT?
Kewl. This will bring to Cocoon both an improved consistency and an
improved expressiveness because of the genearlized EL.
This is more of a RT than anything concrete for or against the ideas
given so far.
As I follow this discussion it keeps striking me that we're
more-or-less reinventing resolvers and sources at a slightly lower
level. At one level, people need:
protocol://x/y/z
to resolve to some XML/SAX stream fragment. Now we want
module.x.y.z
to resolve to something that isn't always XML but can be used to
create a SAX stream or can be traversed with some kind of expression
language.
So on one hand, we've got source resolvers and xpath and on the other
hand we've got factories (hidden or not) resolving to object modules
and some expression languages.
I can't help but have the feeling that if XSLT was easy we wouldn't
be having this discussion at all. Stefano once proposed an alternate
XSLT syntax, but I think the issues of understanding a declarative
language wouldn't go away.
Personally, I wonder if any of what is being discussed is really
necessary; I'd love to see the Cocoon community put a stake in the
ground and build a good set of XSLT authoring tools and XSLT function
and document support capabilities and say the way to data
manipulation and transformation with Cocoon is XSLT!
Given that doesn't seem likely to happen, I guess the only thing I can
suggest here is that everyone should take a step back and make sure
the existing Cocoon machinery for source resolving and xpath traversal
isn't re-usable in some way before inventing anything new...
--
Peter Hunsberger
Re: SAXParser.parse alternative?
Ok. But, don't you guys also monitor the users@ list as well? I guess I just don't like seeing two copies of the same thing in my inbox. ;) -Daniel On Fri, 04 Mar 2005 09:06:24 +0100, Jorg Heymans [EMAIL PROTECTED] wrote: A lot of users bring their issues to dev@ when they don't get an answer on [EMAIL PROTECTED] This is quite allright, no need to play spamcop here :)
Re: SAXParser.parse alternative?
Daniel McOrmond wrote: Ok. But, don't you guys also monitor the users@ list as well? I guess I just don't like seeing two copies of the same thing in my inbox. ;) Some do, not all. It is a lot of stuff to take in, hence it being worth going to the dev list if no resolution comes. Regards, Upayavira
Re: SAXParser.parse alternative?
Upayavira wrote: Daniel McOrmond wrote: I guess I just don't like seeing two copies of the same thing in my inbox. ;) you could subscribe through gmane to read the list. It makes reading the list just like reading a newsgroup. Now if only thunderbird had better newsgroup support sigh cheers Jorg
DO NOT REPLY [Bug 33850] New: - NullPointerException in SQLTransformer
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33850. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33850 Summary: NullPointerException in SQLTransformer Product: Cocoon 2 Version: Current SVN 2.1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: blocks AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] In src/blocks/databases/java/org/apache/cocoon/transformation/SQLTransformer.java around line 1134 are the lines Clob clob = rs.getClob(i); InputStream inputStream = clob.getAsciiStream(); which cause a NPE when getClob() returns null. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
2.1.7-Dev - Commit 156144 - Borked, or am I mad?
Hi guys, Am I going mad, or did this break some of my stuff? It seems as though some of my forms are being cached now, and the change is to do with removing stuff from the cache... If this isn't the case, I apologise for pointing fingers, but I'm sure it worked a couple of days ago. I updated today, recompiled and it stopped working, reverted back and it works again. Anybody else seeing this behaviour? I restarted Jetty a couple of times, but it was definitely displaying data that was no longer in the data file! And none of my pages seem to change when I feed in a different parameter. I still get the same continuation id embedded in the page. Even accessed it from a different browser, one that has never visited said page. Ben
RE: 2.1.7-Dev - Commit 156144 - Borked, or am I mad?
I think I'm mad, so ignore me. Bit difficult to tell now, didn't realise a build clean just deleted the webapp directory. Shame really, as my work was there. Ben -Original Message- From: Ben Pope [mailto:[EMAIL PROTECTED] Sent: 04 March 2005 23:39 To: dev@cocoon.apache.org Subject: 2.1.7-Dev - Commit 156144 - Borked, or am I mad? Hi guys, Am I going mad, or did this break some of my stuff? It seems as though some of my forms are being cached now, and the change is to do with removing stuff from the cache... If this isn't the case, I apologise for pointing fingers, but I'm sure it worked a couple of days ago. I updated today, recompiled and it stopped working, reverted back and it works again. Anybody else seeing this behaviour? I restarted Jetty a couple of times, but it was definitely displaying data that was no longer in the data file! And none of my pages seem to change when I feed in a different parameter. I still get the same continuation id embedded in the page. Even accessed it from a different browser, one that has never visited said page. Ben
