with. If they wish to accept this invitation, they can
be provided with the necessary accounts.
Regards, Upayavira
Upayavira wrote:
Also, I'd like to invite both Mark Leicester and Glen Ezkovich to be
editors, so that they can get on and do good stuff without having to
ask. They have the ideas and enthusiasm, and I'm very keen to see what
they can come up with. If they wish to accept this invitation
Sebastien Arbogast wrote:
2005/6/9, Upayavira [EMAIL PROTECTED]:
Upayavira wrote:
Also, I'd like to invite both Mark Leicester and Glen Ezkovich to be
editors, so that they can get on and do good stuff without having to
ask. They have the ideas and enthusiasm, and I'm very keen to see what
:-)
[1] http://wiki.apache.org/cocoon/CocoonUserGroupLondon
If there are more Londoners out there, do sign up!
Regards, Upayavira
the
same remit.
Upayavira
On 6 Jun 2005, at 10:27, Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le 6 juin 05, à 10:28, Steven Noels a écrit :
...That said, we need to discuss access policies to the Daisy
instance on our Cocoon zone. It's only logical committers are
granted User access
Reinhard Poetz wrote:
Upayavira wrote:
Well, given Steven is working on setting up Daisy right now, I think
we might need that. How much change would our SVN repo require to make
0.7 work?
AFAIK our repositories build fine with Forrest 0.7. The person doing the
conversion of the docs
we have already been doing for the 2.2 efforts.
Question for me is whether we want to carry on on 2.2, or convert the
2.1 docs to xhtml/html right now and work on those.
Thoughts?
Regards, Upayavira
Sylvain Wallez wrote:
Upayavira wrote:
Sylvain Wallez wrote:
Hi all,
Now that thanks to Steven we have a nice Cocoon-based ASF-hosted CMS,
we have to (and want to) use it!
AFAIU by reading the recent discussions, a difficult point is the
xdoc format used by Cocoon's internal publishing
a short, pithy, summary of what
Cocoon is, and I think we would do well to leave that for a week or two.
Does that sound reasonable?
Look forward to seeing what you come up with.
Regards, Upayavira
Ross Gardler wrote:
Reinhard Poetz wrote:
Upayavira wrote:
* This will mean that the end result will be xdocs, not HTML. However,
I don't believe converting HTML to xdocs would be hard, and I'd
happily knock up a script to do any necessary conversions.
actually Forrest already
Ross Gardler wrote:
Upayavira wrote:
Ross Gardler wrote:
Reinhard Poetz wrote:
Upayavira wrote:
* This will mean that the end result will be xdocs, not HTML.
However,
I don't believe converting HTML to xdocs would be hard, and I'd
happily knock up a script to do any necessary
to meet in any of our students,
which is a shame :-(
We really need to think of interesting projects that they are likely to
be attracted to, and that form clearly defined and measurable projects.
Regards, Upayavira
).
It is really good to just meet other people who are using and working
with Cocoon.
So go to http://wiki.apache.org/cocoon/CocoonUserGroupLondon and sign
up. I look forward to seeing you there.
Regards, Upayavira
handle xdocs type documents? Is a conversion to daisy's
format easy?
Regards, Upayavira
, in my view we shouldn't have an ultimate distinction. They are
both a part of the same overall documentation.
Regards, Upayavira
at the same time? This seems like a bit much to ask.
If someone else can offer an existing CMS that has the features they
need, and can be installed and operational within a reasonable amount of
time, then we'd be asking different questions.
Regards, Upayavira
Antonio Gallardo wrote:
On Mar, 24 de Mayo de 2005, 15:42, Upayavira dijo:
Sylvain Wallez wrote:
Sebastien Arbogast wrote:
The second important thing I notice in your remark is the argument
that people here know Cocoon but not PHP. But it's exactly our point :
we don't think Cocoon
migrating across to the
site-build zone. For the time being, we should, IMO, have our own zone
to play in.
+0, only because I don't expect to have time to contribute.
Regards, Upayavira
An interesting read. Where does the servlet container sit within this
picture? Do you need to have an OSGi servlet? Eclipse could by the sound
of it load these bundles, but wouldn't be able to run them due to a lack
of servlet container.
Regards, Upayavira
Daniel Fagerstrom wrote:
Sylvain
not want to start a tag library war. If cforms and jxtg are core
features they should closely support each other.
This is NOT the case of allowing arbitrary instruction sets to be
created. CForms case only.
Plase cast your votes:
[ ] Yes go for it.
2 in favour: me and Upayavira
[ ] It's a bad
, with a default in
the 1000x1000 or so range.
Does it have the 'don't enlarge' option that is in the current image
reader? That seems quite sensible to me.
Regards, Upayavira
, there is a new
discussion about site publishing ASF-wide that this could fit into -
whatever we chose to base our system on daisy, drupal, zope, or xml files.
Regards, Upayavira
that?
Regards, Upayavira
Leszek Gawron wrote:
Upayavira wrote:
Leszek Gawron wrote:
I have refactored JXTG recently so now instructions like jx:for,
jx:if are defined in separate file:
src/block/template/java/org/apache/cocoon/template/template-instructions.xml
Right now we are rendering forms in jxtg using a macro
my work on docs, and even if it does go
slowly, it will happen.
So just get on and do it, whatever you think 'it' needs to be, and then
people will either join in or object, or let you get on with it in freedom.
Regards, Upayavira
seen that
on occasions and wondered about it.
What you are saying makes sense, and I'd happily commit a patch of yours.
Regards, Upayavira
/documentation/src/content/xdocs/
Name it c21-avalon (which means that it is a straight copy from Cocoon
2.1, and hasn't been updated to Cocoon 2.2).
If you can't work out what to do, just ask.
Regards, Upayavira
Geoff Howard wrote:
Upayavira,
As I've only been able to marginally follow the new 2.2 docs strategy
(especially because there have been several I think over time!) :) I
wasn't sure what to do with this doc in 2.2. I also am not clear how
much of it will be accurate in 2.2.
I'll try to take
Geoff Howard wrote:
Upayavira,
As I've only been able to marginally follow the new 2.2 docs strategy
(especially because there have been several I think over time!) :) I
wasn't sure what to do with this doc in 2.2. I also am not clear how
much of it will be accurate in 2.2.
I'll try to take
have them and I'll update the page.
Regards, Upayavira
?
(b) Names of projects/frameworks that could well be listed?
Regards, Upayavira
, would you be willing to draft a page that we
can review?
Regards, Upayavira
long-term. However, so long as
_something_ is there, I'm happy!
Regards, Upayavira
://brutus.apache.org/docs/build/cocoon-doco-global/
And a sample block:
http://brutus.apache.org/docs/build/cocoon-block-portal/
Regards, Upayavira
Sylvain Wallez wrote:
Jorg Heymans wrote:
Upayavira wrote:
I can see this being useful for first time cocooners.
What if the cocoon build switches to maven (as rumoured a few times
already)? Can the tool be extended to handle this? Will you need
seperate logic to handle the 2.2 block
.
Regards, Upayavira
Simon Mieth wrote:
On Thu, 14 Apr 2005 20:49:33 +0200
Daniel Fagerstrom [EMAIL PROTECTED] wrote:
Upayavira wrote:
If the user can get all the way to start Jetty with our demos through
a simple GUI, I find it a good idea. Even if I'm perfectly able to
read a README and run ant or make when I
, but I'm sure it
can be done, somehow!
Regards, Upayavira
block, and scroll down.
5) I haven't tested the gui.cmd script, but it should work, as the
settings are the same as the Unix script.
The installer home is at antinstaller.sourceforge.net.
Thoughts?
Regards, Upayavira
was somewhere else in a hidden repo, then maybe it is okay
to leave it, but not if it is in a public repo.
Regards, Upayavira
Jorg Heymans wrote:
Upayavira wrote:
1) It won't actually run Ant yet. It isn't likely to be much to make
it do it, but I haven't given it the time yet.
2) In its current state, it is GPL licenced. The author has said he's
happy to change licence
3) It includes GPL libraries. I'd need to see
Bertrand Delacretaz wrote:
Le 14 avr. 05, à 11:15, Upayavira a écrit :
...In the work I've been doing with Snapbridge recently, I came across
a rather neat GUI installer, that basically provides a front end to
Ant...
I remember a discussion a while ago about building a WebStart-based
installer
Antonio Gallardo wrote:
On Jue, 14 de Abril de 2005, 10:20, Upayavira dijo:
Bertrand Delacretaz wrote:
Le 14 avr. 05, à 11:15, Upayavira a écrit :
...In the work I've been doing with Snapbridge recently, I came across
a rather neat GUI installer, that basically provides a front end to
Ant...
I
.
Regrards, Upayavira
Daniel Fagerstrom wrote:
Upayavira wrote:
Skip Carter wrote:
I'd rather not see one. At least if one is developed,
there needs remain to be a way to install from the command
line. ALL of my cocoon installations are on headless systems,
and some of them are remote, so a GUI is not really very
Peter Hunsberger wrote:
On 4/14/05, Upayavira [EMAIL PROTECTED] wrote:
Skip Carter wrote:
I'd rather not see one. At least if one is developed,
there needs remain to be a way to install from the command
line. ALL of my cocoon installations are on headless systems,
and some of them are remote, so
it cohesive, then the more the better.
Thanks for your comments, and I look forward to seeing what you come up
with!
Regards, Upayavira
Sebastien Arbogast wrote:
Hi,
I may have something to suggest concernig the new documentation effort.
The main problem that I had to face while begining to work
Bertrand Delacretaz wrote:
Le 13 avr. 05, 10:30, Upayavira a crit :
...2) What myself and Reinhard have conceived is a container for ALL
docs. We need first of all to bring the reference docs across, and to
scrap a lot of the crud that has built up over the years. That, I
hope, will establish
-throughs we want, so that we can have
comprehensive coverage. In the meantime, I'd say just go ahead and write it!
Regards, Upayavira
on this in the next couple of
days. Other volunteers welcome.
Regards, Upayavira
Jeremy Quinn wrote:
On 13 Apr 2005, at 15:46, Upayavira wrote:
I have just done a huge commit (sorry!) of the old 2.1 documentation,
converted into a flat structure with the content formatted as HTML.
I've also committed a site.xml to go with this.
This means we're ready to start the job
Sylvain Wallez wrote:
Hi all,
I was reading http://wiki.apache.org/cocoon/CocoonPerformanceResults and
the nice graphics that were attached to this page on the cocoondev wiki
seem to have been lost.
Upayavira, our slashdotted infrastructure guy, any hint on how to have
them back? :-)
Our
for putting such stuff in COB-INF is that it will
not be accessible via a sitemap, and thus increases security a bit? That
presumably is the argument behind WEB-INF.
Regards, Upayavira
a tall order.
/aside
Regards, Upayavira
Bertrand Delacretaz wrote:
Le 11 avr. 05, à 12:02, Upayavira a écrit :
I've written a script that will convert old 2.1/2.2 documentation into
the proposed new format. However, because we're switching from a
hierarchical to a flat naming, we need a mapping between documents. I
have committed
Reinhard Poetz wrote:
Upayavira wrote:
Definitely. I will take this approach and commit the docs to the live
trunk docs repos with a prefix. Expect some big commits in the next
couple of days!
I'll prefix the blocks docs with c21-block-blockname, so that the
docs survive before we can move
sitemap for diferent dirs.
But what to do? AFAIK, we cannot implement that because the Stefano's -1? :-(
FWIW, stefano's -1 was for dynamic sitemaps, not for a context attribute
to map:mount.
Regards, Upayavira
Sylvain Wallez wrote:
Upayavira wrote:
Or unit/functional. That's actually the distinction isn't it?
Yep. That definitely sounds better.
But after more thinking I not sure we actually _need_ to make the
distinction: what about having HtmlUnitTestCase create upon first use an
embedded Jetty
/test/internal for current junit tests
- src/test/external for htmlunit tests.
Using the external name rather than htmlunit leaves room for other
external test tools such as httpunit.
Or unit/functional. That's actually the distinction isn't it?
Upayavira
[x] there is a chance I gonna make it
Upayavira
/viewcvs.cgi/cocoon/tags/
You'll see that the revision shown there is 158761. That would seem like
a pretty good number to go on.
Regards, Upayavira
David Crossley wrote:
Upayavira wrote:
Bertrand Delacretaz wrote:
Jeremy Quinn a ?crit :
Do you know if there will continue to be xml docs in the build?
AFAIK it's still being discussed, see the recent automatically
generating docs thread.
I would be reluctant to see the online docs go. It would
. Simply
adding another line into the meta-data file isn't likely to be disruptive.
There's my thoughts. Does that help?
Regards, Upayavira
Reinhard Poetz wrote:
Upayavira wrote:
Reinhard Poetz wrote:
David Crossley wrote:
Perhaps we should step back a bit and assess the situation. It seems
a cumbersome process to double-handle all of the source docs, just to
add some specially-generated docs. Would it help to put these special
docs
it someone would have to in some senses rewrite Forrest! Or at least put
together some simple sitemaps to make the content as it is structured
show up as sensible HTML.
Regards, Upayavira
, or as viewable
via Cocoon. Telling a beginner who wants to read the docs offline that
he has to go and download Forrest to find out how Cocoon works is just
not acceptable.
Regards, Upayavira
the samples into separate blocks? Are you going to do that
at the same time? ;-)
Regards, Upayavira
Michael Wechner wrote:
what about specifying the repo as parameter, e.g.
map:generate src=jcr://...
map:parameter name=repo value=.../
/map:generate
Because this is a source, not a generator. The parameter would be a
parameter to the generator.
Regards, Upayavira
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
, Upayavira
!
We would then just need to fill in the gaps, and we'd have some lovely
new docs.
Regards, Upayavira
That would be fab, Helma.
Regards, Upayavira
Linden H van der (MI) wrote:
As I've stumbled across this a few times already (and I'm not nearly as
much into Cocoon as you guys), I know what you mean. I'll try and modify
the current XSL code and put it in Bugzilla.
Bye, Helma
-Original
do it. It would simplify so many things dependency-wise.
Let's have the core samples as a block too, because you don't really
want them in a deployed Cocoon.
Regards, Upayavira
understanding of what the proposals are. In the meantime, let's start
writing some docs.
Regards, Upayavira
- but they're in
the distribution by default, always.
That's my thoughts on the subject.
Regards, Upayavira
the documents in cocoon/trunk/src/documentation,
Upayavira will ensure that all docs that differ from the 2.1 docs will
be saved.
Detailed explanations on how the new documentation system is supposed to
work can be found at
http://wiki.apache.org/cocoon/CocoonDocumentationSystemSUMMARY
that Reinhard is doing. Sounds like you're
competent enough to do so.
Regards, Upayavira
Bertrand Delacretaz wrote:
Le 22 févr. 05, à 09:38, Reinhard Poetz a écrit :
...Before replacing the documents in cocoon/trunk/src/documentation,
Upayavira will ensure that all docs that differ from the 2.1 docs will
be saved...
Saved = moved to a directory where they can easily be found while
Bart Molenkamp wrote:
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 17, 2005 5:19 PM
To: dev@cocoon.apache.org
Subject: Re: Write binary data to output stream from flow
Bart Molenkamp wrote:
Hi,
Is it possible to write binary data to the HTTP
of javascript object as well), you would do well to use JXPath to
get at the values, hence specifying the names of these values as XPath
expressions.
You end up with something more generic component that way that isn't
specifically targetted at your problem.
Make sense?
Regards, Upayavira
-Original
definition or via the map:read
mime-type=xxx approach, or however the ResourceReader currently works.
Regards, Upayavira
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Friday, February 18, 2005 11:06 AM
To: dev@cocoon.apache.org
Subject: Re: Write binary data to output stream
Bart Molenkamp wrote:
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Friday, February 18, 2005 11:20 AM
To: dev@cocoon.apache.org
Subject: Re: Write binary data to output stream from flow
Bart Molenkamp wrote:
Yes, it makes even better sense.
Would such a more generic
a source such as:
stream:/my/path/to/JXPath/Object(application/zip)
But that seems to be abusing the URL metaphor a bit too much for me.
Regards, Upayavira
-Original Message-
From: Upayavira [mailto:[EMAIL PROTECTED]
Sent: Friday, February 18, 2005 11:47 AM
To: dev@cocoon.apache.org
Subject: Re
a getInputStream() method.
But a source similar to that, a StreamSource, could serve the same
purpose in combination with the flow-attr input module. But, for some
reason, this approach makes me feel a little uneasy.
Regards, Upayavira
be careful if you had changes in one of the
four moved blocks. In this case, sorry for any inconveniences!)
Have you tried checking out the external references via http rather than
https? Just want to be sure that they'll still work for non-committers
using http.
Regards, Upayavira
, Upayavira
Torsten Curdt wrote:
Yepp ...yepp ...yepp
Guys, maybe we should get together
more often. I found this always
very helpful...
I'm up for it. And ask for some corporate sponsorship for those in far
and distant lands. A two day hackathon somewhere in Europe. I like the idea.
Regards, Upayavira
David Crossley wrote:
Reinhard Poetz wrote:
Last week Upayavira and I spent some time to overhaul the structure of the
two
document repositories:
- http://brutus.apache.org/docs/build/cocoon-doco-2-2/
- http://brutus.apache.org/docs/build/cocoon-doco-global/
We think that it covers all Cocoon
David Crossley wrote:
Upayavira wrote:
David Crossley wrote:
Here is one thing that i cannot grasp yet:
How will the automatically generated Sitemap Component Documentation
(i.e. the old /userdocs/) fit in with these static repositories?
Currently we need to run 'build docs' to prepare them
be used instead - use the Configurable interface for your component.
Does that make any sense?
Regards, Upayavira
into our sitemaps, so maybe we
can work around some usage of xpatch. But there may be others (web.xml,
etc) where it is still required.
I also saw a doc someone posted on user list that looked like it could
make a useful brief how to install doc for Cocoon.
Regards, Upayavira
want is Forms in my
applications, I would like to rewrite those pages to use JXTG instead
of XSP. Any objections?
Ugo
+1000
+1 :-)
Upayavira
, but in a SVN way (i.e. make a copy). So, you can check it
out from:
http://svn.apache.org/repos/asf/cocoon/tags/RELEASE_2_1_6/
Regards, Upayavira
Carsten Ziegeler wrote:
Upayavira wrote:
Antonio Gallardo wrote:
If 2.1 will work without this feature = please remove it.
Cleaning the
house is good. ;-)
As is leaving things alone so you don't take the risk of breaking
things :-)
Exactly - and we should try to make sense out of our
as described on
http://cocoon.apache.org/community/contrib.html and attached it to
this mail.
Do I create an issue for this (haven't used bugzilla before)?
Yes, please do, and prepend the name of the issue with [PATCH]
Other than that, looks like you've done the job just right!
Regards, Upayavira
this is
the Cocoon Core Service Manager.
So what about using the CCSM acronym instead of ECM++?
+1
Maybe only CSM is enough. Will exists others C[fill a letter]SM or this is
the only one?
Tend to agree. CSM sounds good to me. But a good idea to rename it.
Upayavira
Sylvain Wallez wrote:
Upayavira wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hi all,
Doing some cleanup on the component management, I went into
o.a.c.Cocoon where a bootstrap service manager is created and setup
only to handle the case where the user would like to use parser
different
it. Cleaning the
house is good. ;-)
As is leaving things alone so you don't take the risk of breaking things :-)
Upayavira
and then later
synchronise with trunk?
I have just written up the RequestMethodSelector after an 'oh, aren't
the docs crap' complaint on user list, and am not sure whether to put it
in trunk as well or not.
Regards, Upayavira
it. So,
anyone, either update the page, or let me know here what this prop stuff
is all about, and I'l update the page.
Regards, Upayavira
301 - 400 of 893 matches
Mail list logo
