Re: [RT] seven good reasons to close down users@cocoon.apache.org
Geert Josten wrote: ... Too bad you cannot cross-post between the two lists, that alone could have made things easier. The developer list should receive mails also from the user list with [Users] prepended. In this way developers get user mails, but users don't need to read all the longwinding discussions about internals (which tend to frighten some). -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [GT2005] Jotspot?
Ugo Cei wrote: Il giorno 03/ott/05, alle 10:38, Arje Cahn ha scritto: Stefano was talking about JotSpot in his RT; did anyone try this? JotSpot Live [1] seems to be the SubEthaEdit-for-those-without-a-Mac (indeed, I'm talking purely for myself ;-) ). Another product in this area is Writeboard http://www.writeboard.com. JotSpot is sold as a real-time collaborative environment, while Writeboard is not. OTOH, Writeboard is free, while JotSpot Live is free for max. 5 pages, which should be enough for the GT. I haven't tried any of them yet, but i read a couple reviews on www.solutionwatch.com Gobby http://socialsoftware.weblogsinc.com/entry/1234000410060570/ http://gobby.0x539.de/ -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Is Cocoon Obsolete?
Stefano Mazzocchi wrote: My life regarding software goes thru phases. A phase transition is when you strongly believe in something, then you strongly change your mind. Others call it a 'revelation', others think you lost your mind. I wrote Cocoon as a way to help achieving a more coherent look and feel for the apache web sites. It was way overdesigned for that, so much that we created another project for that (Forrest) which is still overdesigned (even if it got a lot done). It's funny how I was thinking about this lately... Forrest overdesigned? Yup. Got a lot done? You are being too generous :-) If I want to have a site with a consistent look, I would simply have all content in HTML, a css file, some images, and it's done. Cocoon is not dead, it's just that the reasons why it was created in the first place are no longer so relevant. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: JCI NoSuchMethod in trunk
Carsten Ziegeler wrote: Did you make a m2 clean:clean before? Boy, clean:clean is s /neat/ ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Do we want a GUI installer?
Upayavira wrote: ... Do we need to include a libary to achieve a better LF? What is the current way in the Java world? If we do, we need to make sure that we choose one that is licenced in a compatible way to ASL. Thus, [2], which is LGPL, is not compatible. I know JGoodies is BSD, but don't know if it is any good. Any Java Swing gurus here who can give a little guidance? IMHO, if a GUI feels ugly, the first thing to do is to rethink the layout. From teh screenshots I saw here it's not qhat I would call a standard layout. Then set the look and feel of the native platform (please no metal), add icons, set the spacing between components, use SwingWorker to manage long-running actions... and thing will start to look nice. Other things can be done like setting rollover images for buttons, using more advanced components for some parts of the UI (swinglabs and l2fprod), using progress bars and statusbar for more info to the user, add a splash, tweak font, etc. Only *then* one can think of changing the lf, but usually it's not needed. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Maven, Gump and Blocks
Carsten Ziegeler wrote: ... Now, we could for example use continuum - whatever that means... But perhaps pushing gump and maven a little bit could help. http://wiki.apache.org/gump/GumpAndMaven -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [2.2] Past, present and future of the maven build
Joerg Heinicke wrote: On 31.08.2005 09:16, Nicola Ken Barozzi wrote: ... IMNSHO it's not about Maven but about establishing correct build dependencies. Maven is made in a way that enforces it, but it doesn't mean that it's not correct. It's a problem of precondition vs. positive consequence. I'm not against fixing the issues in our code base (indepently on Maven or Ant), but I have a problem enforcing this step instead of encouraging it. Discussions get forgotten, just code remains. Once it's done, will anyone complain? The real point is: are you ok with this being fixed? Remember that it's a need of the project, regardless the build system. Once you reply yes, the fact that Maven makes good use of it is not a problem anymore, but a feature. :-D -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [2.2] Past, present and future of the maven build
Joerg Heinicke wrote: On 30.08.2005 17:31, Ralph Goers wrote: ... So to summarize, I would suggest that it would be a good idea for each component - be it core or a block - to have api, impl, test and samples projects. Did I mention that I hate tools needing changes in the subject they should work on to make them work? The above scenario and the other mentioned necessary restructurings were the reason why I ever were against a change of the build system to Maven. Ok, we really have a problem with our current build system. Nobody (me included) started with another solution like Ant 1.6 or similar. The Maven fraction started now to address the problem and I'm ok with it. The above rant probably just shows I'm a smart-ass ;-) If you, or me, or anyone would have really gone deep in fixing the Ant build system, we would have been forced to do the same restructuring. IMNSHO it's not about Maven but about establishing correct build dependencies. Maven is made in a way that enforces it, but it doesn't mean that it's not correct. :-D -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The impact of using OSGi
Niclas Hedhman wrote: On Thursday 11 August 2005 06:34, Vadim Gritsenko wrote: Isn't it the first goal to make (any) existing block (with no code modifications) run under OSGi? AFAIU, Existing blocks would run unchanged in the ECM-OSGi bridge bundle. I think Daniel is talking real blocks here, and I think that would require the blocks to have OSGi code in them, at least for the Bundle Activator and ServiceFactory. Of course there is an option to make a Cocoon specific abstraction level on top of the basic OSGi mechanisms, but to me it seems to only hamper the progress, resulting in endless debates of what to expose and not. This had come up during the first Blockathon day when I was present, and it seemed to me that there were no real objections. OSGi is not a plain POJO system, and in part this is nice as it does not depart too much from some Avalon constructs. Put the stick in the ground. Declare OSGi bundles is the plugin mechanism for Cocoon. Then move from there. :o) Build it, show it, and if there are objections, let them be in code. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Suggestion for XHTMLSerializer
Joerg Heinicke wrote: On 08.08.2005 21:30, Vadim Gritsenko wrote: ... Moreover, I don't see why go all religious on simple and (as it seems) useful idea of XSLSerializer. We do have FOP, Batik, etc serializers - why not Trax. I don't see how they compare. Furthermore there were reasons for not using xsl:output information, but putting it into serializer component declaration. Shall they no longer be valid? Blocking others on implementing something that they will use, while you will not use it and while this will not affect your usage, is always a bad idea. I have resisted for years in putting in features in the exception handling in a similar way, only to find that afterwards they got implemented without any real harm. In the end, I just prevented others from doing something they wanted. It was a bad thing to do. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The impact of using OSGi
Torsten Curdt wrote: ... but I just wanted to expose the mental connections that I've been making last week: if we consider moving to Maven, this might be the right time to do it, or at least try. Yep. +1! ...I know there are quite diverse feelings about the build system ...but I would love to see that happen. I have always - and also at fault - criticized Maven as a build system. That was Maven 1. Maven 2 is an order of magnitude better, and has very good design considerations. I think Cocoon must try using it now: if it works as it should, it will be of great help. If not, it has been at least tried. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Implementing map:mount... in Forrest Locationmap
Unico Hommes wrote: I don't think the locationmap has the growth potential of the sitemap. After the addition of mounting semantics the locationmap is probably done. My impression too. Doing the minimum that we need now is the best thing to do IMHO. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [osgi] Changing framework?
Daniel Fagerstrom wrote: Torsten Curdt wrote: Maybe I should just shut up and let Daniel continue with his awesome job ...but (there is always a but) I hope that you and everyone else speaks up and rise your concerns if you have any. In theory, in a perfect world, with all the time and will, with plenty of developers... I would have Torsten's same concerns. We need community involvement in this area sooner rather than later if we really want real blocks. In practice, we *desperately* need real blocks if we want to go ahead. This is much more important than any lock-in on another container. ... TBH, we have discussed containers for years, forked Cocoon a couple of times and Pier have even implemented an own kernel, without getting that much closer to real blocks. And today we have fewer active developers with container implementation competence and interest than we had a year or two ago. I agree in full. Overall, OSGI seems the best bet ATM, since Eclipse will remain for years, and presumably will not change framework soon. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Vote] Reduce dependencies to LogKit
Carsten Ziegeler wrote: ... We remove all direct dependencies to LogKit. +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Docs] A proposed revision, four weeks for Cocoon, and a smattering of Julie Andrews
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 into the format required by Daisy should have a look at the project sitemap where he will find some pipelines that should be helpful. If Daisy uses HTML, then it can use Forrest to convert it all using the plain-dev skin. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Block builder and deployer
Unico Hommes wrote: ... Exactly my thinking. In fact the reason I asked is that I was thinking of starting a Maven2 plugin for cocoon. I've been looking at the emerging Maven2 effort that is due to come out this summer and I think its going to be a killer. IIUC I can just start that in the whiteboard without a vote right? Yes. Maven2 is very interesting: it seems that most architectural shortcomings of Maven 1 have been fixed. I have written an xsl that converts the gump descriptor in the block.xml files, I just need to test it. I also want to use the Maven Ant tasks to download the jars needed, as already voted on this list. For this, and to be able to collaborate on transitive dependencies with the other projects, we will need to create also a pom.xml for each block, which would help also your effort for Maven 2. BTW, the current schema is inadeguate for MAven2: libraries lib id=avalon-framework-api location=core/ lib id=avalon-framework-impl location=core/ lib id=excalibur-xmlutil location=core/ lib id=excalibur-pool location=core/ lib id=excalibur-sourceresolve location=core/ /libraries I'll have to change it to mimic the Maven pom library entries. OTOMH, maybe it may also be beneficial to use the Maven2 directory project layout, at least for blocks. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Forrest Daisy integration scenarios
Steven Noels wrote: ... What do people think? I think that we need people that write documentation, not a tool. I'll think about it again when we have 10 doc writers sending patches and files that we are not able to manage. For now converting all documentation files to plain html and adding a link from every page to the svn version would certainly make things easy enough for most doc writers. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Forrest Daisy integration scenarios
Steven Noels wrote: ... Again, I'm not pushing - consider me a dis-interested, yet friendly party. I'm quite convinced though that documentation committers are currently passively discouraged by the patch/mail mechanism. Remember what started the Cocoon Wiki? Content (Leigh Dodds) + platform (JSPWiki). Leigh had valuable content to offer, and the format was a mere side effect of his preferred authoring tool. Hmmm... I guess I'm wrong, and the current system is a too high barrier to entry: the wiki example is a good one. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [VOTE] Removing author tags
Vadim Gritsenko wrote: ... Just for fun, and for meaningless PR statements like Cocoon is a result of work of 12345 developers! 8-O, we can aggregate all names of all contributors into one file. Cool! :-D In this case we have change the thread to: [VOTE] Refactor @author tags in a single file :-P -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [PROPOSAL] Download of jars with Maven ant tasks
David Crossley wrote: How do artifacts get into the remote Maven respository and how are they guaranteed to be the legitimate file? We don't necessarily have to use Maven's central repository, we can make our own repository with only the jars that we need and use that. In this way we would be sure of what we get. In the long run, it would be beneficial IMHO to help Maven in this regard, so that it can download jars from the normal Apache artifact publishing system. This would also have th ebenefit of not duplicating the jars between repositories (this duplicates downloads). -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [PROPOSAL] Download of jars with Maven ant tasks
Nicola Ken Barozzi wrote: ... We don't necessarily have to use Maven's central repository, we can make our own repository with only the jars that we need and use that. BTW, from an implementation POV IMHO it's better to start this way, as it's more incremental and solves one problem at a time without also starting to download jars from a remote repository. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
[PROPOSAL] Download of jars with Maven ant tasks
Some time ago, it was noted that the usage of a jar download and handling mechanism would greatly help Cocoon, because it makes it easy to share jars and to download only the ones needed. Ivy was proposed as a possible solution, but I suggested instead to use the Maven code, for the sake of not duplicating efforts; unfortunately at that time it was not ready and the proposal stalled. Finally, Maven has released tasks that enable Ant builds to use the artifact handling [1]. Isn't it time that we actually do it? :-) [1] http://maven.apache.org/maven2/ant-tasks.html PS: Please no discussions about Ant sucks, Maven sucks, mine is bigger than your's. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Ann/RFC] Virtual Sitemap Components
Daniel Fagerstrom wrote: ... So I don't see this so much as an implementation question as a conceptual question. Are we considering the VPCs as sitemap components or something else, to me they look like sitemap components. To me, a VPC is a better _resource_: IMHO it should be on the same level. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] composition vs. inheritance in blocks
Daniel Fagerstrom wrote: ... This means IMO that we have to spend time discussing things even if it in the short time horizont and for ones own goals whould have seemed more productive to just commit some code. Or commit two codes in separate branches and see what works best. OTOMH, all this smells a lot like the Microsoft COM model versus language features. It may be beneficial to read things on the Microsoft Component Object Model, as IIRC it used composition instead of inheritance, with analogous reasoning. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [proposal] move cforms in core
Stefano Mazzocchi wrote: Ralph Goers wrote: ... I'd like to hear why you think cforms should not be a block. Because having it as a block makes it really hard to answer the question: what is cocoon and what does it provide me. Hmmm... I think it's useful to have a list of things that cocoon comes with and a form handling framework is something that *must* be part of the core. Code-wise, putting cforms in the same java build of the cocoon core is wrong, as it does not enforce proper layering. I mean, the Cocoon core should not depend on cforms, /code-wise/. So, from this POV, cforms should still be a separate compilation step after the cocoon core; this does not mean that it has to be a block. It's not the first time that we come up with the need of a separate compilation step without making it a block (remember the modules?). -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] How scripting made me hate java
Carsten Ziegeler wrote: ... So, again: everyone is invited to join the party. Open Source is either driven by itch scratching (well, not always, but that's not important here), so if it itches, do something about it, that's all I can say. +1 I'll also like to add that committers should learn to not interfere with others' work unless it's *against* the good of Cocoon, and not only because it's not what he/she simply prefers. A good positive example is how Stefano let Actions get into Cocoon even if he was not sure about them. They were of use and a better alternative came up anyway. A good negative example is how how I blocked error handling features and site pass-through stuff. With time I needed them and also took part in putting them in. If committers were more tolerant on non-critical changes that other do, then committers like you, Carsten, would not feel in danger of being blocked by death by discussion. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] How scripting made me hate java
Stefano Mazzocchi wrote: ... This is why I think we should make an effort to think about how we can solve this time/cognitive-energy discrepancy between the scripting and the java try/fail cycle. +1 In fact, for users, xslt in Cocoon is cool because you get instant feedback, and the current sitemap has really made things fly because changes are active right away. For the core developers, AFAIK, there is only one way of dealing with this, and it's modularization. Smaller blocks are easier to understand, and faster to build and check. Forrest has seen revived interest since we have inserted a rudimentary plugin architecture. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Management Prototype?
Carsten Ziegeler wrote: ... I know that there are a lot of pros and cons for/against JMX - the discussion on the geronimo list is a good example of this. But it seems that every project is using JMX, so imho we shouldn't invent something different. Java 5 is using JMX to expose itself for monitoring. At this point IMO there is no real justification for anything other than JMX for management. +0 (good idea, no time for help) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [proposal] Cocoon documentation system
Reinhard Poetz wrote: Stefano Mazzocchi wrote: ... tell you what. forget about it for now. Think about going dynamic and later we'll find a way to make a persistent copy of that (either via forrest or simply by wget or something) +1 Forrest - pardon my rudeness - sucks as a static site generation system. I can't wait to have it shine as a dynamic system :-) point taken :-) here my next steps: - adapt the proposal so that it reflects the results of the discussion - same for the two demo repositories - implement the web application For historical reasons, and for collaboration opportunity, Cocoon committers have committer access to the Forrest SVN repository. I'd personally be happy if you would like to work on this in the Forrest repo, and I'm positively sure that there would be no objections from other Forrest participants :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [proposal] Cocoon documentation system
Reinhard Poetz wrote: ... ... and if there is no other way, I have ideas to perfectly work around the ASF infrastructure without having to forbear from online editing. IMHO enough bike-shedding on this thread. You know what is available, you know what you want to do. Whatever you do or choose, I'll be very happy :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Importing libraries from ibiblio
Sylvain Wallez wrote: ... What that means is that we can create the list of jars to download from our jars.xml or the gump descriptor, and have them automatically downloaded from the ibiblio repo. Very few modifications on the current build are needed. +1 to use a jar repository +1 to use a Maven repository, so that users can reuse their local Maven-downloaded jars reducing bandwidth usage and download times +1 to using Maven Wagon to download the artifacts -1 to using any download mechanism different from Maven Wagon or pure http get If we want to use the Maven repository system, it's better to stick with the Maven implementation, that is supported. ATM it doesn't have an Ant task anymore, but over at [EMAIL PROTECTED] I have understood that they agreed to add it back. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [proposal] Cocoon documentation system
Reinhard Poetz wrote: At http://wiki.apache.org/cocoon/CocoonDocumentationSystem I propose the architecture of a new extensible documentation system. I am *strongly* in favor of plain html as a source, as Forrest renders it nicely; the Incubator website is now all using html as a source format. Also, I don't see the need for a separate metadata file, which would duplicate stuff that is in SVN and in the source file. Comment file handling can be added as a Forrest plugin; I prefer it separate because in fact it *is* separate. Maybe putting the comments in a doc.comments directory, with each a separate html file would be nice. I added my comments to the Wiki BTW. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Importing libraries from ibiblio
Sylvain Wallez wrote: Nicola Ken Barozzi wrote: ... +1 to using Maven Wagon to download the artifacts Didn't knew about this. Interesting, but is it visible somewhere else than in the CVS [1]? No. We could prod them though :-) I couldn't find it on the maven site. Also, is there an Ant task using Wagon? There was, they deleted it, now should add it back IIUC. ... If we want to use the Maven repository system, it's better to stick with the Maven implementation, that is supported. ATM it doesn't have an Ant task anymore, but over at [EMAIL PROTECTED] I have understood that they agreed to add it back. I'm all for a Maven-supported solution, but do we want to wait until Ant and Maven agree on something common when we have today a lightweight tool that can do the job? There is already agreement (@see [EMAIL PROTECTED]), but we don't need it, as Wagon is all we need ATM... I think we should help Maven do a point release and use that. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [VOTE] Creation of a french-speaking users list
Matthew Langham wrote: ... However I also see a problem in having additional channels in _any_ other language because it would essentially mean that people would probably only post to their native list (which again is understandable). But this would eventually reduce the common discussion on the main list. I think that if a person knows English well enough, he would still post in English, because he knows that on that list he will find more help and developers. This is just about giving an extra chance to people that would not participate in English, still to participate. Moreover it's an experiment, nothing is set in stone, let's see how it works out and then decide. Community refactoring :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Update to build system: location of blocks and gump
Nicola Ken Barozzi wrote: ... Because in fact our artifacts, that are searched by Gump in the 'work' Rats, I meant 'home' :-/ The home directory for a project is the directory which contains the files referenceable by another project. dir, are in the 'build' dir that is nested, IOW found relative to the project 'src' dir (what we would call 'base' dir). something like $srcdir/[EMAIL PROTECTED]/build -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
[Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)
Carsten Ziegeler wrote:
Stefano Mazzocchi wrote:
Carsten Ziegeler wrote:
How about leaving everything as is and just change the default logger
to be log4j instead of logkit?
Hm, yeah, why not :( It seems that everyone is using different logging
approaches, so a consensus is impossible. Sigh.
Wait, not all is lost.
Let's restart with the points I think we agree upon.
1: we want to get rid of Avalon dependency
- get rid of logkit
2: there seems to be a general like of log4j as an implementation
- use log4j as a standard implementation
3: we want a logging abstraction, not be tied to a concrete impl
- use commons logging or UGLI
These points have brought us to almost say yes to Commons Logging +
Log4j as predefined implementation.
Then I came up with proposing UGLI as an alternative abstraction, as it
has the *same* advantages of commons logging without the configuration
nightmare drawbacks, has some extra niceties, and is supported by log4j,
which is the implementation that we tend to prefer.
Now, it seems to me that nobody is against UGLI instead of commons
logging for a logging abstraction, as all things against UGLI have
nothing to do with the comparison with commons logging but just about
the extra features it has, which seem not so important.
Now, I propose that we use UGLI as a logging abstraction and log4j as
the predefined logging package.
Here is the UGLI logging interface [1].
If you prefer commons logging over it, please write a technical
motivation about it.
package org.apache.ugli;
public interface ULogger {
public boolean isDebugEnabled();
public void debug(Object msg);
public void debug(Object parameterizedMsg, Object param1);
public void debug(String parameterizedMsg, Object param1,
Object param2);
public void debug(Object msg, Throwable t);
public boolean isInfoEnabled();
public void info(Object msg);
public void info(Object parameterizedMsg, Object param1);
public void info(String parameterizedMsg, Object param1,
Object param2);
public void info(Object msg, Throwable t);
public boolean isWarnEnabled();
public void warn(Object msg);
public void warn(Object parameterizedMsg, Object param1);
public void warn(String parameterizedMsg, Object param1,
Object param2);
public void warn(Object msg, Throwable t);
public boolean isErrorEnabled();
public void error(Object msg);
public void error(Object parameterizedMsg, Object param1);
public void error(String parameterizedMsg, Object param1,
Object param2);
public void error(Object msg, Throwable t);
}
http://cvs.apache.org/viewcvs.cgi/logging-log4j/src/java/org/apache/ugli/ULogger.java?rev=1.2view=markup
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: [RT] Escaping Sitemap Hell
Stefano Mazzocchi wrote:
Daniel Fagerstrom wrote:
...
A real map for the site should be tree structured like the linkmap in
forrest. Take a look at the example in [1], (I don't suggest using the
free form XML, something stricter is required). Such a tree model
will also help in planning the URI space as it gives a good overview
of it.
Forrest and cocoon serve different purposes.
While I totally welcome the fact that Forrest has such linkmaps, I
don't think they are general-enough concepts to drive the entire
framework. They are fine as specific cases, especially appealing for a
website generation facility like forrest, but as a general concept is
too weak.
While I agree with your reply, I think that I understand what problem
Daniel thinks he sees.
A sitemap is not the _map_ of a _site_.
That's why we made site.xml.
But saying that this should drive processing is IMHO not correct. In
fact, it's the opposite. We made the site.xml stuff in a different file
so that it would *not* interfere with processing.
...
Choosing Production Pipeline
...
Now instead of having the rule:
*.x.y.z == XYZPipeline
we have
* where repository:{1} have properites {x, y, z} == XYZPipeline
or
* where repository:{1}.x.y.z exists == XYZPipeline
Oh, a rule system for sitemap!
h, interesting... know what? the above smells a *lot* like you are
querying RDF. h...
At Forrest, we have done a similar thing, and are still in the process
of finishing it. IT states something like this:
Forrest processing should not be tied to URLs.
IOW, Forrest should not process a file differently just because it's in
a particular directory, but using other characteristics, like mime-type,
DTD, schema, etc. For us, an URL is a partitioning decision of the
content creator, not of the application creator.
Many sites fail to do this, and URL matching has become the easiest way
of partitioning Cocoon's processing, although not the best.
You can make your own matcher... and here is where we should
concentrate, by defining new blueprints that don't use the URL as a
matching system.
Forrest is doing it for docs... someone else can do it for apps :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: [Proposal] Use UGLI as logging abstraction (Re: [RT] Logging in 2.2)
Torsten Curdt wrote:
If you prefer commons logging over it, please write a technical
motivation about it.
As I already said: I don't see the point of this parameter stuff.
Then don't use the parameter stuff.
IMO this only leads to mixing of concepts.
What concepts? Remember that python and Java 1.5 have this capability,
because it's useful... are they both so wrong?
Some people will
use the {} some won't. To be honest I would not feel very happy
with UGLI since IMHO this interface is only half-backed. Sorry.
Half baked because it has the parameter stuff?
Remember that log4j uses that interface. Is log4j also half-baked?
...and I don't see point of getting rid of the Avalon Logger
dependency and introducing the UGLI dependency instead. Only
because we want to get rid of Avalon?
Yes.
Is there any technical reason to switch from the Avalon Logger
abstraction?
No.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: [RT] Logging in 2.2
Carsten Ziegeler wrote: ... If we still want to provide flexibility, we could opt for commons-logging. In this case, brave users can configure logkit as the logger for commons-logging and they are happy as well. Think again before adopting the commons-logging API http://www.qos.ch/logging/thinkAgain.jsp Rod Waldhoff's Weblog: Commons Logging was my fault http://radio.weblogs.com/0122027/2003/08/15.html I would support this instead: Universal and Generic Logging Interface (UGLI) http://logging.apache.org/log4j/docs/ugli.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Logging in 2.2
Antonio Gallardo wrote:
...
Please have a look at the Torsten suggestions, looks good too:
http://just4log.sourceforge.net
+1 too.
I saw that too, but UGLI should not need that extra isLogEnabled stuff
in any case.
BTW, I love the way this makes one write log messages, it's what we have
in POI, and is very convenient.
Ceki wrote:
As noted in my previous message, UGLI also supports parameterized log
messages obliterating the need to surround log messages with
logger.isXXXEnabled checks.
Instead of writing:
if(logger.isDebugEnabled()) {
logger.debug(User with +id+ entered wrong query string
[+query]. );
}
you can just write:
logger.debug(User with {} entered wrong query string [{}]., id,
query);
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: [RT] Logging in 2.2
Keeping it simple... we all kinda want log4j but don't want to link
directly to the implementation... UGLI is the lightweight frontend that
gives us log4j with pluggability [1].
Note that log4j version 1.3 and later support UGLI directly as log4j
itself is implemented in terms of the UGLI interface.
Antonio Gallardo wrote:
...
1-UGLI: If Torsten comment related to the 2 parameter limit in UGLI is
true, then UGLI is not a serious proposal.
That's not the goal of UGLI, just an extra feature.
Please read this [1] first, don't assume that what you read on this
thread is all there is to it.
Torsten Curdt wrote:
logger.debug(User with {} entered wrong query string [{}]., id,
query);
very pythonish. I like it :-)
...but only with jdk 1.5 :-/
Not AFAIK.
[1] http://logging.apache.org/log4j/docs/ugli.html
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: Splitting xconf files step 2: the sitemap
Sylvain Wallez wrote: ... 3 - include it in the block-specific sitemap. That makes the smallest root sitemap yet still allows to easily add block-specific components to any sitemap as [block-name]-sitemap.xconf can be located in context://WEB-INF/xconf +0 Thoughts? Wildcard include? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Remove current docs in trunk
Reinhard Poetz wrote: ... One question to the Forrest specialists: What is a future-proof document type that can be edited with a *common* WYSIWIG editor like the HTML editor that comes with Mozilla and that works with Forrest 0.6? Plain HTML. We pass it through jtidy before using it. Also, there is a special skin called plain-dev. If you tell forrest to use that skin, it outputs all the site in plain html, that can be used instead of the original formats as the input format. I used it to convert the Incubator docs to html. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [vote] splitting cocoon.xconf
Sylvain Wallez wrote: Team, here's a formal vote about splitting cocoon.xconf. ... Please cast your votes. Here's my +1 (of course!) +1 [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110354180900487w=2 [2] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=110361460811792w=2 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Vote] Component confs per sitemap [was: [RT]]
Carsten Ziegeler wrote: ... So, please cast your votes! +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Component confs per sitemap
Carsten Ziegeler wrote: . What about providing the possibility to add components/roles on a per sitemap level? Where do I sign? 8-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [ANN] auto-compiling javaflow in trunk
Sylvain Wallez wrote: ... Mmmh... AFAIK jakarta sandbox is open to jakarta committers. Once it was that way... then when I was still contributing there there has been consensus on opening to any APache committer. I don't remember the final formal outcome, but AFAIK there should not be major problems in getting access to the sandbox :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Proposal] New Block building system
Reinhard wrote: ... Stefano and others, What do you think, should I continue with the new block build system? You are doing the work, the work is well done, what can I say... go ahead :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Duesseldorf, Nov8-Nov11
I'll be attending the Glesstec [1] fair in Duesseldorf from Nov 8 to Nov 11. It would be fun to meet up with some ASF folks there, maybe for a dinner gettogether. [1] http://www.glasstec-online.com/ -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Implementation of the Continuations checker
Unico Hommes wrote: ... I believe that the excalibur event package lives on at d-haven [1]. Why not use that? Oh oh. We did this discussion with the container, I hope we don't have to go over this again for every Avalon dependency we have ;-P 1. http://api.d-haven.org/event/ -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] doco lite?
Bertrand Delacretaz wrote: Le 26 oct. 04, à 23:36, Helma van der Linden a écrit : ...G4. Make submitting documentation a more straight forward process. I haven't yet looked at the ins and outs of the xdocs, but I know from the times I tried to find the documentation in the checked out tree that I was unable to figure out how it worked... Sure. If committers can quickly see online the results of a small patch to the docs (which my proposal allows), it will be much easier and motivating to apply such patches. Direct applying of patches by authorized users is another story, but this is a first step. What IMHO could be done even now is to: - include at the bottom of every page a 'comments link' that links to a Wiki page with the same name as the page (taking path in consideration) - include with SSI the contents of the wiki page at the bottom of the document -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Let's deprecate the PHP block
Tony Collen wrote: ... Let's deprecate the PHP block for the remainder of our 2.1.X releases and then dump it in 2.2. If people want to use PHP with Cocoon, the best solution is to just use a FileGenerator and an http:// URL. I had written a similar mail a loong time ago, so I only find it natural that I vote +1, let's deprecate it. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Let's deprecate the PHP block
Stefano Mazzocchi wrote: ... If you have ideas on how to make it better, we are wide open to suggestions. Making the Subject match the content of this thread would be a good start. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [cron block] dependency question
Vadim Gritsenko wrote: Reinhard Poetz wrote: Some thoughts I want to share: goal: move towards real blocks - do as much work that can be reused later - each block has its own build system Why? It is easier to write and maintain single ant script than 55! (we have 55 blocks right now) Let me answer for Reinhard :-) If every local buildfile has import file=../common-block-build.xml then there is not really more to maintain, but you gain in being able to customize the build where needed and to build the block 'locally'. It also becomes easier to accomodate for extra external blocks that do not necessarily need only our build targets. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Some notes about the 'Real Blocks' issue
Stefano Mazzocchi wrote: Ralph Goers wrote: Antonio, This subject has come up many times. I'll restate what I've always said. If we must release a snapshot jar then the source that was used to build it must be available for download from Cocoon's website, or another documented location (i.e. cocoondev, ibiblio, etc.). I've had too much trouble in the past trying to track down the source for snapshots. This is not an issue for formally released dependencies because almost all of them release a source package that matches their binary package. Ehm, sorry, but as long as the CVS repository is public, I see no need for this. In fact AFAIK we had decided that we had to keep the sources only if the source was not easy to get. We can simply append the SVN version of the snapshot used to build, and it should be a snap to get the corresponding code. xalan-20041018-SVN712345.jar -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: ECM++
Carsten Ziegeler wrote: ... Should I switch 2.2 to use ECM++ now +1 (ECM++ is not buildable standalone, you have to copy the classes into the Cocoon src directory - but we could add the required libs if needed). IIUC you will integrate it in the build as a step to be involked before the Cocoon build, right? As ECM++ doesn't support Composable and ComponentSelector anymore, the XSP block is currently not working - we have to switch it to Serviceable as well - but that isn't really a problem. I will do that as soon as I have time for it. 'k Forrest is using 2.2 too, so let's try to keep it stable as much as possible and in general do all the big changes on branches. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: ECM++
Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: IIUC you will integrate it in the build as a step to be involked before the Cocoon build, right? No, it's just some more classes in the core; we don't have the need to have a separate jar/product. I disagree in part. B-) I agree that there is no need of a separate jar in the distro. I do think though that the compilation of ECM++ must be done *before* the others, so that things remain properly layered. What about using this? http://ant-contrib.sourceforge.net/tasks/compilewithwalls.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: ECM++
Sylvain Wallez wrote: Nicola Ken Barozzi wrote: Forrest is using 2.2 too, so let's try to keep it stable as much as possible and in general do all the big changes on branches. Why do Lenya and Forrest use 2.2? I was not able to backport the @passthrough attribute on mounts to the 2.1 branch :-( -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: ECM++
Stefano Mazzocchi wrote: Nicola Ken Barozzi wrote: Forrest is using 2.2 too, so let's try to keep it stable as much as possible and in general do all the big changes on branches. Hmmm, I'm not sure if I like this. Quasi-static development, reversible changes, early testers that can test the trunk from SVN without having to wait for alphas or betas, no unbuildable or broken trunk that halts others from contributing, etc etc etc. The usual mantra says that the code must be buildable at all times. I prefer to extend it to saying that it must be usable at all times, even if not necessarily bug free or feature complete. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Building ECM++ for 2.2
Carsten Ziegeler wrote: ... The basic idea is to build an own version of ECM +1 Rub a dub dub http://www.joelonsoftware.com/printerFriendly/articles/fog000348.html In Defense of Not-Invented-Here Syndrome http://www.joelonsoftware.com/printerFriendly/articles/fog07.html Things You Should Never Do, Part I http://www.joelonsoftware.com/printerFriendly/articles/fog69.html -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT9 subversion pre commit hook
Bertrand Delacretaz wrote: Le 11 oct. 04, à 12:24, Torsten Curdt a écrit : ...But wouldn't it be cool to just write: fixes-bug:1234 message ..not having to care about the status.xml anymore?.. it would for sure ;-) The problem is that not necessarily stastus changes are done in one commit, there is a different granularity in the two. This is the reason why some projects that were using commit message extraction systems are now also using a status file. BTW, could committers please also add the bug name to the commit message? Log: Apply patch for bug 29951 doesn't say anything to me when reading commit messages. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: pass-through in BRANCH_2_1_X does not work
Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: ... But to be sure, someone should look at the code and verify. I'm sorry to say that my time constraints have grown even more strict, as my wife's vet ambulatory opening date is getting nearer and as we are starting a new metal structure painting section. :-) If someone wants/has time to do this I'd be happy, but I'm equally fine in having it only in 2.2. Is already something checked in into 2.1.x? If so, I think we should remove it from there - unless of course someone has time to look at it. Exactly. If nobody replies in a couple of days I will revert. Maybe the CGT can foster goodwill? :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT9 subversion pre commit hook
Torsten Curdt wrote: The problem is that not necessarily stastus changes are done in one commit, there is a different granularity in the two. This is the reason why some projects that were using commit message extraction systems are now also using a status file. where is the problem? do one commit without the magic words and one with them. not *all* changes have to go into the status file. 'k, this is nice :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: svn commit: rev 54666 - in cocoon/trunk/src/java/org/apache/cocoon/bean: . helpers
[EMAIL PROTECTED] wrote: Author: upayavira Date: Tue Oct 12 04:08:27 2004 New Revision: 54666 Modified: ... Log: Broken link reporting now includes referring pages (requested by Forrest) Woh! :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: pass-through in BRANCH_2_1_X does not work
Carsten Ziegeler wrote: ... But to be sure, someone should look at the code and verify. I'm sorry to say that my time constraints have grown even more strict, as my wife's vet ambulatory opening date is getting nearer and as we are starting a new metal structure painting section. :-) If someone wants/has time to do this I'd be happy, but I'm equally fine in having it only in 2.2. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: pass-through in BRANCH_2_1_X does not work
Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: Carsten Ziegeler wrote: ... But to be sure, someone should look at the code and verify. I'm sorry to say that my time constraints have grown even more strict, as my wife's vet ambulatory opening date is getting nearer and as we are starting a new metal structure painting section. :-) If someone wants/has time to do this I'd be happy, but I'm equally fine in having it only in 2.2. Is already something checked in into 2.1.x? If so, I think we should remove it from there - unless of course someone has time to look at it. Exactly. If nobody replies in a couple of days I will revert. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
pass-through in BRANCH_2_1_X does not work
I have backported the pass-through stuff from the trunk (where it works, and is being used by Forrest) to the 2.1 branch (where it does not work right). In particular, it seems that the source resolving is not happening correctly, because part of the processing start happening if I change from cocoon:/ to cocoon:// and if I insert full pathnames for files. The same processing part work ok if not called by a passthrough mount. It seems like things are not being set back correctly after the child sitemap ends and the parent continues processing. The files to compare is MountNode.java (and maybe PipelineNode.java). Any ideas? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Rhino from mozilla.org and continuations
Igor Bukanov wrote: ... I think I will commit the patch early next week after I add few changes to Rhino documentation about it so it will be included in Rhino 1.6. http://www.textfiles.com/art/beer.vt :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: svn commit: rev 43428 - in forrest/trunk/src/core/context: . WEB-INF
[EMAIL PROTECTED] wrote: Author: rgardler Date: Mon Sep 6 13:57:34 2004 New Revision: 43428 Modified: forrest/trunk/src/core/context/WEB-INF/cocoon.xconf forrest/trunk/src/core/context/default-forrest.properties forrest/trunk/src/core/context/linkmap.xmap forrest/trunk/src/core/context/menu.xmap forrest/trunk/src/core/context/tabs.xmap Log: add ability to override linkmap, menu and tabs .xmap files to allow the generation of site.xml and tabs.xml from other source files such as imsmanifests for IMS content packages Is it necessary to expose more than one extension point to the users? IOW can't users just override these in the single user sitemap.xmap? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: svn commit: rev 43428 - in forrest/trunk/src/core/context: . WEB-INF
Oops, sorry, wrong place 8-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
cocoon:/ protocol bug in 2.2?
I've updated Cocoon to use 2.2-dev to test the new pass-through stuff, and one thing is not working as before. In a subsitemap, I do a cocoon:/ call and it does not work. It works when I put the things to call in the base sitemap, but wasn't that cocoon:// (which BTW seems to work correctly)? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: cocoon:/ protocol bug in 2.2?
Carsten Ziegeler wrote:
Hmm, I just tested latest trunk from SVN and it works for me.
For example our samples:
http://localhost:/samples/sources/xsl-cocoon
or the portal work very well and they all use the cocoon:/
protocol.
Can you provide a test-case?
In the base sitemap I put:
map:pipeline internal-only=false
map:match pattern=*.xml
map:select type=exists
map:when test=subsitemap.xmap
map:mount uri-prefix=
src=subsitemap.xmap
check-reload=yes/
/map:when
/map:select
/map:match
/map:pipeline
Then in the subsitemap I put:
map:pipelines
map:pipeline internal-only=false
map:match pattern=test2.xml
map:generate src=index2.xml /
map:serialize type=xml /
/map:match
/map:pipeline
map:pipeline internal-only=false
map:match pattern=test.xml
map:generate src=cocoon:/index2.internal /
map:serialize type=xml /
/map:match
/map:pipeline
map:pipeline internal-only=true
map:match pattern=*.internal
map:generate src={1}.xml /
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
Then test2.xml gives output, test.xml does not.
Note that if I remove the match in the base sitemap, both tests work
even if the internal pipeline in the subsitemap is still hidden from
direct calls.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: Planning 2.1.6
Carsten Ziegeler wrote: The 2.1.x branch contains imho enough important bug fixes for a new release: 2.1.6. What do you think of a release by the end of september? The only thing currently missing is merging all the changes we did to the head into the branch. This page http://wiki.apache.org/cocoon/MergingBranches lists all remaining parts. Would it be ok to add the passthrough attribute stuff (I am struggling to find time to do it, but will, I promise!) in this release so that Forrest can ship with a released Forrest? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Proposal] Add pass-through capability to mounted pipelines
David Crossley wrote: ... +1 for the ability to return for subsequent processing. I like the explicit name return-no-match. The fact is that it's not necessarily true that it will be only matches that it fails to find. The contract is simply that it will continue if no xml pipeline (gen-[transf]-ser) is executed. 'passthrough' is the same used in James (actually it's passThrough). An option could be return (IOW come back) or delegate (give processing responsinility to the parent). In any case, the best one that will seem ok to me will go in there... after all it's the functionality we need, not the name ;-) (*) The default should ideally be true, but does that sit okay with back-compatibility? The default must be backward compatible, IOW false. -- Nicola Ken Barozzi [EMAIL PROTECTED] - (*) verba volant, scripta manent - (discussions get forgotten, just code remains) -
Actual implementation of passthrough
If the @passthrough attribute is to be put in the pipelines section of
the mounted sitemap, it seems easy: make the PipelinesNodeBuilder set a
passthrough variable in the PipelinesNode, and have the PipelinesNode
tell or not the last PipelineNode if it has to stop:
public void setChildren(ProcessingNode[] nodes) {
// Mark the last pipeline so that it can throw a
//ResourceNotFoundException
//- put an if() here
((PipelineNode)nodes[nodes.length - 1]).setLast(true);
//
super.setChildren(nodes);
}
The point is that it makes sense for the mount node to set it, but I'm
not sure which is the preferred way in the TreeProcessor to pass that
info from the MountNodeBuilder to the PipelinesNode.
Suggestions?
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: Actual implementation of passthrough
Unico Hommes wrote: ... What about letting MountNode catch the No pipeline matched request exception that is thrown during processor.buildPipeline() and processor.process() and decide whether or not to rethrow it there. Would that work? It could, but I'd have to check somehow that it's the right exception, as the end of the processing is not the only condition that triggers it. Besides, Exception throwing is not necessarily fast and is not meant in itself to be used for flow management. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
[Proposal] Add pass-through capability to mounted pipelines
Summary: Developing Forrest, I seem to have stumbled in the need of mounted pipelines that do not halt processing if a match is not found. Thus I propose that we add the pass through='true|[false]' attribute to make it possible for mounts not to necessarily halt processing if no match is found. -=--=--=--=--=- Rationale: It's typical to use the URL space to partition *processing*; because of this it's natural to match a URL in the base sitemap and delegate subURLs to mounted sitemaps. In Forrest we have decided not to do this, and to keep the whole URI space free for uses to fill with their semantical partitionings. To decide how to process a file we use file extensions and eventually peek inside to take a look at the DTD. This makes it impractical to partition the sitemap in several mounted sitemaps. It shifted from impractical to impossible as soon we tried to make it possible for users to add their sitemap to the processing. There is no clean way i know of ATM for me to delegate a part of the matches to an external sitemap without giving away a whole URL space. ATM we are asking users to *copy* the sitemap they want to use and change it, but it has already proved over time to be extremely fragile for updates. We do not want to keep such a lame contract with our users. I hoped that calling the user pipeline with the cocoon: protocol and using a resource-exists could route round the issue, but it's still not ok. If a match is found, I have to process the pipeline two times, or rely on caching, which is not always possible or desirable. So it seems that the only viable solution is to make it possible for mounted pipelines to not fail processing if a match is not found, and have the base sitemap resume processing. This is in line with what resources do now (in an unwanted but nevertheless welcome and happily used bug). James also has a similar thing in the mail pipeline matches, that can passThrough. Thus: I propose that we add the passthrough='true|[false]' attribute to make it possible for mounts not to necessarily halt processing if no match is found. The proposed element for it is the mount node, so that the base sitemap has the say on whether it wants to make the subsitemap completely responsible or not of the subsequent processing. The default behavior would be identical to what we have now. WDOT? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
ResourceExists does not work on cocoon: protocol requests?
I'm hacking Forrest so that users can add their documents to the Forrest
processing.
First of all, from the root sitemap I mount their sitemap in a separate
uri space if it's found ({project:sitemap} contains the URL to the user
sitemap):
map:match pattern=project_sitemap/**
map:select type=exists
map:when test={project:sitemap}
map:mount uri-prefix=project_sitemap
src={project:sitemap}
check-reload=yes /
/map:when
/map:select
/map:match
Then, in another subsitemap, where Forrest searches for source files, I
want to see if the user sitemap has an xml file to serve me for the
current URI, and if so, use it:
map:select type=exists
map:when test=cocoon://project_sitemap/{uri}.xml
map:generate src=cocoon://project_sitemap/{uri}.xml /
map:serialize type=xml-document/
/map:when
...etc
The problem is that the test is always true IIUC, and the result is an
'Attempted to process incomplete pipeline.'
In fact IIUC, in SitemapSource I see:
/**
*
* @see org.apache.excalibur.source.Source#exists()
*/
public boolean exists() {
return true;
}
Any hint if/on how to make this work, or alternatives?
I'm literally _drowning_ in this code.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: ResourceExists does not work on cocoon: protocol requests?
Vadim Gritsenko wrote:
Nicola Ken Barozzi wrote:
In fact IIUC, in SitemapSource I see:
/**
*
* @see org.apache.excalibur.source.Source#exists()
*/
public boolean exists() {
return true;
}
The problem is that the only way to actually test whether sitemap source
exist or not is to try and generate this sitemap resource - which might
be expensive operation.
Let's say that I'm clever enough and all of the processing that happens
without resource generation are (failed) matches. This should be cheap
enough, as it's the same thing I would do if I do it in the main sitemap
(which I do not want to do).
How to do it?
[I still remember some time ago when someone wanted to mount sitemaps
and have processing from the caller continue if no match was found. I
still remember who was particularly against this thing (errr me), and I
am now banging my head on solving the same issue. Same thing with the
handle-errors and the generator in it... the world still didn't fall.
Gotta remember these things next time I open my big mouth...]
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: [VOTE] Avoid checking in JavaDOCs into SVN
Pier Fumagalli wrote: I'm rebuilding the site and javadocs, and I seriously fail the point of checking in generated javadocs... It's useful to have javadocs on the site, but on SVN it's useless. +1 to remove them Why not simply put them on http://www.jdocs.com/ ? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Concerns surrounding CocoonNG
Leo Sutic wrote: ... I'm sure Merlin/Metro has a place somewhere, maybe inside the blocks, maybe somewhere else, but considering switching to it at this point in time is simply reckless. Using a container has two advantages: using code that is already there and tested, and hooking up with a commmon base so to collaborate with other services. For the first point, our needs are not so easy, so we would have the same problem we had with Avalon: create our new ECM derived from the simpler core. Furthermore it's not so much tested in the real world and still evolving. For the second point, it's not relevant, as Cocoon as a _whole_ should be embeddable in such a container, like for example in Geronimo as a GBean, in JBoss, in Merlin, etc. I agree with Leo, we don't need to buy a motor for our nice car, we need to make our own and tune it at need. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [proposal] Private Branches
Steven Noels wrote: On 29 Jul 2004, at 23:50, Stefano Mazzocchi wrote: fine, what about http://svn.apache.org/repos/asf/cocoon/ (whiteboard|scratchpad|research) We had already discussed (was it 1, 2 years ago) that personal playgrounds are bad... Much better. But you are suggesting a branch for all these, no? I'm not so sure about that - branches tend to hide things away. Of course, branching is better|easier than scratchpad areas, so this might be the better solution. If something is a branch, it should actually be a branch (ie copy from the main code), so it can merge. If not it can still reside in branches, as in subversion it's just a dir. For the record: I'm -1 on any labelling or classification system which includes the name|id|alias of a contributor. Same here. Anything else which is workable, facilitates creativity, groups common work areas under a single name, and doesn't create code islands, I'm violently +1. If someone wants to experiment on a branch, just say so and do it, and label the branch with a significant name. When/if time to merge back will occur, we will vote. Simple IMHO. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] A Groovy Kind of Sitemap
Ugo Cei wrote:
Il giorno 30/lug/04, alle 00:24, Sylvain Wallez ha scritto:
Don't take all this badly Ugo: I see much more dangers in turning the
sitemap into a scripting language than the advantages brought by
saving a few keystokes or the ease of implementation. But I'm all for
a simplified implementation of the current syntax.
...
One thing I *hate* about flowscript is that it's in a different file
from the sitemap. Kinda like writing a java class with methods in one
file and fields in another.
Having both in the same file, even if with a different language but
still with a readable format (like python), would be really cool.
cocoon
version = 2
sitemap---
mypipeline
if (request.match(.*\.html)) then
generate(input.xml)
transform(xslt, stylesheet1.xsl)
transform(xslt, stylesheet2.xsl)
serialize(xml)
---
javascript---
void myfunction(continuation,javascript){
blah...blah...
(can call mypipeline pipeline from here)
(can call mypipeline2 pipeline from here)
}
---
sitemap---
mypipeline2
if (request.match(.*\.html)) then
generate(input.xml)
transform(xslt, stylesheet1.xsl)
transform(xslt, stylesheet2.xsl)
serialize(xml)
---
jtyhon---
myfunction(continuation)
blah...blah...
(can call mypipeline pipeline from here)
(can call mypipeline2 pipeline from here)
---
So I needed something that could enable me to reach very
rapidly the target of having an actual program that would be able to
take an HTTP request, feed it to a sitemap that is (semantically if not
syntactically) equivalent to a subset of the Cocoon sitemap and send out
an appropriate response.
One attempt is the CocoonBean, that has tried to do this by wrapping
instead of redoing. Same problem, different implementation. Personally i
think that it's wierd to have a bean wrap a component wrap some classes,
although necessary not to redo things (like you are doing :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
-
Re: [proposal] Private Branches
Reinhard Poetz wrote: Stefano Mazzocchi wrote: http://svn.apache.org/repos/asf/cocoon/(whiteboard|scratchpad|research) I like research or playground best. Anyway, let's make it more concrete: These days I started to work on the Cocoon BlockDeployer and I plan to share my work within the next two or three weeks. I would put it into http://svn.apache.org/repos/asf/cocoon/playground/block-deployer (I don't think putting it into the branches directory is appropriate because it is definitly no branch.) Any objections or other proposals? No objections, just that 'playground' seems like kids playing... better would be 'whiteboard' IMHO. Not that I oppose to any name, you can even name it SGdfgDSGDSFG as long as it gets in there :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Stefano Mazzocchi wrote: ... Result, I'm -1 on Spring because we can't control it and -0.5 on Merlin/Fortress/Geronimo because they are other communities with other interests. I agree but... I say we write our stuff and be done with it once and forever. ... if he wants to try Spring, why stop him and others to _try_. It seems he can't be persuaded otherwise, and who knows, maybe he's right! -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [butterfly] spring dependant tests (was Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?))
Ugo Cei wrote: Il giorno 22/lug/04, alle 10:34, Marc Portier ha scritto: still have to get into your actual code sample though, by the way: could we arrange having a cvs somewhere? How about cocoondev.org? Is the migration over? I asked Steven some time ago about hosting the SpringPetstore block and he askde me to wait until August. Or would it be better to create a new module in the Apache CVS? I'd rather avoid SF, I've had unpleasant experiences in the past. As I tried to explain, as a Cocoon committer you should be able to experiment in a branch. As soon as the SVN conversion is over, you can create a butterfly branch and all Cocooon committers can work there if they want to. What about a mailing list? We're having an unpleasant discussion about creating mailing lists on the community list... ugh IMO the right thing is to ask a vote for it, and then ask infra to set it up as per the Cocoon PMC decision. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: The Butterfly Manifesto (was Re: [RT] Spring+JMX == Real Blocks?)
Ugo Cei wrote: Il giorno 12/lug/04, alle 18:23, Marc Portier ha scritto: think so too, just needs more wild thinking and somebody doing :-) Since I'm getting more and more bored with my daytime job, I ended up doing something: http://wiki.apache.org/cocoon/ButterflyManifesto Comments are welcome, flames /dev/null. This looks like an interesting revolution in Cocoon land :-) If you want to do it, and it will be really interesting if you do, here are some tips: http://incubator.apache.org/learn/rules-for-revolutionaries.html In particular, here are the relevant parts: To allow this to happen, to allow revolutionaries to co-exist with evolutionaries, I'm proposing the following as official Jakarta policy: 1) Any committer has the right to go start a revolution. They can establish a branch or seperate whiteboard directory in which to go experiment with new code seperate from the main trunk. The only responsibility a committer has when they do this is to inform the developer group what their intent is, to keep the group updated on their progress, and allowing others who want to help out to do so. The committer, and the group of people who he/she has a attracted are free to take any approaches they want to free of interference. 2) When a revolution is ready for prime time, the committer proposes a merge to the -dev list. At that time, the overall community evaluates whether or not the code is ready to become part of, or to potentially replace the, trunk. Suggestions may be made, changes may be required. Once all issues have been taken care of and the merge is approved, the new code becomes the trunk. 3) A revolution branch is unversioned. It doesn't have any official version standing. This allows several parallel tracks of development to occur with the final authority of what eventually ends up on the trunk laying with the entire community of committers. 4) The trunk is the official versioned line of the project. All evolutionary minded people are welcome to work on it to improve it. Evolutionary work is important and should not stop as it is always unclear when any particular revolution will be ready for prime time or whether it will be officially accepted. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] Document based I18n sites with Cocoon
Upayavira wrote: ... Sorry, could we please delete the parts of the discussion that are not strictly necessary from the replies? I have to keep on scrolling miles of pages 8-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: advice
Pier Fumagalli wrote: I agree with Jim... Although rolling 2.1.6 might be non trivial given that noone created a new branch/repo for 2.2 and _a_lot_ of changes (in libraries and related) have been committed since. Can't we simply untar the 2.1.5 distro, shove in the two text files, retar it, call it 2.1.6, and release that removing 2.1.5? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Releasing 2.1.5.1
Carsten Ziegeler wrote: I'm planning to release 2.1.5.1 (2.1.5 + the two missing files) tomorrow morning if noone objects. I will create a branch in CVS from 2.1.5, change the build script accordingly and do the usual release process (without testing :) ) I hope this is ok with everybody? We should start of taking the habit of voting the release of the actual tarballs. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Releasing 2.1.5.1
Carsten Ziegeler wrote: Nicola Ken Barozzi wrote: ... We should start of taking the habit of voting the release of the actual tarballs. ... Now, how do we want to do this practically. Imho this would require that we build the tarballs and give people time to test them (some days) so they can really vote on them. A typical scenario is that the release manager uploads the tarballs along with the checksums on his private web space at Apache, and that a vote is done on those after - let's say - 72 hours. If the vote is ok then the release manager can simply move the files in the dist section. My naiv understanding was that we all test the tarballs during our code freeze, so actually I thought we vote on a virtual tarball so to speak. Going 'real' instead of 'virtual' could help us not repeat the same mistake we have done now. It makes it possible to have the actual tarball be reviewed by all that want to (and that should if they vote IMHO). -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: Cocoon is not gump! ( was RE: [VOTE] preservation policy for third-party snapshot sources)
Antonio Gallardo wrote: ... Yep, but keep in mind that we are not talking about rhino here. We are talking about more files: lib/core: commons-jexl-1.0-beta-1-20040113.jar - currently 116 kB commons-jxpath-20030909.jar- 266 kB jcs-1.0-dev-20040516.jar - 318 kB rhino1.5r4-continuations-20040627.jar - before was 500 kB ...etc I did not think it was about *these* snapshots too. I thought it was about snapshots of stuff that we had modified somehow and the code of which was hard to find or build. (see for example excalibur stuff when there was confusion about it's future) If what Antonio has written is the case, consider my vote a -1, as we should not be distributing sources of things that can and should be easily gotten elsewhere, *especially* is 'elsewhere' is still in Apache. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [VOTE] preservation policy for third-party snapshot sources
Sylvain Wallez wrote: ... keep sources in jar files +1 -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The Cocoon Handbook
Joerg Heinicke wrote: On 25.06.2004 19:12, Nicola Ken Barozzi wrote: The problem is that it requires storing the sxw as a binary file, which doesn't help to track changes. Come on guys HTML, HTML, HTML! Forrest *already* can use HTML! Why that low-level? You don't have a real page structure then, it's to loose IMO. HTML is not more low level than Document-DTD, and the h1s, h2s, h3s, etc are transformed internally in sections. Why HTML? Because everybody knows html, there are tons of books on it, and virtually every editor can read and write html. And our primary output is HTML. Don't forget Helma's effort on that: http://wiki.cocoondev.org/Wiki.jsp?page=Cocoon215TOC Sure won't, thanks for the link :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Cocoon Docs SVN Repository?
To start off the new documentation effort, I'd like to use subversion and html. This would give us the possibility of simply navigating the latest docs in source control in an easy way, and given how well tortoiseSVN works also to make it easier for doc writers. Is it ok if I ask infrastructure to create a cocoon/newdocs space in svn so we can start working on it? Later on it can be moved under the final cocoon destination with no effort (thanks to SVN :-) WDOT? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The Cocoon Handbook
Sylvain Wallez wrote: ... The problem is that it requires storing the sxw as a binary file, which doesn't help to track changes. Come on guys HTML, HTML, HTML! Forrest *already* can use HTML! -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The Cocoon Handbook
caleb racey wrote: ... I too wish to see docbook as a documentation format for cocoon and a whole host of other projects. Forrest will move to XHTML2 as the source format of election in the future, and will support XHTML and HTML too (already does but not as extensively as we would want). -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The Cocoon Handbook
Tony Collen wrote: ... The Solution I propose we create a free, high-quality electronic book (entitled _The_Cocoon_Handbook_), which will eventually replace the mess of docs we currently have. It will be in DocBook (possibly simplified) format. ... Let's not make this a technology issue, it's a people issue. IOW, it's not (only) the doc system that sucks, but it's the doc writers that are missing. 1 - The first thing we need IMNSHO is to define a structure of this book: The sections, the chapters. 2 - Then we can take the existing docs and put them into place in this structure till there are no more, eventually enlarging the structure to make them get in. 3 - Finally, we need to fill in the missing gaps. Only at this point do we really need an easier documentation system ala DOCO. What I would suggest doing is to make a new documentation directory from Forrest and fill in the tabs.xml and site.xml files (step 1). The copy the docs from the current documentation and link them in the site.xml file (step 2). [Note that at this point we should be using SVN, and users can then be given fine grained access only to the docs even without having a Unix account. In this way we can give away SVN access just for documenters that don't need to become part of the project.] I would also suggest to use simple html files (that Forrest can read), so that users can use any editor to create them without running Forrest, and they can be seen also in ViewCVS too. What I can help to do is to set up the initial Forrest doc space in the Cocoon CVS where this can start happening. WDOT? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The Cocoon Handbook
[EMAIL PROTECTED] wrote: ... I would also suggest to use simple html files (that Forrest can read), why not xhtml that are structured? That's the idea. Forrest ditches all non-presentational tags... using a simple subset of xhmtl tags will be easy to tranform to PDF ...and then can transform to PDF :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] The Cocoon Handbook
Berin Loritsch wrote: ... All I can say is Write On! (pun intended). :-D Seriously, having a good organizational structure helps writing comprehensibly. The structure does not need to be set in stone, but it does need to be there. The biggest problem is getting writers. +1 Question is, who is going to do the writing? Easier task: what documentation is well written, so we can copy the organization form that? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
