The current version of trunk is feature complete; we only have one item
left which we discussed briefly at the GetTogether and a little bit more
in the past weeks in this mailing list: removing the need of the maven
deploy plugin.
There is one major advantage: make the use of maven 2 for building
Carsten Ziegeler cziegeler at apache.org writes:
So the final part is how to avoid the maven deploy plugin? We recently
discussed a possible solution which works using some classloader
functionality, some new protocols and so on and does not require any
extraction of files during deployment
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Joerg Heinicke wrote:
IMHO this is too fast. We did not receive any feedback on the 2.2 stuff
from any non-committer (only people working with committers). We should
run through some release candidates first, which gives the users the
Joerg Heinicke wrote:
Carsten Ziegeler cziegeler at apache.org writes:
So the final part is how to avoid the maven deploy plugin? We recently
discussed a possible solution which works using some classloader
functionality, some new protocols and so on and does not require any
extraction of
Hi,
how do you use an Avalon component in a Spring bean? With Spring you are
supposed to inject the dependency via the bean XML config. There you
need a bean-id of the component to inject. What if this component is not
defined as a Spring bean but is an Avalon component? Do I simply use the
Carsten Ziegeler wrote:
The current version of trunk is feature complete; we only have one item
left which we discussed briefly at the GetTogether and a little bit more
in the past weeks in this mailing list: removing the need of the maven
deploy plugin.
There is one major advantage: make the
Alexander Klimetschek wrote:
Hi,
how do you use an Avalon component in a Spring bean? With Spring you are
supposed to inject the dependency via the bean XML config. There you
need a bean-id of the component to inject. What if this component is not
defined as a Spring bean but is an
Reinhard Poetz wrote:
do we establish any contracts? I guess the only thing is the includes in
cocoon.xconf, right?
Yes.
Carsten
--
Carsten Ziegeler - Open Source Group, SN AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
On 26 Oct 2006, at 20:35, Lars Trieloff wrote:
But in this case the repeater's add-button should only do an ajax-
request and add the new contents behind the already existing
repeater-rows. So I think the main problem is making the repeater
AJAX-aware.
Repeaters are already
[
http://issues.apache.org/jira/browse/COCOON-1939?page=comments#action_12445588
]
Alexander Klimetschek commented on COCOON-1939:
---
With this fix polymorphic calls no longer work. Eg. (with A -- super -- B),
calling B, then super
Carsten Ziegeler schrieb:
But roles are a different concept than bean-ids
Why do you think so?
I am not a Spring expert, but roles have this inheritance concept, and
bean-ids are merely just IDs, aren't they?
Alex
--
Alexander Klimetschek
http://www.mindquarry.com
Alexander Klimetschek wrote:
Carsten Ziegeler schrieb:
But roles are a different concept than bean-ids
Why do you think so?
I am not a Spring expert, but roles have this inheritance concept, and
bean-ids are merely just IDs, aren't they?
Ah, yes, the original idea of Avalon included
Alexander Klimetschek alexander.klimetschek at mindquarry.com writes:
But roles are a different concept than bean-ids
Why do you think so?
I am not a Spring expert, but roles have this inheritance concept, and
bean-ids are merely just IDs, aren't they?
I might be wrong, but there is
Checking for a class doesn't seem to be a good idea I think we
should check for an interface instead.
Implemented.
Maybe we instead could make the DispatcherServlet less intrusive on
the request object by modifying the getServletPath() and getPathInfo
() on the incomming request object
Hello Jorg,
I'm sorry I did not respond to your question earlier.
On Fri, Oct 13, 2006 at 12:42:13PM +0200, Jorg Heymans wrote:
Fred Vos wrote:
[...]
[INFO] Generating war
/path/to/cocoon/trunk/dists/cocoon-dist-samples/target/cocoon-samples.war
[INFO]
Antonio Gallardo said the following on 30/10/06 01:08:
Hi folks,
In http://cocoon.apache.org/2.1/changes.html we read for each release:
snip
Contributors to this release
We thank the following people for their contributions to this release.
This is a list of all people who
[ http://issues.apache.org/jira/browse/COCOON-1929?page=all ]
Maurizio Pillitu updated COCOON-1929:
-
Attachment: cocoon-r469167.diff
Adapted patch after cocoon-core xconf location refactoring
Added cocoon-core-sample dependency to cocoon-webapp
Hi Guys
Ross and I managed to update our presentation on the wiki.
Enjoy
regards Jeremy
On 13 Oct 2006, at 14:48, Vadim Gritsenko wrote:
Hi,
Many presentations are already uploaded to the wiki [1], but some
are missing. Any chance of getting them all up?
Jeremy, last slide of your
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
do we establish any contracts? I guess the only thing is the includes in
cocoon.xconf, right?
Yes.
let's implement your solution c). If somebody comes up with something better
before we release the final 2.2, we can change it, otherwise we go
Torsten Curdt wrote:
On 10/15/06, Reinhard Poetz [EMAIL PROTECTED] wrote:
Because of a lot of work on our open Jira issues (thanks guys!) you
might have
overlooked it: Maurizio provided a patch that enables Torsten's reloading
classloader in trunk (again)[1]. I think we should apply it so
On 10/30/06, Reinhard Poetz [EMAIL PROTECTED] wrote:
Torsten Curdt wrote:
On 10/15/06, Reinhard Poetz [EMAIL PROTECTED] wrote:
Because of a lot of work on our open Jira issues (thanks guys!) you
might have
overlooked it: Maurizio provided a patch that enables Torsten's reloading
On 30.10.2006 18:52, Torsten Curdt wrote:
I've already applied it on my machine and can do the commit ...but I
think Maurizio also did another update to it to re-enable the
component reloading as well. Maurizio?
...also think it would be really worth having that in ASAP
could you apply
Mounting the same subsitemap multiple time, but with different prefixes, causes
an error
Key: COCOON-1945
URL: http://issues.apache.org/jira/browse/COCOON-1945
[ http://issues.apache.org/jira/browse/COCOON-1929?page=all ]
Maurizio Pillitu updated COCOON-1929:
-
Attachment: cocoon-core-r469213.diff
Last patcheset was missing some files; this is the right one.
[PATCH] Reloading classloader in Cocoon 2.2
[PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and showing
cform templates
---
Key: COCOON-1946
URL: http://issues.apache.org/jira/browse/COCOON-1946
[ http://issues.apache.org/jira/browse/COCOON-1946?page=all ]
Maurizio Pillitu updated COCOON-1946:
-
Attachment: cocoon-javaflow-r469213.diff
[PATCH] - Javaflow Sample errors trying to enhance Javaflow classes and
showing cform templates
[
http://issues.apache.org/jira/browse/COCOON-1946?page=comments#action_12445686
]
Maurizio Pillitu commented on COCOON-1946:
--
This issue depends on http://issues.apache.org/jira/browse/COCOON-1929
[PATCH] - Javaflow Sample errors
Ralph Goers wrote:
This may not be too big a deal for Cocoon trunk. So long as flowscript
is an optional part of Cocoon I believe we are OK. However, it probably
also means that while other blocks can take advantage of flowscript they
shouldn't rely on it.
I presume that this will put
Antonio Gallardo wrote:
In http://cocoon.apache.org/2.1/changes.html we read for each release:
snip
Contributors to this release
We thank the following people for their contributions to this release.
This is a list of all people who participated as committers:
[Committer's
I don't believe it works like that. My understanding is that as long as
the flowscript block is an optional part of Cocoon then there is no
problem with releasing the flowscript block even if it requires a jar
under the NPL. We just have to provide notice and not include the NPL'd
jar within
30 matches
Mail list logo
