> -Original Message-
> From: Giacomo Pati [mailto:[EMAIL PROTECTED]
> Sent: 24 October 2004 15:45
> To: Cocoon-Dev
> Subject: Re: [VOTE] Remove excalibur instrumentation support from 2.2
>
> On Sun, 24 Oct 2004, Carsten Ziegeler wrote:
>
> > The ECM++ is now integrated in 2.2 and it see
> -Original Message-
> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
> Because they have been around forever *AND* they don't change their
> contracts overnight.
So who is changing contracts Stefano?
> -Original Message-
> From: Gump [mailto:[EMAIL PROTECTED]
> -ERROR- Bad Dependency. Project: excalibur-compatibility unknown to
> *this* workspace
You can fix this error by replacing the following line:
with this:
> -ERROR- Bad Dependency. Project: excalibur-i18n unknown to
> -Original Message-
> From: Gump [mailto:[EMAIL PROTECTED]
> Sent: 02 October 2004 13:40
> To: [EMAIL PROTECTED]
> Subject: [EMAIL PROTECTED]: cocoon-2.1/cocoon failed
>
> To whom it may engage...
>
> This is an automated request, but not an unsolicited one. For
> more information plea
> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sent: 01 October 2004 22:34
> To: [EMAIL PROTECTED]
> Subject: Re: [EMAIL PROTECTED]: cocoon-2.1/cocoon failed
>
> Gump wrote:
>
> >To whom it may engage...
> >
> >This is an automated request, but not an unsolicite
> -Original Message-
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
> Sylvain (who finds very funny to talk to the guy sitting on the other
> side of his office wall through the Internet)
You don't have SMS?
I'm in the process of updating a bunch of Avalon related gump
descriptors to reference current content in svn (as opposed to cvs
content). Part of the transition also involves linking gump build
procedures with magic based builds and getting this all in sync means a
couple of changes on dependent
Vadim Gritsenko wrote:
Stephen McConnell wrote:
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know
what the
status of LogKit is in Avalon itself (did they deprecate it?).
Version 2.0.0 of LogKit has recently been released.
What's new in 2
Unico Hommes wrote:
BTW I am not
following Avalon developement very closely anymore, does anyone know what the
status of LogKit is in Avalon itself (did they deprecate it?).
Version 2.0.0 of LogKit has recently been released.
It is not deprecated.
Cheers, Stephen.
Stefano Mazzocchi wrote:
WDYT?
The reason why logkit was developped was because log4j made extensive
use of static methods and that doesn't work very well with servlet
environments.
Ceki, anything to report on that front?
NOTE: Cocoon is getting fed up with avalon and its community
instabiliti
On 27.03.2004 23:03, Gump wrote:
To whom it may engage...
This is an automated request, but not an unsolicited one. For help understanding the
request please visit http://gump.apache.org/nagged.html, and/or contact
[EMAIL PROTECTED]
Project cocoon has an issue affecting its community integration
://avalon.apache.org/finder/
And javadocs here:
http://avalon.apache.org/finder/api/index.html
Cheers, Stephen.
Carsten
-Original Message-
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 09, 2004 2:20 AM
To: Avalon Developers List
Cc: [EMAIL PROTECTED]
Subject: ECM facility
I've just committed some content into the merlin/facility directory
dealing with a pull-based service finder implementation. This commit is
dealing with two things:
(a) an example of the addition of a semantic extension to
merlin without modification or extension to the container
Stefano Mazzocchi wrote:
On 12 Nov 2003, at 15:31, Stephen McConnell wrote:
Stefano Mazzocchi wrote:
On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
Just a note to let you know that there are a number of
threads currently running over on the [EMAIL PROTECTED]
concerning the
Stefano Mazzocchi wrote:
On 12 Nov 2003, at 12:50, Stephen McConnell wrote:
Just a note to let you know that there are a number of
threads currently running over on the [EMAIL PROTECTED]
concerning the establishment of a component repository
project. After reading your email I think that many
Just a note to let you know that there are a number of
threads currently running over on the [EMAIL PROTECTED]
concerning the establishment of a component repository
project. After reading your email I think that many of the
subjects you have addressed below are relevant to the things
the Avalon c
Steve K wrote:
Hey folks --
I have developed a few Avalon Components (they all extend
AbstractLogEnabled) that I am currently using inside of Cocoon, but I
would like to use them in another, much simpler application. I know
the ExcalibirTestCase does a pretty good job at providing a simple
Joerg Heinicke wrote:
On 03.11.2003 17:18, Berin Loritsch wrote:
It only makes sense to roll back and start concentrating on Cocoon
Blocks
at this time.
I do highly recommend refactoring Cocoon bit by bit to remove ECM
assumptions
wherever they exist so that the actual upgrade to Fortress or
Berin Loritsch wrote:
Geoff Howard wrote:
[EMAIL PROTECTED] wrote:
ghoward 2003/10/25 14:59:50
Modified:src/java/org/apache/cocoon/matching Matcher.java
CookieMatcher.java
Log:
start fortressizing Matchers. lots of open questions already,
so I'll pause here
Carsten Ziegeler wrote:
Stephen McConnell wrote:
When you have a hierarchy of component managers (I still call them
component managers :) ), and you lookup a selector on the child CM
and then try to lookup a component using a hint that is not defined
in this selector but in a selector with
Leo Sutic wrote:
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]
So in this sax streaming we have a class called
EnvironmentChanger that takes care that the current collection
used is the correct one.
So if the sub request sends an event to the main request,
a pointer is set pointing to
Carsten Ziegeler wrote:
Berin Loritsch wrote:
Carsten Ziegeler wrote:
Berin Loritsch wrote:
Yes, I think this is basically our extension together with the
ParentAware
support.
* ParentAware
A selector (or any other component) can declare that it is
ParentAware,
Carsten Ziegeler wrote:
Berin Loritsch wrote:
Initial comments about CocoonComponentManager--to make sure I don't forget
anything it is currently doing:
The CocoonComponentManager handles several aspects including:
* Request scoped components
* Source Resolver specifics for a processor/reque
Berin Loritsch wrote:
Stephen McConnell wrote:
Berin:
A couple, of notes in-line...
Berin Loritsch wrote:
Request Scoped Components: Create a new lifestyle handler for Fortress.
Is this equivalent to the creation of a new component instance for
each invocation against the service
Geoff Howard wrote:
Geoff Howard wrote:
But a browse around ibiblio reveals:
http://www.ibiblio.org/maven/jms/
http://www.ibiblio.org/maven/jndi/
exist but don't have any jars.
And looks like Stephen knows why - I had assumed ASF was being
conservative (wisely, I assume) and that ibiblio wou
Stefano Mazzocchi wrote:
On Tuesday, Oct 14, 2003, at 18:40 Europe/Rome, [EMAIL PROTECTED] wrote:
haul2003/10/14 09:40:09
Modified:.blocks.properties gump.xml
lib jars.xml
Added: src/blocks/jms/samples sitemap.xmap
src/blocks/jms
Berin:
A couple, of notes in-line...
Berin Loritsch wrote:
Request Scoped Components: Create a new lifestyle handler for Fortress.
Is this equivalent to the creation of a new component instance for each
invocation against the service manager?
Steve.
--
Stephen J. McConnell
mailto:[EMAIL P
Stefano Mazzocchi wrote:
On Thursday, Oct 9, 2003, at 17:15 Europe/Rome, Ryan Hoegg wrote:
Rather than have cocoon blocks extend avalon blocks, I think cocoon
blocks could use avalon blocks.
Ok, I see your point.
Instead of having a /COB-INF and a /BLOCK-inf, perhaps we include
avalon bloc
Geoff Howard wrote:
Stephen McConnell wrote:
Geoff Howard wrote:
If you havn't read up on the blocks docs on the wiki lately (the
last two weeks) you really should. Stefano has put a good series of
pages up detailing the plan and the current implementation ideas.
Another fol
Stefan Bodewig wrote:
The qdox project descriptor points to a jar that no longer exists.
Several parts of Avalon fail to build because of the wrong file name
and as a side effect, Cocoon doesn't get built by Gump as its prereqs
coming from Avalon are missing.
Can you be a bit more specific.
A
Geoff Howard wrote:
If you havn't read up on the blocks docs on the wiki lately (the last
two weeks) you really should. Stefano has put a good series of pages
up detailing the plan and the current implementation ideas.
Another followup question related to the following note on the wiki:
Geoff Howard wrote:
If you havn't read up on the blocks docs on the wiki lately (the last
two weeks) you really should. Stefano has put a good series of pages
up detailing the plan and the current implementation ideas.
Just a couple of observations -
The usage of /BLOCK-INF may conflict w
Stefan Kostopoulos wrote:
Hi everybody!
I try to unit test a generator, but cannot find the source/class for:
org.apache.avalon.excalibur.testcase.ExcaliburTestCase
In which jar file should this package be located?
ExcaliburTestCase is a part of the depricated Excalibur Component package.
Bi
remain open and
receptive to ideas and experience that other communities have to offer.
Stephen.
Stefano Mazzocchi wrote:
On Thursday, Oct 2, 2003, at 16:59 Europe/Rome, Stephen McConnell wrote:
Please - go back and take another look.
Stephen,
while I thank you for your interest in cre
Geoff Howard wrote:
Stephen McConnell wrote:
Sylvain Wallez wrote:
Geoff Howard wrote:
Upayavira wrote:
So you won't be able to include and share arbitrary components
between blocks? i.e. components that have arbitrary interfaces?
They'll all have to follow interfaces th
Stefano Mazzocchi wrote:
On Thursday, Oct 2, 2003, at 15:04 Europe/Rome, Stephen McConnell wrote:
1) lack of polymorphic dependencies
Dependencies are adaptive to the implementation strategy.
A block author does not need to declare any dependencies as these
are implicity established based
Stefano Mazzocchi wrote:
On Wednesday, Oct 1, 2003, at 16:22 Europe/Rome, Stephen McConnell wrote:
Stefano Mazzocchi wrote:
So, a few questions:
1) where is the DTD of your block.xml?
There is no DTD due to the fact that we wanted to include user
configuration directly in component
Stefano Mazzocchi wrote:
If its collaboration then some concrete things need to be
considered on the Avalon side and communication channels need to be
established. If not - there are migration issues related to
ECM/Fortress that can take a back seat in favour of other priorities.
? you a
Well that was intended as an offlist message.
Now that its on-list - maybe its a good idea to get some broader feedback?
Stephen.
Stephen McConnell wrote:
Geoff:
Just wanted to followup with you on the subject of
Merlin/Cocoon/Avalon/Blocks/etc.
A few weeks ago there were several [EMAIL
Geoff:
Just wanted to followup with you on the subject of
Merlin/Cocoon/Avalon/Blocks/etc.
A few weeks ago there were several [EMAIL PROTECTED] people pushing for
greater collaboration with Cocoon on the Merlin/Cocoon block question.
That was the stimulus for taking a more proactive role in pu
Stephen McConnell wrote:
Stefano Mazzocchi wrote:
3) how open are you/avalon to changes to this DTD?
Totally open.
However, a better question is how reasonable is it to extend the
deployment and composition object model instances. This implies
implementation of readers and writers that
Stefano Mazzocchi wrote:
So, a few questions:
1) where is the DTD of your block.xml?
There is no DTD due to the fact that we wanted to include user
configuration directly in component directives. Instead we aim to apply
schema validation via tools - but this is work in progress. In the
Stefano Mazzocchi wrote:
On Wednesday, Oct 1, 2003, at 09:49 Europe/Rome, Michael Lipp wrote:
Hi,
having studied the avalon concepts some time ago, I just came upon a
point where I wanted to take advantage of them and failed. Let me
tell you why.
I have a problem with filenames of Java file
Michael:
A couple of comments - the issue of the Component interface was
addressed 12-18 months ago with the introduction of the service
sub-package in the framework. The Component interface along with the
entire component sub-package is now depricated. The replacement
org.apache.avalon.fram
Geoff Howard wrote:
Stephen McConnell wrote:
Geoff Howard wrote:
If you havn't read up on the blocks docs on the wiki lately (the
last two weeks) you really should. Stefano has put a good series of
pages up detailing the plan and the current implementation ideas.
Just a coup
Geoff Howard wrote:
If you havn't read up on the blocks docs on the wiki lately (the last
two weeks) you really should. Stefano has put a good series of pages
up detailing the plan and the current implementation ideas.
Just a couple of observations -
The usage of /BLOCK-INF may conflict w
Stefano Mazzocchi wrote:
as a matter of fact, we don't. It's plain vanilla ant 1.5.4 and it's
there only because not everybody has ant installed. Same thing for
jetty, it's called "convenience" and makes it easier for users and
developers to get started.
Is there a specific reason why ther
Geoff Howard wrote:
If you havn't read up on the blocks docs on the wiki lately (the last
two weeks) you really should. Stefano has put a good series of pages
up detailing the plan and the current implementation ideas.
Just a couple of observations -
The usage of /BLOCK-INF may conflict w
Sylvain Wallez wrote:
Geoff Howard wrote:
Upayavira wrote:
So you won't be able to include and share arbitrary components
between blocks? i.e. components that have arbitrary interfaces?
They'll all have to follow interfaces that already exist within
Cocoon? Or am I missing something?
N
Just for reference.
http://maven.apache.org/builds/release/1.0-rc1/
Steve.
Original Message
Subject:Maven 1.0-RC1 released
Date: Mon, 29 Sep 2003 16:43:39 +1000
From: [EMAIL PROTECTED]
Reply-To: Maven Developers List <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Having been though the process of setting up Maven for several projects
- and during the process experienced the evolution form Maven 0.7 to the
current 0.10, I can confirm that Maven in its current form is usable and
functional.
There are bugs in the Maven 10 release, many of which have been r
51 matches
Mail list logo
