Hello,
This is a second attempt to resolve problem with inaccurate version information
in JIRA which I
described here[1]. The first one was to split up our COCOON project into
several smaller ones[2].
Unfortunately, this option had several drawbacks like broken links to the
current issues.
Hi Daniel,
[EMAIL PROTECTED] pisze:
Author: danielf
Date: Sat Aug 25 03:37:44 2007
New Revision: 569656
URL: http://svn.apache.org/viewvc?rev=569656view=rev
Log:
Actually all samples work.
Modified:
cocoon/whiteboard/osgi/README.txt
I see that you are playing with OSGi in
Hi,
I wanted let you know that I have created Daisy site for
cocoon-expression-language module. It was
very easy because everything is explained here:
http://cocoon.zones.apache.org/daisy/cdocs/g3/1223.html
I must visit our Daisy more often; our documentation system is no less fun than
As some of you might have seen in the SVN logs, I have started to work
on making Cocoon work under OSGi again [1].
This will, for the moment, not affect the trunk more than that I might
refactor or reorganize some stuff based on needs for the OSGi integration.
The main reasons for working on
Grzegorz Kossakowski skrev:
Hi Daniel,
[EMAIL PROTECTED] pisze:
Author: danielf
Date: Sat Aug 25 03:37:44 2007
New Revision: 569656
URL: http://svn.apache.org/viewvc?rev=569656view=rev
Log:
Actually all samples work.
Modified:
cocoon/whiteboard/osgi/README.txt
I see that you are
Grzegorz Kossakowski wrote:
Hello,
This is a second attempt to resolve problem with inaccurate version information
in JIRA which I
described here[1]. The first one was to split up our COCOON project into
several smaller ones[2].
Unfortunately, this option had several drawbacks like broken
Grzegorz Kossakowski wrote:
this one is quite obvious:
markLocalContext() should be executed only if a context object is
explicitly set with jx:import uri=sth context=${contextObject}/
(or should not?)
You are right, the problem is with local contexts. I remember that I didn't
understand what
Leszek Gawron pisze:
1. What's the scope of variable introduced by jx:set?
you are probably asking the wrong question. jx:set always puts a
variable in current context. The question should be: which
elements/instructions should trigger a new local context.
I think new local context should
On 26.08.2007 16:07 Uhr, Grzegorz Kossakowski wrote:
Are these valid xml files?:
Nit-picking: None of them is valid as there is nothing to validate
against like a DTD or a schema. You can only talk about well-formedness.
root
foo:foo xmlns:foo=http://foo.org/1.0;
/foo:foo
!--
On 26.08.2007 7:29 Uhr, Grzegorz Kossakowski wrote:
Unexpectedly, Nils Kaiser has come up with much better and, in general, less
intrusive solution. He
proposed[3] to introduce custom fields where information about version specific
to the *component*
would be stored.
I don't want to rain on
10 matches
Mail list logo
