Project: avalon-cache
State: Failed
URL: http://lsd.student.utwente.nl/gump/avalon-sandbox/avalon-cache.html
- G U M P Y
Annotations:
- Warning - Optional dependency checkstyle failed with reason build failed
- Error - Failed with reason build fai
Project: avalon-cache
State: Failed
URL: http://lsd.student.utwente.nl/gump/avalon-sandbox/avalon-cache.html
- G U M P Y
Annotations:
- Warning - Optional dependency checkstyle failed with reason build failed
- Error - Failed with reason build fai
> The pattern seems to be related to new versus reply messages. I've
> posted about three new messages that simply have not arrived.
This is a new message.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For addit
mcconnell2004/02/04 20:05:12
Modified:merlin/activation/impl/src/test/org/apache/avalon/activation/appliance
AbstractTestCase.java
Log:
Housekeeping.
Revision ChangesPath
1.12 +3 -1
avalon/merlin/activation/impl/src/test/org/apache/avalo
mcconnell2004/02/04 19:17:44
Modified:merlin INSTALL.TXT STRUCTURE.TXT maven.xml project.xml
merlin/facilities/http/api project.xml
merlin/facilities/http/impl project.xml
merlin/facilities/http/listener project.xml
merlin/fac
Hello.
I've been meaning to add something to the exalibur-configuration package
which would allow context variables in configuration files, something like:
Which would be resolved by the container before being passed to the
component in the configure() method. This makes life easier when
> >
> >>-Original Message-
> >>From: Stephen McConnell [mailto:[EMAIL PROTECTED]
>
> In principal I agree with the above. In practice I think we are going
> to have to come up with some good installer solution so that we don't
> end up with multiple installations that end up conflicting
mcconnell2004/02/04 13:19:26
Added: logging .cvsignore
Log:
Housekeeping.
Revision ChangesPath
1.1 avalon/logging/.cvsignore
Index: .cvsignore
===
maven.log
velocity.log
build
mcconnell2004/02/04 13:07:48
Removed: merlin/logging/logkit/api .cvsignore
Log:
Housekeeping.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mcconnell2004/02/04 13:04:48
Removed: merlin/logging/api .cvsignore project.xml
merlin/logging/api/src/java/org/apache/avalon/logging/data
CategoriesDirective.java CategoryDirective.java
package.html
merlin/log
mcconnell2004/02/04 12:49:17
Log:
no message
Status:
Vendor Tag: AVALON
Release Tags: AVALON_LOGGING
N avalon/logging/LICENSE.txt
N avalon/logging/maven.xml
N avalon/logging/project.properties
N avalon/logging/project.xml
N avalon/logging/README.TXT
N avalon/lo
Woah.
I finally finished reading the MutableConfiguration thread(s). Leo is
right, Gump might be a TLP before this gets done! :) Anyway, here's my take
on a number of the issues presented:
Contents
1. Comments on the Proposal and Implementation Details
2. Original Proposal: MutableConfigurati
Stephen McConnell wrote:
Presumable you meant to say that DefaultConfiguration as opposed to
MutableConfiguration?
yep. s/Mutable/Default/.
And independently of that - it seems to me that
this thread is addressing the issue.
yeah, but frustratingly slowly, and with lots of energy expenditure.
T
mcconnell2004/02/04 10:46:44
Log:
no message
Status:
Vendor Tag: AVALON
Release Tags: DOCS_20040204
U avalon-site/site/util/cvs-usage.html
U avalon-site/site/util/dependencies.html
U avalon-site/site/util/download.html
U avalon-site/site/util/index.html
U avalon-
mcconnell2004/02/04 10:26:36
Modified:util/extension/impl/src/java/org/apache/avalon/extension/manager/impl
package.html
util/xdocs/criteria navigation.xml
util/xdocs/defaults navigation.xml
util/xdocs/env navigation.xm
mcconnell2004/02/04 10:15:15
Modified:merlin/activation/impl project.xml
merlin/activation/spi project.xml
merlin/composition/api project.xml
merlin/composition/impl project.xml
merlin/composition/spi project.xml
Leo Simons wrote:
Stephen McConnell wrote:
What do think?
a) MutableConfiguration is IMHO seriously flawed because it exposes a
work interface which is not defined using an actual interface;
Presumable you meant to say that DefaultConfiguration as opposed to
MutableConfiguration? And independ
Stephen McConnell wrote:
What do think?
a) MutableConfiguration is IMHO seriously flawed because it exposes a
work interface which is not defined using an actual interface;
b) it is straight-forward to extract the work interface from
MutableConfiguration and make it an actual interface (any half-
mcconnell2004/02/04 09:26:06
Modified:util maven.xml
Log:
Update the javadoc generation to incude the extensions content.
Revision ChangesPath
1.12 +2 -0 avalon/util/maven.xml
Index: maven.xml
==
mcconnell2004/02/04 09:24:22
Log:
Addition of extension under the utils project so we can use this content as part of
the avalon-repository implementation.
Status:
Vendor Tag: AVALON
Release Tags: AVALON_EXTENSION_1_1
N avalon/util/extension/api/.cvsignore
N avalon/ut
Leo Sutic wrote:
From: Stephen McConnell [mailto:[EMAIL PROTECTED]
Leo:
Niclas does not need to veto anything because I already have.
Stephen,
still, he's a committer and *can* veto. While he hasn't done so,
he's not part of any existing consensus among some committers that
MutableConfigura
Hi, Leo!
LSU> fork would take about 1.5 minutes, and the results
LSU> would be ...
Maybe this thought is not worth a mail - but..
you may
fork *DefaultConfiguration* only by
makeing a tiny project and
putting new interface and forked impl there
That's what going to happen in -spi anyway
mcconnell2004/02/04 08:16:49
Modified:repository maven.xml
Log:
Fix maven_gpg_exe handling.
Revision ChangesPath
1.14 +18 -18avalon/repository/maven.xml
Index: maven.xml
===
RCS file: /home/
> From: Stephen McConnell [mailto:[EMAIL PROTECTED]
>
> Leo:
>
> Niclas does not need to veto anything because I already have.
Stephen,
still, he's a committer and *can* veto. While he hasn't done so,
he's not part of any existing consensus among some committers that
MutableConfiguration shou
Leo:
Niclas does not need to veto anything because I already have. Lets
stick with the real subject and the real concerns.
Firstly:
MultibleConfiguration should not be exposed under the
Avalon client API.
Secondly:
MultibleConfiguration as you have proposed it extends Configuration
wh
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
>
> On Wednesday 04 February 2004 19:33, Leo Sutic wrote:
> > > From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
> > > What you add today, I and others have to support tomorrow.
>
> > So how come you think you have to support my implementation of
On Wednesday 04 February 2004 19:33, Leo Sutic wrote:
> > From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
> > What you add today, I and others have to support tomorrow.
> So how come you think you have to support my implementation of
> configurators, just because I'm adding a MutableConfiguration
>
> -Original Message-
> From: Anton Tagunov [mailto:[EMAIL PROTECTED]
> Sent: den 4 februari 2004 12:52
> To: Avalon Developers List
> Subject: Re[2]: MutableConfiguration
>
>
> Come on guys, be nice! :-)
>
>
> LSU> MutableConfiguration ... to plug what ... a hole in
> LSU> the Avalon
Come on guys, be nice! :-)
LSU> MutableConfiguration ... to plug what ... a hole in
LSU> the Avalon architecture - that we had no interface abstraction
LSU> for DefaultConfiguration.
Do you feel there's same hole also with
* DefaultServiceManager
* DefaultContext
I would say yes. And if we ab
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
>
> What you add today, I and others have to support tomorrow.
(...)
> I could vote -1, and then shut up, but I try to turn your
> proposal into
> something positive, yet getting harassed for it.
So how come you think you have to support my imp
On Wednesday 04 February 2004 18:11, Leo Sutic wrote:
> Now you turn around and say that I have to evolve the use case
> into something industrial-strength and include it in the proposal
> before you'll consider MutableConfiguration.
Without the "industrial-strength" there is no reason to make it
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]
>
> is your use case really desirable to promote as
> the way to go. Right now, I don't feel like it is.
Niclas,
whether my use case is the way to go or not is *not relevant*.
I didn't ask you to validate and endorse the design of my use
case, I
On Wednesday 04 February 2004 15:52, Leo Simons wrote:
> why would you want listeners?
So that a component can be replaced on the fly, without unloading everything.
It is also a necessity for a Jini-driven service discovery mechanism under the
hood, where services may or may not be available, co
Stephen McConnell wrote:
3.3 walk-in-the-park.
is there a timeline to look at?
exposing a Object get( key ) - I think that instead we
should be thinking more along the lines of
void addServiceAvailabilityListener(
ServiceAvailabilityListener listener, Something key );
Thoughts?
well, t
34 matches
Mail list logo
