On 9/20/07, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Looking at the program - Bertrand Delacretaz/Carsten Ziegeler: Bye bye
Avalon:
an introduction to OSGi - should this really be Spring, not OSGi? :)
It is OSGi indeed: we're going to introduce the general principles,
and show how easy it is
Bertrand Delacretaz wrote:
On 9/20/07, Vadim Gritsenko [EMAIL PROTECTED] wrote:
Looking at the program - Bertrand Delacretaz/Carsten Ziegeler: Bye bye
Avalon:
an introduction to OSGi - should this really be Spring, not OSGi? :)
It is OSGi indeed: we're going to introduce the general
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=7225projectId=51
Build statistics:
State: Failed
Previous State: Failed
Started at: Thu 20 Sep 2007 00:01:19 -0700
Finished at: Thu 20 Sep 2007 00:01:56 -0700
Total time: 36s
Build Trigger: Schedule
Build
As you probably have noticed, I've started with the release of the POM modules.
So far this shouldn't have affected you except a short period when trunk didn't
build.
I'm going to continue with the jar modules in core and blocks which means that I
ask you not to commit to any of the affected
I also use this release to publish our docs. I wonder now whether I should add
the Javadocs to our docs or not. For the spring-configurator and and
configuration-api I've added them because they are subprojects but I'm not sure
if it is the best idea to add the javadocs of our core modules
Reinhard Poetz wrote:
I also use this release to publish our docs. I wonder now whether I
should add the Javadocs to our docs or not. For the spring-configurator
and and configuration-api I've added them because they are subprojects
but I'm not sure if it is the best idea to add the javadocs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Giacomo Pati wrote:
snip-all
I've isolated the culprit commit that caused our application to stop working.
Our application works
fine up to and excluding commit r567329 which was
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I also use this release to publish our docs. I wonder now whether I
should add the Javadocs to our docs or not. For the
spring-configurator and and configuration-api I've added them because
they are subprojects but I'm not sure if it is the best
Reinhard Poetz wrote:
Reinhard Poetz wrote:
As you probably have noticed, I've started with the release of the POM
modules. So far this shouldn't have affected you except a short period
when trunk didn't build.
I'm going to continue with the jar modules in core and blocks which
means that I
Reinhard Poetz wrote:
As you probably have noticed, I've started with the release of the POM
modules. So far this shouldn't have affected you except a short period
when trunk didn't build.
I'm going to continue with the jar modules in core and blocks which
means that I ask you not to commit
Reinhard Poetz wrote:
Could somebody help me with an additional script which recursivly scans
for the download scripts, sets the x attribute on the file and
executes it then?
Sure; what's the script name / name pattern?
Vadim
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Could somebody help me with an additional script which recursivly
scans for the download scripts, sets the x attribute on the file and
executes it then?
Sure; what's the script name / name pattern?
It will be located in apidocs/create-apidocs.sh
Giacomo Pati pisze:
Giacomo Pati wrote:
snip-all
I've isolated the culprit commit that caused our application to stop working.
Our application works
fine up to and excluding commit r567329 which was
http://article.gmane.org/gmane.text.xml.cocoon.cvs/24998/match=r567329:
Vadim Gritsenko pisze:
Joerg Heinicke wrote:
On 19.09.2007 18:22 Uhr, Grzegorz Kossakowski wrote:
As you see, this pipeline just process simple JX template that tries
to access one variable
(status.myTasks) and fails at this point. It must fail (by throwing
NPE) because there is no
[
https://issues.apache.org/jira/browse/COCOON-2134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grzegorz Kossakowski reopened COCOON-2134:
--
I'm reopening this issue because it's worth to consider other solution, see:
ObjectModelImpl tries to modify UnmodifiableMap
---
Key: COCOON-2135
URL: https://issues.apache.org/jira/browse/COCOON-2135
Project: Cocoon
Issue Type: Bug
Components: - Expression
Grzegorz Kossakowski pisze:
When looking at this issue and the stacktrace you have given above I'm
feeling like having Déjà vu.
I have experienced problem with UnmodifiableMap at the time I made the commit
you mentioned and I
thought that I had fixed it immediately. It turns out that I
On Thu, 20 Sep 2007, Grzegorz Kossakowski wrote:
Date: Thu, 20 Sep 2007 18:54:24 +0200
From: Grzegorz Kossakowski [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: dev@cocoon.apache.org
Subject: Re: pipelineComponent scope troubles (was Code freeze?)
Grzegorz Kossakowski pisze:
When
Giacomo Pati pisze:
I've tried current trunk as well and it seems that the stack trace I've
reported earlier is gone now and I'm again at the NPE from jexl. After
some debugging as you told me, I can confirm that the failing request of
my app is using the one and only OM instance created
For some reason I'm getting this weird error:
[INFO]
[INFO] Building Apache Cocoon
[INFO]task-segment: [install]
[INFO]
[INFO]
Vadim Gritsenko wrote:
[INFO] No Java test frameworks found
Any clues?
Strangely, mvn clean solved this mystery...
Vadim
21 matches
Mail list logo
