[Link] Dutch Ministry of Finance - www.minfin.nl
Key: COCOON-1850
URL: http://issues.apache.org/jira/browse/COCOON-1850
Project: Cocoon
Type: Task
Components: - Documentation
Versions: 2.1.8
Reporter:
Giacomo Pati wrote:
No!?! I probably missed something.
Most blocks add their component configs to the cocoon.roles files during
build. As you originally build Cocoon without the template block, these
configs are now missing in the cocoon.jar. So all you have to do is
rebuild Cocoon with the
Carsten Ziegeler skrev:
I'm currently wondering what the best way to configure 2.2 from a user
perspective is. We now have includes for xconfs and property
replacements which is great.
Now, each block comes with its own configuration files: all of them are
stored in the jar and on deployment
Hi,
While using the repeater.moveRow(from, to) method, there were two things
about it which I found illogical:
* to move a row to the last position, say x, one needs to
specify a to-index of x + 1
* if the to-index is larger then from-index, the to-index is
Issue Subscription
Filter: COCOON-open-with-patch (93 issues)
Subscriber: cocoon
Key Summary
COCOON-1848 [PATCH] using setRequired in Ajax mode does not generate bu:replace
http://issues.apache.org/jira/browse/COCOON-1848
COCOON-1847 [PATCH] AJAX errors' popup window not
[
http://issues.apache.org/jira/browse/COCOON-1838?page=comments#action_12412135
]
Reinhard Poetz commented on COCOON-1838:
If a version or a groupId is missing, the values are taken from the parent
artifact. Taking this into consideration, do you
[
http://issues.apache.org/jira/browse/COCOON-1838?page=comments#action_12412136
]
Ben Pope commented on COCOON-1838:
--
A while go I had a look at all the pom files, but I wasn't entirely sure how
they worked with respect to the missing version numbers,
Maven brings a lot of advantages to standardize the development process but also
makes development of applications more difficult as you spread your applications
over different artifacts.
In the light of this I think we should revert our removal of the per-sitemap
classloading
Reinhard Poetz wrote:
Maven brings a lot of advantages to standardize the development
process but also makes development of applications more difficult as
you spread your applications over different artifacts.
In the light of this I think we should revert our removal of the
per-sitemap
In order to replace a snaphot jar in Cocoon with a proper release we
need the BCEL release to come through. Unfortunately BCEL is missing
some feedback on the RC2 to do the release though.
So if anyone is using Xalan XSLTC - please give it a try. Just replace
the shipped BCEL jar with the one
Reinhard Poetz skrev:
Maven brings a lot of advantages to standardize the development
process but also makes development of applications more difficult as
you spread your applications over different artifacts.
In the light of this I think we should revert our removal of the
per-sitemap
Reinhard Poetz wrote:
Maven brings a lot of advantages to standardize the development process but
also
makes development of applications more difficult as you spread your
applications
over different artifacts.
In the light of this I think we should revert our removal of the per-sitemap
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Maven brings a lot of advantages to standardize the development
process but also makes development of applications more difficult as
you spread your applications over different artifacts.
In the light of this I think we should revert our removal of
Automated build for cocoon-docs FAILED
Log attached.
--
Forrestbot run ended at 17 May 12:24 PM
Using Forrest 0.8-dev
Forrestbot administrator: ForrestBot
--
[echo]
... Forrest render START 2006-05-17 12:02:27
... Rendering docs in
Daniel Fagerstrom schrieb:
Reinhard Poetz skrev:
Maven brings a lot of advantages to standardize the development
process but also makes development of applications more difficult as
you spread your applications over different artifacts.
In the light of this I think we should revert our
[EMAIL PROTECTED] escribió:
Author: giacomo
Date: Tue May 16 21:58:44 2006
New Revision: 407153
URL: http://svn.apache.org/viewcvs?rev=407153view=rev
Log:
keep versions in sync
Thanks Giacomo.
Best Regards,
Antonio Gallardo.
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
I'm currently wondering what the best way to configure 2.2 from a user
perspective is. We now have includes for xconfs and property
replacements which is great.
Now, each block comes with its own configuration files: all of them are
stored in
Daniel Fagerstrom wrote:
Reinhard Poetz skrev:
Maven brings a lot of advantages to standardize the development
process but also makes development of applications more difficult as
you spread your applications over different artifacts.
In the light of this I think we should revert our
Carsten Ziegeler wrote:
Now I think that per sitemap configuration and even per sitemap class
loading are key features of 2.2. I see no need to deprecate them or
something like this.
With Cocoon 3.0 and applications that are really split into blocks, we should
only support one way of
Ralph Goers wrote:
I think Carsten is worried about the Portal. The portal has a lot of
configurable elements in it.
No actually I'm not worried about the portal - this will have a clean
solution for 2.2; I'm just more worried about core, for example how can
I configure my own store
Daniel Fagerstrom wrote:
Here the IMO best and most natural solution is to have different blocks
for different implementations. Say we have two different components that
implements the XsltProcessor inteface, the Xalan and the Saxon
implementation. Then if you have a Xalan block with its
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Here the IMO best and most natural solution is to have different blocks
for different implementations. Say we have two different components that
implements the XsltProcessor inteface, the Xalan and the Saxon
implementation. Then if you have a
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Now I think that per sitemap configuration and even per sitemap class
loading are key features of 2.2. I see no need to deprecate them or
something like this.
With Cocoon 3.0 and applications that are really split into blocks, we should
On 5/17/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
snip/
2. This works only as long as the user wants to use the same
implementation for a component. Switching to an own implementation with
an own configuration is not possible.
Any idea on how to solve this?
Here the IMO best and most
Carsten Ziegeler wrote:
Hopefully you can use the same configuration files for both versions, so
only the includes are at a different location.
Yes, that's already implemented in C3.
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source,
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1156
Build statistics:
State: Ok
Previous State: Failed
Started at: Wed, 17 May 2006 17:53:57 +
Finished at: Wed, 17 May 2006 17:54:36 +
Total
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/2/buildId/1157
Build statistics:
State: Ok
Previous State: Failed
Started at: Wed, 17 May 2006 17:59:58 +
Finished at: Wed, 17 May 2006 18:00:24 +
Total
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/156/buildId/1159
Build statistics:
State: Ok
Previous State: Failed
Started at: Wed, 17 May 2006 18:02:57 +
Finished at: Wed, 17 May 2006 18:03:25 +
Total
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/163/buildId/1160
Build statistics:
State: Ok
Previous State: Failed
Started at: Wed, 17 May 2006 18:03:28 +
Finished at: Wed, 17 May 2006 18:05:41 +
Total
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/45/buildId/1161
Build statistics:
State: Ok
Previous State: Failed
Started at: Wed, 17 May 2006 18:05:52 +
Finished at: Wed, 17 May 2006 18:06:20 +
Total
Online report :
http://cocoon.zones.apache.org:12000/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/47/buildId/1162
Build statistics:
State: Ok
Previous State: Failed
Started at: Wed, 17 May 2006 18:06:23 +
Finished at: Wed, 17 May 2006 18:07:36 +
Total
Carsten Ziegeler skrev:
Reinhard Poetz wrote:
How does OSGi solve this?
Since OSGi4 declarative services are supported. Think of Spring dependency
injection but considering interface/implementation relations. You can use the
OSGi configuratonAdmin service to change an injected component or a
[ http://issues.apache.org/jira/browse/COCOON-1804?page=all ]
Simone Gianni closed COCOON-1804:
-
Fix Version: 2.1.10-dev (current SVN)
Resolution: Fixed
Committed the patch
Javascript FOM_SCOPE issue when using Java as the flow engine -
Carsten Ziegeler skrev:
Reinhard Poetz schrieb:
Carsten Ziegeler wrote:
Reinhard Poetz wrote
I have just committed it but didn't update SitemapLanguage.java accordingly.
A brief look reveals that you do not support all lifecycle interfaces.
Aren't SingleThreaded and ThreadSafe enough. We
Ralph Goers skrev:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
I'm currently wondering what the best way to configure 2.2 from a user
perspective is. We now have includes for xconfs and property
replacements which is great.
Now, each block comes with its own configuration files: all of
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Here the IMO best and most natural solution is to have different blocks
for different implementations. Say we have two different components that
implements the XsltProcessor inteface, the Xalan and the Saxon
implementation. Then if you have a
Daniel Fagerstrom wrote:
No, I meant something different than the mechanism today, something
that works like the PropertyOverrideConfigurer in Spring. Say that you
have a configuration file like:
store logger=core.store
parameter name=maxobjects value=1000/
parameter
Peter Hunsberger skrev:
On 5/17/06, Daniel Fagerstrom [EMAIL PROTECTED] wrote:
snip/
2. This works only as long as the user wants to use the same
implementation for a component. Switching to an own implementation with
an own configuration is not possible.
Any idea on how to solve this?
Ralph Goers skrev:
Daniel Fagerstrom wrote:
No, I meant something different than the mechanism today, something
that works like the PropertyOverrideConfigurer in Spring. Say that you
have a configuration file like:
store logger=core.store
parameter name=maxobjects value=1000/
[CForms] fi:styling type=textarea/ throws NPE in BRANCH
---
Key: COCOON-1851
URL: http://issues.apache.org/jira/browse/COCOON-1851
Project: Cocoon
Type: Bug
Components: Blocks: Forms
Versions: 2.1.8
[
http://issues.apache.org/jira/browse/COCOON-1851?page=comments#action_12412269
]
Kaj Kandler commented on COCOON-1851:
-
Here is my hack for the Null Pointer Exceptions.
EffectWidgetReplacingPipe.java
line 973 ---
if (elementNesting
[ http://issues.apache.org/jira/browse/COCOON-1851?page=all ]
Kaj Kandler updated COCOON-1851:
Attachment: EffectWidgetReplacingPipe.java
[CForms] fi:styling type=textarea/ throws NPE in BRANCH
[ http://issues.apache.org/jira/browse/COCOON-1851?page=all ]
Kaj Kandler updated COCOON-1851:
Attachment: EffectPipe.java
[CForms] fi:styling type=textarea/ throws NPE in BRANCH
---
[ http://issues.apache.org/jira/browse/COCOON-398?page=all ]
Ralph Goers updated COCOON-398:
---
Bugzilla Id: (was: 12139)
I checked in a workaround to this. Basically, it catches the exception and
retries. If the retry fails then it just doesn't include
[
http://issues.apache.org/jira/browse/COCOON-1851?page=comments#action_12412278
]
Antonio Gallardo commented on COCOON-1851:
--
Did you try cocoon 2.1.9? Would you send a patch?
[CForms] fi:styling type=textarea/ throws NPE in BRANCH
45 matches
Mail list logo
