Hi all,
Seems like current 2.1 build is screwed up. A bit. Issues at hands are:
* jing is located in lib/optional but is used by build.xml. Is it used
anywhere else? If no, it must be moved to tools/lib
* commons-httpclient-20030210.jar is located in lib/optional but
xsp\SOAPHelper.java in
[EMAIL PROTECTED] wrote:
From: Steven Noels
It's some 120K of code being added to the core. Syntactical sugar for
the flow in the sitemap is essentially orthogonal to
JXTransformer/-Generator (and agreed upon IIUC), but moving this into
its own block might grow a better community wrt.
Sylvain Wallez wrote:
[EMAIL PROTECTED] wrote:
snip/
Although we can change the attribute of map:flow (type would be
more in accordance with other sitemap statements), it's content is
actually a Configuration object given to the chosen flow engine. For
type=JavaScript, it fully makes sense to
Steven Noels wrote:
The current setup of http://xml.apache.org/cocoon** is a redirect to
http://cocoon.apache.org/2.0{1} using this .htaccess file:
RedirectMatch permanent /cocoon(.*)$ http://cocoon.apache.org/2.0$1
... which means people who still use the old entry point will not be
aware of
Joerg Heinicke wrote:
A complete website update would take hours ... and megabytes ...
This was only the root directory (for removing links to invalid
mail-lists.html) and nearly 1 MB.
But it seems that I can not login on daedalus as written at daedalus.
Whom should I ask? Can someone else do
Reinhard Pötz wrote:
snip/
Thank you for voting/reading so far (13 items ;-)!
Reinhard,
This doco nicely summarizes what we have so far in the flow. And,
because it is already present, and was already dicussed/voted some time
ago, what here we are voting for? :)
Vadim
Reinhard Pötz wrote:
From: Vadim Gritsenko
Reinhard Pötz wrote:
snip/
Thank you for voting/reading so far (13 items ;-)!
Reinhard,
This doco nicely summarizes what we have so far in the flow. And,
because it is already present, and was already dicussed/voted
some time ago
Geoff Howard wrote:
We discussed this reoccuring problem recently and there was a sort of
consensus (http://marc.theaimsgroup.com/?t=10562336112r=1w=2) to
remove the link which currently exists from xml-cocoon2 to the
historical cocoon module and in its place create a real module at
Joerg Heinicke wrote:
Hello Vadim,
while in CygWin Cocoon 1.x build does not work,
Now it works.
;-P
Vadim
Ricardo Rocha wrote:
Matt Segeant wrote:
This is a proposal to support attribute value interpolation
(called attribute value templates in XSLT) in XSP.
+1,
I'd already voted this one on the XSP list, but it's important to
re-state support for a most useful feature
+0 from me too on a
Sylvain Wallez wrote:
...
IMO, the name should reflect the notion of Source and either traversal
or hierarchy. So what about SourceHierarchyGenerator (that's the name
of my implementation) or SourceTraversalGenerator ?
I would prefer something really simple; like SourceDirectoryGenerator.
Or
[EMAIL PROTECTED] wrote:
joerg 2003/07/12 06:30:02
--- JspGenerator.java 10 Jul 2003 23:38:04 - 1.3
+++ JspGenerator.java 12 Jul 2003 13:30:02 - 1.4
@@ -131,8 +131,6 @@
throw new ProcessingException(SAXException JspGenerator.generate(),e.getException());
[EMAIL PROTECTED] wrote:
gianugo 2003/07/11 03:32:35
src/blocks/webdav/lib slide-webdavlib.jar
Do we know the version number?
Vadim
[EMAIL PROTECTED] wrote:
+ pIt's also advisable to change your implementations from using
emLogEnabled/em
+ instead of emLoggable/em when it comes to logging in your components.
+ /p
... to change ... from using emLogEnabled/em
... instead of emLoggable/em
Is it me or
Gianugo Rabellino wrote:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
gianugo 2003/07/11 03:32:35
src/blocks/webdav/lib slide-webdavlib.jar
Do we know the version number?
Nope, it comes from the (long time) unreleased Slide CVS. I added a
timestamp though, isn't
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
+ pIt's also advisable to change your implementations
from using emLogEnabled/em
+ instead of emLoggable/em when it comes to
logging in your components.
+ /p
Stefano Mazzocchi wrote:
On Monday, Jul 14, 2003, at 11:20 America/Guayaquil, Geoff Howard wrote:
Christopher Oliver wrote:
Yes. That is a feature of the new FOM: it always creates a session.
The original API had createSession() and removeSession(). Those
functions were removed from FOM.
Christopher Oliver wrote:
Continuations do not require the session. But the session is needed to
support cases where you use JS global variables to share data between
multiple top level page flows. In your cases, there are no shared
variables or else there is only a single page flow. I guess
Christopher Oliver wrote:
Vadim Gritsenko wrote:
Is it possible to use application context to share those global
variables?
It's possible, but I don't see any benefit over using the session.
Memory consumption. Several people already chimed in that they want to
have session-less flows
Christopher Oliver wrote:
Vadim Gritsenko wrote:
Christopher Oliver wrote:
Vadim Gritsenko wrote:
Is it possible to use application context to share those global
variables?
It's possible, but I don't see any benefit over using the session.
Memory consumption. Several people already chimed
Christopher Oliver wrote:
-1 to having request or context scope.
...
Sorry, what I meant was that for the case you mention you don't need
the context. So for now I can't think of a reason why you need request
or context scope.
Actually, I've got an idea: session is not required too! :)
Christopher Oliver wrote:
Vadim,
Your observations are correct.
However, I just checked in a change to FOM_JavaScriptInterpreter that
causes it to only create a session if you actually modify global
variables. (Note: global constants do not cause a session to be
created). For example, if you
Steven Cummings wrote:
Hello,
Is it possible for javascript code in the flow engine to locate properties
files that it might need. I have a JAXBContext that I'm trying to use from the
javascript and i get
javax.xml.bind.JAXBException: Unable to locate jaxb.properties for package
Stefano Mazzocchi wrote:
On Monday, Jul 28, 2003, at 14:23 Europe/Rome, Sylvain Wallez wrote:
...
In other words, streamed requests aren't so much different from
regular requests : it's just that incoming data is more complex and
that decoding is not handled transparently by the servlet
Steven Cummings wrote:
--- Vadim Gritsenko [EMAIL PROTECTED] wrote:
Steven Cummings wrote:
Hello,
Is it possible for javascript code in the flow engine to locate properties
files that it might need. I have a JAXBContext that I'm trying to use from
the
javascript and i get
Stefano Mazzocchi wrote:
Cocoon is glue and duct tape for your web needs.
...
I propose to choose the humble one.
I guess we are all agree with your RT. What's next -- what we are going
to update? :)
Vadim
Carsten Ziegeler wrote:
So, by this, it means, we should only apply bug-fixes and docs to the
repository.
Up to the 2.1 release only. After that, 2.1.1-dev starts.
Now, I think this applies only to the core, we can still change the blocks,
at least the blocks marked as alpha.
Yes.
We now have
Hi guys,
Check out the samples. Most of them work ok, with the exception of i18n
samles -- click on content view or links view and see the results. i18n
samples use aggregation and resources in the sitemap with the label on
one aggregated part. When this pipeline moved from the resource to the
Geoff Howard wrote:
Vadim Gritsenko wrote:
Hi guys,
Check out the samples. Most of them work ok, with the exception of
i18n samles -- click on content view or links view and see the
results. i18n samples use aggregation and resources in the sitemap
with the label on one aggregated part. When
Gianugo Rabellino wrote:
Vadim Gritsenko wrote:
Another thing to keep in mind is that if everybody starts developing
2.2 and nobody works on 2.1+, then it makes sense to copy all of the
blocks to 2.2 as well, and 2.1 will become historical.
Please don't call it like this. Let users have
Tetsuya Kitahata wrote:
The amazing thing is, you will be able to find this announcement from
http://jakarta.apache.org/
http://jakarta.apache.org/site/elsewhere.html#20030730.1
in a few hours, too.
Can somebody writeup something in our news? Jakarta will have our
news, and our news won't... Hm
Antonio Gallardo wrote:
Hugo Burm dijo:
For a long discussion about Hibernate versus JDO see a recent discussion
on www.theserverside.com.
Hi:
Can you point to a more specific page? :)
I guess this is the one:
Gianugo Rabellino wrote:
I want to propose Guido Casper ([EMAIL PROTECTED]) as a new Cocoon
committer.
+1
Vadim
Nicola Ken Barozzi wrote:
http://blog.xesoft.com/jon.lipsky/blog/Java/?permalink=workflow_viewlets.html
Have you seen one from the BEA's Workshop (8.1)? They've got workflow
editor and pageflow (struts app) gui editor.
Vadim
Nicola Ken Barozzi wrote:
Steven Noels wrote, On 31/07/2003 13.32:
On 31/07/2003 13:27 Stefano Mazzocchi wrote:
I removed references to the publishing framework and added a CSS
stylesheet to both the cocoon directory and lenya's using a
headinsidebody hack (dirty, but it works on all the
Stefano Mazzocchi wrote:
On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi
wrote:
http://blog.xesoft.com/jon.lipsky/blog/Java/
?permalink=workflow_viewlets.html
did you guys ever programmed java with JavaStudio? it was a nice
little app that sun released in the early
Joerg Heinicke wrote:
Vadim Gritsenko wrote:
On Firebird 0.6 the links are so sml...
I can't read it too (ie or esp. mozilla 1.4). At least one Ctrl-+ is
required. Mind increasing the font?
Vadim
You can configure a minimum font size in Mozilla :-)
You do recommend this to all
Olivier Billard wrote:
Hi Vadim !
Relatively to recent mails of the thread, you think it could work with
xsltc, if some offendering xsl were removed ?
Yes. Just added transform to xsl-dynamic-source:
xsl:stylesheet version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
Olivier Billard wrote:
What do you mean about Just added transform to xsl-dynamic-source ?
Meaning:
I've just added a transformation step to the xsl-dynamic-source matcher
to more closely reproduce your scenario and samples/sources/sitemap.xmap
now reads:
!-- Generate XSL source
Carsten Ziegeler wrote:
I just want to collect opinions how to manage the final release.
Now, it seems 2.1rc1 is relative stable, no real complains, some minor
issues but no showstoppers.
I know of two bugs ATM which are kind of bugging me:
1) broken tutorial due to missing support of action
Joerg Heinicke wrote:
Vadim Gritsenko wrote:
You can configure a minimum font size in Mozilla :-)
You do recommend this to all Cocoon users? Seriously? And what to do
about all the other web sites where font will become too large?
Vadim
No, to all Mozilla users. Because there are many
Gianugo Rabellino wrote:
Stephan Michels wrote:
Mmmh... collection it a bit too vague IMO. Why not keeping the
current
directory namespace ?
At least, we should agree on one name
SourceHierarchyGenerator - http://apache.org/cocoon/hierachy/1.0
SourceCollectionGenerator -
Elena Litani wrote:
Hi all,
The Xerces-J team is very happy to announce that version 2.5.0 of
Xerces-J is now available.
This release provides a partial partial implementation of the XML
Inclusions (XInclude) W3C Candidate Recommendation
Has anybody seen this / tried this with Cocoon?
Vadim
Reinhard Pötz wrote:
-Original Message-
From: Reinhard Pötz [mailto:[EMAIL PROTECTED]
Sent: Friday, August 01, 2003 4:21 PM
To: [EMAIL PROTECTED]
Subject: RE: Paginator and ImageReader -- core components?
Responding to Carsten's mail too:
Then (if anybody else is faster) I modify the
Ugo Cei wrote:
Ugo Cei wrote:
Christopher Oliver wrote:
FOM_Cocoon has Java methods to get the Request, Response, Session, and
Context, and ComponentManager.
But is it callable from Javascript? If I try to call
cocoon.getRequest() I get this exception:
Bertrand Delacretaz wrote:
Le Mercredi, 6 aoû 2003, à 07:03 Europe/Zurich, Mark Leicester a écrit :
...Attached is the block in a zip, and this is the gump entry (I
think this is
correct?):
I compiled your block and technically everything is ok, great!
I have a problem with the copyright
Sylvain Wallez wrote:
BTW, on my way to support legacy, I also supported non-namespaced
attributes on i18n: elements. This means one can write i18n:text
key=blah instead of i18n:text i18n:key=blah which always seemed
cumbersome to me.
Common sense tells me that i18n:text key=blah should be
Carsten Ziegeler wrote:
...
Hmm, yes, but we could start the 2.2 repo with the current core source,
so we have a starting point. I expect that blocks will require longer
discussions and I personally don't want to wait with 2.2 for this.
I'm wondering. What are you personally planning which
Miles Elam wrote:
Ummm... Quick question: What are the use cases for this that are not
handled by existing methods? I mean, couldn't this be handled with an
(as-yet unwritten) action?
Matcher *does* exist:
map:match pattern=*.doc
map:match type=wildcard-request-parameter
Sylvain Wallez wrote:
Bertrand Delacretaz wrote:
Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :
...But shouldn't we keep labels that are already used into pipelines
? E.g :
map:read src=docs/{1}.doc label=raw, xdoc/
map:generate src=docs/{1}.doc type=word2xml
Miles Elam wrote:
Sylvain Wallez wrote:
Go back to first post of this thread, where (last paragraph) I
proposed something similar. The whole discussion is about how we
could have a syntax which doesn't introduce such verbosity in the
sitemap.
Verbosity is not necessarily a bad thing. If
Upayavira wrote:
[here's a non-HTML version - mailer misbehaved again :-( ]
OT: Have you tried mozilla mail client?
* split the bean into a CocoonWrapper that handles configuring a Cocoon object
and handling a single request, and a CocoonBean which handles crawling
What is the API of these
Phil Shafer wrote:
I'm seeing an error when I use xsl:imports containing
cocoon: sources. During processing of the import sources,
ResourceReader.processStream() calls:
response.setHeader(Content-Length, Long.toString(contentLength));
But the response referenced is the _original_ (external)
Upayavira wrote:
...
Anyway, I've done some more research, including downloading the source
for Avalon (for the first time!) and stepped through the code for the
Store.
I don't know if this is a problem, but in AbstractJispFilesystemStore,
the get and store methods don't seem to match up:
Upayavira wrote:
Vadim,
How's about:
Better! :)
Vadim
---
Overview
The Cocoon Bean provides a Java programmatic interface for embedding
Cocoon into other applications.
Details
At present, the bean is mainly used for offline page generation.
However, there is no reason why it
Should we send this to [EMAIL PROTECTED] as well?
Vadim
Carsten Ziegeler wrote:
Apache Cocoon 2.1 Released
--
The Apache Cocoon Community is proud to announce the new release
of Apache Cocoon.
...
Upayavira wrote:
I've just committed some documentation for the CLI..
Points to note, in the page cli.html:
noteWhilst the xconf method provides access to more features, the
command line parameter method is more stable, as there are currently
plans to improve the xconf format to allow greater
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
snip/
Here is another wild (or not?) thought.
All this discussion comes down to the requirement of generating some
XML out of the content usually served by the reader, if that's
possible
Upayavira wrote:
...
Vadim's already answered you on that but another point is that I'm
pretty sure there's nothing wrong with the Store(s) or Cache because I
don't see this happening in the webapp. You could prove this to
yourself by configuring the max-objects param for transient-store in
Upayavira wrote:
[here's a non-HTML version - mailer misbehaved again :-( ]
I have on my system a substantially reworked CLI/bean. It is much better
componentised (rather than the monolithic bean), and should therefore be much
easier to understand and extend (how many of you avoid the
Jeremy Quinn wrote:
Dear All,
...
My hope is that this could constitute a sample of working with
FlowScript + JX + Hibernate. It would not be otherwise useful to
anyone, because it all depends on inIVA's copious data (which would
obviously not be supplied).
I would either supply the App as a
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
...
Hmm, yes, but we could start the 2.2 repo with the current core source,
so we have a starting point. I expect that blocks will require longer
discussions and I personally don't want to wait with 2.2
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
snip/
Here is another wild (or not?) thought.
All this discussion comes down to the requirement of generating
some XML out of the content usually
Upayavira wrote:
Vadim wrote:
* split the bean into a CocoonWrapper that handles configuring a
Cocoon object
and handling a single request, and a CocoonBean which handles
crawling
What is the API of these new beans? Please do not forget that
CocoonBean is out of the door with 2.1
[EMAIL PROTECTED] wrote:
s1 title=Overview
pThe Cocoon Bean provides a Java programmatic interface for offline
page and site generation
with Apache Cocoon.
/p
/s1
Ummm... I don't agree with this description. Cocoon bean should
Jeremy Quinn wrote:
On Thursday, August 14, 2003, at 06:29 PM, Vadim Gritsenko wrote:
Jeremy Quinn wrote:
...
should/can I add the Apache license to it?
Not sure that this is possible due to bindings to LGPL code.
Sorry I meant, should I be adding the Apache license to the Java
Jeremy Quinn wrote:
BTW: The Hibernate guys are now aware of the license problem, and
seem to be
willing to offer their api under a less restrictive license.
That is good news ...
Some BSD-like license for redistributing their binary code would be just
what we need. We don't need BSD-like
[EMAIL PROTECTED] wrote:
cziegeler2003/08/15 06:42:31
Modified:lib jars.xml
src/webapp/WEB-INF cocoon.xconf
Added: lib/core excalibur-store-20030815.jar
Removed: lib/core excalibur-store-20030726.jar
Log:
Updating to latest store version
Any chance of
Vadim Gritsenko wrote:
Reinhard Pötz wrote:
IMO a bug in Cocoon 2.1 that makes a 2.1.1 necessary, doesn't it? I
think many production environments depend on external sources and many
use proxy firewalls.
Without looking into the sources: could this be a problem with the
httpclient library?
Yahoo
[EMAIL PROTECTED] wrote:
haul2003/08/15 08:53:20
Modified:src/java/org/apache/cocoon/acting
AbstractValidatorAction.java
FormValidatorAction.java
SessionValidatorAction.java
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Just ran Cocoon build under optimize it. Not the clean build, but
second one, when there is nothing to do. It took 6 minutes on 1.6GHz
P4 desktop box. Guess where all this time has been spent? Logging!
45.26%: Project.fireMessageLoggedEvent
Sylvain Wallez wrote:
Roger I Martin PhD wrote:
Hi,
Started working on a cvsclient logicsheet as a cocoon block but am
wondering if there is already such development or if anybody can
opine if it's worth it or not.
You should have a look the CVSSource project at
http://www.cocoondev.org :
Geoff Howard wrote:
Joerg Heinicke wrote:
...
GOT IT!!!
What ever node type this should be: ![if !IE] ![endif]
this is the reason for the exception. Why the explicite XPath works?
I don't know ... At other places in the same file these constructs
are placed in comments and don't disturb:
Geoff Howard wrote:
Joerg Heinicke wrote:
This poor guy has edited the complete cocoon.xconf by hand, what is
not that easy as you can imagine. Should we make the webapp target
the default one in 2.0 too or speaks anything against it?
I'd be +1. It's the 99% most used, it should be the
Upayavira wrote:
...
But we did document that the API of the bean was unstable. Doesn't
that mean we can change the API where necessary?
Ah, in this case we can. Unfortunately, class's Javadoc does not has
this indication.
How do you use Javadoc to indicate unstable?
pbWARNING:/b This
Phil Shafer wrote:
Vadim Gritsenko writes:
It's not concern of the resolver's user to fiddle with request /
response. If change to be made, it should be done in cocoon source
implementation.
This sounds right.
I think reader has a right to make this call unconditionally
I'd noticed that traffic is very low -- because I'm not getting all the
emails which I can see on marc. I hope that this is temprorary
situation, may be due to overloaded mail servers in between, and I hope
I'll get those emails eventually...
Vadim
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
One thing missing is passing information from the pipeline to the
components.
For example if you write this pipeline:
map:generate type=filteredFile src=afile.xml
map:parameter name=a parameter value=a value/
...
I assume that the src info and the
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Phil Shafer wrote:
Vadim Gritsenko writes:
Try the suggestion above.
Will do. Thanks for the help. Is there a PR open for this? Should
I open one?
I think there is no bug open for this. Also, I'd ping Carsten
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
snip/
Now, I guess this is very easy as we could create a response wrapper
for internal requests (we already have a request wrapper) and filter
the headers.
This reminds me some random thoughts I had
Upayavira wrote:
Vadim has just fixed a bug with the persistent cache not shutting down
properly. This means that the CLI has access to the Cocoon cache.
For a largely static site, should now be possible to have the CLI
crawl a site, purely with the intention of building up the cache,
which
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
It could be convinient if it would work. But it does not.
map:generator name=filteredFile
map:aggregate
map:part src=a/
map:part src=b/
map:part src=c/
/map:aggregate
map:transform type=xslt src=a.xsl/
map:transform
Marc Portier wrote:
snip/
There's already a parameters property in the cocoon object.
We can have :
function whatever() {
doSomething(cocoon.parameters.x, cocoon.parameters.y);
}
And nobody still answered the question: why passing of parameters into
the function
function whatever(x, y, z)
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
Steven Noels wrote:
Of course, I'm very confident that Carsten has done this with the best
possible intentions, but Contributions to the portal is hardly an
intuitive commit message, and a quick search for the three people
involved didn't
Carsten Ziegeler wrote:
Vadim Gritsenko wrote:
I noticed that jtidy has been moved out of html block and into
lib/optional. What will happen if I to remove jtidy from the
lib/optional? Will this break the build?
Yepp, you can see it in the gump.xml dependency description
Nicola Ken Barozzi wrote:
snip/
*IMPORTANT* (and the reason why I started the RT):
So in he CLI, instead of asking for the link view and then generate, I
simply ask Cocoon to insert a transformer that gathers links in the
same positions where the links view would.
This would make it possible
Gianugo Rabellino wrote:
Robert Simmons wrote:
snip/
Many open
source projects have yet to bridge this gulf and only a few have done it
sucessfully (apache web server, ant, log4j, tomcat, jboss). For
example, the
decision to NOT distribute a binary build of cocoon is a good example of
going in
Upayavira wrote:
Vadim Gritsenko wrote:
Nicola Ken Barozzi wrote:
snip/
*IMPORTANT* (and the reason why I started the RT):
So in he CLI, instead of asking for the link view and then generate,
I simply ask Cocoon to insert a transformer that gathers links in
the same positions where the links
Robert Simmons wrote:
Uhh .. I dont get how that FAQ answers me. I dont need the pretty print in
production, just in development. It would be cool if I could use a cocoon view
to do it.
This would be more to the point:
http://cocoon.apache.org/2.1/userdocs/serializers/xml-serializer.html
See
Antonio Gallardo wrote:
Andrew Savory dijo:
On Fri, 29 Aug 2003, Antonio Gallardo wrote:
It seems like our server daedalus.apache.org is being blocked by the
black-hole list http://relays.osirusoft.com/.
The osirusoft black-hole list has been shut down due to a denial of
service
Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move already in bugzilla:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Triggered by the recent discussions about using log4j,
I propose that we move from the deprecated LogKitManager
to the new LoggerManager. This will make using log4j much
easier (and I would implement that then next).
There is a patch for the move
Carsten Ziegeler wrote:
joke
Ah, btw. I will replace ECM with fortress over the weekend. Any problems
with that?
Yep. Aren't we supposed to use Merlin instead? I'm checking in the code
as we speak...
/joke
Vadim
Geoff Howard wrote:
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
...
Ok, great. Does anybody have a problem with the proposed file
system layout?
AFAIU, blocks are expanded into WEB-INF/blocks/\d+/ directories:
By default - but as I understood Stefano's last email, it should
Berin Loritsch wrote:
The new Cocoon should be able to use the new Fortress container. This
should
have little to no impact on component writers. It boasts faster
startup, and
it provides easier component definition. I will be happy to do the work.
+1 from me.
+1, but I (still) would like
Reinhard Poetz wrote:
a comment by Vadim:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=106096301526641w=2
My comment has nothing to do with proxies. As Joerg found out, this is
the problem with M$ html extensions and XPath:
beware of snips/
Berin Loritsch wrote:
The above in Fortress would be redone as:
jdbc-datasource id=foo/
j2ee-datasource id=bar/
...
In Fortress, you can do things the old ECM way, or you can incorporate
the ID
to get whichever component you want and bypass the selector completely
like
this:
Jeff Ramsdale wrote:
If all the cool features that users want to play with are in the HEAD via
Subversion, you might think about easing the path to entry for the new
user...
Ain't this (http://cvs.apache.org/snapshots/cocoon-2.1/) easy enough? :)
Vadim
David Crossley wrote:
Are the HTML files that make the /dist/cocoon/ page
under cvs control somewhere or do i just edit them
in place?
No, there are not under CVS (hint: there is no CVS directory).
Feel free to add them to, say, cocoon-site/dist. Don't forget images
sub-dir and 3 .htaccess
Sylvain Wallez wrote:
Tuomo L wrote:
It would be convinient,
if one could use a protocolthat defines a source (FilePart) located
in memory.
This could be for example: multipart://foo.zip . Then it would
be possible to extract that in-memory zip-file to the target-dir.
Is this possible already,
1 - 100 of 2061 matches
Mail list logo
