cziegeler2003/01/15 00:06:37
Modified:src/java/org/apache/cocoon/components/pipeline/impl
AbstractCachingProcessingPipeline.java
src/java/org/apache/cocoon/sitemap ContentAggregator.java
Log:
Disabling deferred validities for the moment
Rev
-xmlutil-20030115.jar
Removed: lib/core excalibur-xmlutil-20030114.jar
Log:
Updating to latest excalibur xmlizer
Revision ChangesPath
1.19 +2 -2 xml-cocoon2/src/documentation/cocoon.xconf
Index: cocoon.xconf
cziegeler2003/01/15 03:30:42
Modified:src/java/org/apache/cocoon/i18n
XMLResourceBundleFactory.java BundleFactory.java
Added: src/java/org/apache/cocoon/i18n AbstractBundleFactory.java
Removed: src/java/org/apache/cocoon/i18n AbstractBunldeFactory.ja
Hy;
I wonder, why the Catalog.properties must reside
in the classes directory. For me it would be
more natural to put it either into WEB-INF, or
WEB-INF/conf instead.
any explanations?
This is what makes me troubles:
(Maybe someone knows a workaround for this ...)
i use eclipse for my developme
cziegeler2003/01/15 04:04:51
Modified:src/java/org/apache/cocoon/components/pipeline/impl
CachingProcessingPipeline.java
Log:
Preventing a NPE
Revision ChangesPath
1.32 +5 -1
xml-cocoon2/src/java/org/apache/cocoon/components/pipeline/imp
cziegeler2003/01/15 04:28:17
Modified:src/java/org/apache/cocoon/components/pipeline/impl
AbstractCachingProcessingPipeline.java
CachingProcessingPipeline.java
Log:
Fixing NPE in caching algorithm
Revision ChangesPath
1.22
I think there's an error in log.xsl logicsheet. When trying to use it for
example:
test
the messages end up in tomcat's log because the full logging category is
cocoon.sitemap.myxsplog.
while the same logic copied exactly to my xsp file with sitemap.myxsplog
category:
try {
org.apache.log.
Team.
The long pending SAP R/3 patches [1] by Michael Gerzabek and Reinhard
Poetz now carry the standard ASF licence plate, mock classes exist, I
have reviewed the code and am happy with it. All issues have been
solved by Michael and it was great working with him on it. I have not
tested the compo
Christian Haul wrote:
Before actually adding the code to the 2.1 repository, I'd like to
have a final voting on it.
- do they need some SAP-jars in the classpath upon compilation time?
- if that is the case, do those need to be stored in ASF CVS?
- if that is the case, is that allowed according
Steven Noels wrote:
- if all that is the case and the license only allows binary
distribution, we can implement mock classes
If all these are incorrect assumptions, pardon my ignorance.
It was ignorance, sorry about that - better check before ranting ;)
Other worry: this means adding yet ano
cziegeler2003/01/15 06:06:37
Modified:src/blocks/portal-fw/samples/profiles types.xml
admintypes.xml
Log:
Correct spelling
Revision ChangesPath
1.2 +1 -1 xml-cocoon2/src/blocks/portal-fw/samples/profiles/types.xml
Index: types.xml
On 15.Jan.2003 -- 02:58 PM, Steven Noels wrote:
> Christian Haul wrote:
>
> >Before actually adding the code to the 2.1 repository, I'd like to
> >have a final voting on it.
>
> - do they need some SAP-jars in the classpath upon compilation time?
Michael has created Mock objects that are used in
Hi all,
concerning long term perspective: we enjoy Cocoon since release 1.8 and
have at least 2 productive projects running with Cocoon 2.0 and the SAP
part. And we will go on!
So if testing is needed with real SAP we surely can do this. And I'm
also sure that we won't be the only one to use thes
crafterm2003/01/15 06:26:29
Added: src/scratchpad/lib LICENSE.commons-logging
commons-logging-1.0.2.jar
Log:
Added commons logging package which is required for the axis soap server
component (was previously in xml-cocoon2/lib but was recently removed).
Dear All,
I have now created my CocoonBean [which is a programmatic interface to Cocoon,
allowing pages to be requested from Cocoon by any Java application], the code for it
is currently in Bugzilla (bug 15748). I'd appreciate any comments upon what I've done
so far.
The significant changes si
Dear All,
Now that I've created a Cocoon bean, I need to create an
application to drive it. I would like to produce something
reasonably generic, that might be of use to others - hence
this proposal. What I detail below is what I have thought of
so far, but I would very much appreciate comment
I should be able to make monday night.
Regards, Upayavira
> On Tue, 14 Jan 2003, Stefano Mazzocchi wrote:
>
> > Anyway, I'm leaving for Italy on the 22nd and I can't change that.
> > So, it's either monday night or tomorrow at lunch.
>
> Yikes! Ok, let's make it Monday 20th night then. I'd sugg
haul2003/01/15 07:55:13
Modified:src/java/org/apache/cocoon/components/modules/input
DigestMetaModule.java
Log:
fix NPE
Revision ChangesPath
1.11 +20 -12
xml-cocoon2/src/java/org/apache/cocoon/components/modules/input/DigestMetaModule.
haul2003/01/15 07:55:47
Modified:src/java/org/apache/cocoon/components/source/impl
ContextSourceFactory.java
Log:
remove unused import
Revision ChangesPath
1.10 +1 -2
xml-cocoon2/src/java/org/apache/cocoon/components/source/impl/Cont
haul2003/01/15 07:57:51
Modified:src/java/org/apache/cocoon/transformation/helpers
VariableConfiguration.java
Log:
remove unused import
Revision ChangesPath
1.2 +1 -3
xml-cocoon2/src/java/org/apache/cocoon/transformation/helpers/Var
haul2003/01/15 07:58:41
Modified:src/java/org/apache/cocoon/transformation
LinkRewriterTransformer.java
Log:
remove unused import
Revision ChangesPath
1.2 +8 -22
xml-cocoon2/src/java/org/apache/cocoon/transformation/LinkRewriterTrans
haul2003/01/15 07:59:06
Modified:src/java/org/apache/cocoon/transformation
SimpleFormInstanceExtractionTransformer.java
Log:
remove unused import
Revision ChangesPath
1.4 +1 -2
xml-cocoon2/src/java/org/apache/cocoon/transformation/S
haul2003/01/15 07:59:32
Modified:src/scratchpad/src/org/apache/cocoon/components/source/impl
BlobSource.java
Log:
remove unused import
Revision ChangesPath
1.6 +1 -2
xml-cocoon2/src/scratchpad/src/org/apache/cocoon/components/source
haul2003/01/15 08:15:36
Modified:src/java/org/apache/cocoon/components/modules/input Tag:
cocoon_2_0_3_branch AbstractJXPathModule.java
AbstractMetaModule.java DigestMetaModule.java
JXPathMetaModule.java RandomNu
This has already been discussed [2] and [3]. Especially the long term
perspective really _is_ an issue. However, I believe that these
components will attract users and hopefully, the components can be
maintained that way.
I am pretty sure this will work out in the end...
Before actually adding
On Wed, 15 Jan 2003, Sylvain Wallez wrote:
> Dear all,
>
> I'm please to announce the availability of the CVSSource I talked about
> recently on cocoon-dev.
>
> This component allows adding new protocols to the ones available in
> Cocoon (such as "resource:", "cocoon:", etc) which are linked "li
Stephan Michels wrote:
On Wed, 15 Jan 2003, Sylvain Wallez wrote:
Dear all,
I'm please to announce the availability of the CVSSource I talked about
recently on cocoon-dev.
This component allows adding new protocols to the ones available in
Cocoon (such as "resource:", "cocoon:", etc) which
Sylvain Wallez wrote:
Dear all,
I'm please to announce the availability of the CVSSource I talked
about recently on cocoon-dev.
This component allows adding new protocols to the ones available in
Cocoon (such as "resource:", "cocoon:", etc) which are linked "live"
to a remote CVS repository.
hello all,
I was just wondering if any of you have tried running the cocoon.war under
tomcat with the UNPACK WAR option set to FALSE? I am getting several errors
trying to compile the sitemap, although all the needed files have been
extracted to the ~work/ directory. We need to be able to run our w
hi,
I have been waiting a long time to be able to work like this!
These types of editors are becoming a reality.
I downloaded the standard edition, and managed to make
it handle document-v10 cocoon documents.
I'm impressed!
And the spellchecker is quite helpful.
Any interests in these xxe co
hi,
SAXESS - Hussayn Dabbous wrote:
Hy;
I wonder, why the Catalog.properties must reside
in the classes directory. For me it would be
more natural to put it either into WEB-INF, or
WEB-INF/conf instead.
com.sun.resolver.CatalogManager reads this property file from the
classpath, so its not an
> 'A computer lets you make more mistakes faster than any invention in human
> history - with the possible exceptions of handguns and tequila' - Mitch
> Ratliffe
But handguns are one invention and tequila is a completely different
invention. That's two inventions ...
--
John Austin <[EMAIL PRO
Dear all,
I'm please to announce the availability of the CVSSource I talked about
recently on cocoon-dev.
This component allows adding new protocols to the ones available in
Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" to
a remote CVS repository. These protocols are _wr
Nicola,
I agree with your and Stefano's basic premise of code reuse, however I would
also point out that there are already Java standard technologies for these
sorts of things: JNDI and JAAS.
Beyond the consideration that standards exist, and Turbine isn't one of
them, there are some technical pr
Torsten Curdt wrote:
This has already been discussed [2] and [3]. Especially the long term
perspective really _is_ an issue. However, I believe that these
components will attract users and hopefully, the components can be
maintained that way.
I am pretty sure this will work out in the end...
Andrew Savory wrote:
On Tue, 14 Jan 2003, Stefano Mazzocchi wrote:
Anyway, I'm leaving for Italy on the 22nd and I can't change that. So,
it's either monday night or tomorrow at lunch.
Yikes! Ok, let's make it Monday 20th night then. I'd suggest meeting in a
fairly central pub from 6 (I'll t
Sylvain Wallez wrote:
Dear all,
I'm please to announce the availability of the CVSSource I talked about
recently on cocoon-dev.
This component allows adding new protocols to the ones available in
Cocoon (such as "resource:", "cocoon:", etc) which are linked "live" to
a remote CVS repository.
Title: xmlform samples are not working for me
This looks like another bad version of the Xerces or Xalan
libs.
Have these been changed lately?
Ivelin
- Original Message -
From:
Jonathan Spaeth
To: '[EMAIL PROTECTED]'
Sent: Wednesday, January 15, 2003 9:11
AM
S
--- Begin Message ---
I'm very proud to announce the availability of Agora 1.1.
This improved version includes a totally rewritten datacloud visualizer
(written in Java since Dynamic SVG was *way* too slow for the purpose).
It runs both as an applet and as a command line application.
The tool
FICO! :-)
+1 ;-D
Che ne dici di metterlo su Alexandria? Sto per committare javasrc,
rimettere l'applet e ristartare tutto.
Stefano Mazzocchi wrote:
Subject:
[announce] Agora 1.1
--
Nicola Ken Barozzi
[ I just sent a very similar email to [EMAIL PROTECTED] ]
Hi all,
There is a Board meeting next Wednesday. I know there has been interest in
the past about Cocoon becoming a top-level project. Should you wish to
pursue that, then next week's board meeting could be ideal.
To establish the top-lev
Christian Haul wrote:
Team.
[...]
Ladies and Gentlemen, please cast your votes: Shall we accept the SAP
R/3 connectivity components from patch [1] ?
[...]
[1] http://nagoya.apache.org/bugzilla/show_bug.cgi?id=9075
+1
--
Nicola Ken Barozzi [EMAIL PROTECTED]
Greg Stein wrote:
To establish the top-level project, the Board would need a resolution
similar to the other project-establishing resolutions (see the November
Board minutes for examples; Avalon and Ant were created then). The
resolution would need to include a Chair and a list of initial PMC
mem
43 matches
Mail list logo
