RE: [summary][PMC:Proposal] Opening up access to Excalibur/Sandbox

Has Root given any response yet? Maybe on the PMC mailing list? Otherwise, would it be appropriate to send a reminder? On Mon, 2003-05-26 at 14:16, Leo Sutic wrote: > Root, > > the Avalon PMC has decided to open up parts of its CVS to > committers from other projects in order to facilitate > co

Introducing jakarta-regexp dependency in sourcersolver

Hi all, quick background: I'm working on improving relative URL resolving in the sourceresolver. For this I need to parse the structure of an URL, and I'm using a regexp for this (using jakarta-regexp). So I'm now looking at what is involved with introducing the dependency on jakarta-regexp. This

FW: [Checkstyle] Plugin now supports checkstyle 3.1

I used the wrong email address for the avalon dev ml hence the forward. -Vincent > -Original Message- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: 30 May 2003 15:21 > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: [Checkstyle] Plugin now supports ch

Re: On Avalon Library (was: [Fortress] DataSource / Server components)

the best short-term solution might be to just create a page on our website that links to where other components can be found. a registry of sorts. -pete - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail

Re: Patch #14.5 [Fortress] Let's make ContextManager not final!

Anton Tagunov wrote: BL> As this does not refer to a bug, I think I would like to focus on a BL> Fortress 1.0 release. We can apply this and whatever other patches BL> for the next release (which can be soon afterwards if we want). BL> All, I think we are reaching the point where we are delaying

Re: On Avalon Library (was: [Fortress] DataSource / Server components)

J Aaron Farr wrote: --- Berin Loritsch <[EMAIL PROTECTED]> wrote: We have one called "Avalonia"--unless it has been closed out. On SF? If so, I can't find it. Though I do remember reading about it somewhere, perhaps in an old email. Yep. Nothing was done with it for a long time, and it sat e

Re: On Avalon Library (was: [Fortress] DataSource / Server components)

--- Berin Loritsch <[EMAIL PROTECTED]> wrote: > > We have one called "Avalonia"--unless it has been closed out. > On SF? If so, I can't find it. Though I do remember reading about it somewhere, perhaps in an old email. > > We would like to get to that point. We have a long ways to go first

Re: On Avalon Library (was: [Fortress] DataSource / Server components)

J Aaron Farr wrote: --- Anton Tagunov <[EMAIL PROTECTED]> wrote: So, on the one hand it looks a nice idea to gather a handfull of avalon based stuff in something like the sandbox. It could be a bit like SF, but with the avalon PMC members keeping an eye on maintaining duplication at a reasonable l

Re: [MERLIN] release preparation request for assistance

--- Stephen McConnell <[EMAIL PROTECTED]> wrote: > > Any volunteers out there willing to help with release preparation - > please let me know. Help can be in all sorts of areas - validating > documentation, packaging, testing, etc. > Put me down on the list. I can assist with documentation,

Re: On Avalon Library (was: [Fortress] DataSource / Server components)

--- Anton Tagunov <[EMAIL PROTECTED]> wrote: > > So, on the one hand it looks a nice idea to gather a handfull > of avalon based stuff in something like the sandbox. > It could be a bit like SF, but with the avalon PMC members > keeping an eye on maintaining duplication at a reasonable level > an

on excalibur-extension (wrt Merlin release)

Hello Stephen and All! SM> 4. either release Excalibur Extension or include a fork SM> under the Merlin project So, it has not been released yet! The contract of InstrumentManager still seems funny to me. Maybe it would make sense move from instrumentable.setInstrumentableName( "bar"

[patch] meta-tools for merlin

Hi, when I used the javadocs-tags for all my merlin services I finally came across the need, to collect all the tags from the overwritten service-methods of the complete inehritance graph, to produce the correct xtype-file. the attached patch just does this for service, enableLogging and contex

[GUMP] PRE-REQ FAILED for phoenix-example-testserver

onitor/build/lib/excalibur-monitor-20030530.jar from excalibur-monitor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] PRE-REQ FAILED for phoenix-example-pdk

/build/lib/excalibur-monitor-20030530.jar from excalibur-monitor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] PRE-REQ FAILED for phoenix-example-demo

/build/lib/excalibur-monitor-20030530.jar from excalibur-monitor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] PRE-REQ FAILED for avalon-phoenix

ld/lib/excalibur-monitor-20030530.jar from excalibur-monitor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

[GUMP] Build Failure - excalibur-store

This email is autogenerated from the output from: Buildfile: build.xml Caught exception (org.apache.tools.ant.BuildException

[GUMP] Build Failure - excalibur-fortress

This email is autogenerated from the output from: Buildfile: build.xml checkBCEL: dependencies: compile: [javac] C

cvs commit: avalon-sandbox/merlin/meta/src/java/org/apache/avalon/meta/model/builder XMLProfileCreator.java

mcconnell2003/05/30 03:21:04 Modified:merlin/meta/src/java/org/apache/avalon/meta/model/builder XMLProfileCreator.java Log: Updates to move from to for context entry constructor arguments. Revision ChangesPath 1.4 +5 -4 avalon-sandbox

cvs commit: avalon-site/site/sandbox/merlin - Imported sources

mcconnell2003/05/30 03:13:50 Log: no message Status: Vendor Tag: MCCONNELL Release Tags: DOCS_030530 U avalon-site/site/sandbox/merlin/changelog-report.html U avalon-site/site/sandbox/merlin/cvs-usage.html U avalon-site/site/sandbox/merlin/dependencies.html U avalo

cvs commit: avalon-sandbox/merlin/merlin-smp/xdocs/tools/tags navigation.xml

mcconnell2003/05/30 02:53:04 Modified:merlin/merlin-smp/src/tutorial/004/src/config block.xml merlin/merlin-smp/src/tutorial/009/src/config block.xml merlin/merlin-smp/xdocs navigation.xml merlin/merlin-smp/xdocs/about navigation.xml

cvs commit: avalon-sandbox/merlin/merlin-smp/xdocs/starting/advanced/lifecycle - New directory

mcconnell2003/05/30 02:51:16 avalon-sandbox/merlin/merlin-smp/xdocs/starting/advanced/lifecycle - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

cvs commit: avalon-sandbox/merlin/merlin-smp/xdocs/resources - New directory

mcconnell2003/05/30 02:50:07 avalon-sandbox/merlin/merlin-smp/xdocs/resources - New directory - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]

Patch #14.5 [Fortress] Let's make ContextManager not final! (was: Fortress ServiceManager question)

Hello Berin, Shash and All! :-) 1. === SC> ... I now realize that the ServiceManager SC> interface has no "add/put/addService etc." method. One thing is that SC> Fortress could require the supplied service-manager to already have the SC> required servi

On Avalon Library (was: [Fortress] DataSource / Server components)

Hello All! JAF> I'm just a lowly user One more lowly user here :-) JAF> I've started putting together an SF project of my own for more "generic" JAF> Avalon components and I know others have mentioned doing the same. JAF> This trend concerns me a little since it scatters the developer community J

Re: [MERLIN] release preparation request for assistance

I could help :-) But I haven't tried Merlin yet. Anyway, where can I start? On Fri, 30 May 2003, Stephen McConnell wrote: > > Merlin is an Avalon sandbox project that includes a set of containment > facilities, a container, and a number of container extensions. > > http://avalon.apache.org

Re: [MERLIN] release preparation request for assistance

Melvin Dave P. Vivas MCOM/3794 wrote: I could help :-) Super! But I haven't tried Merlin yet. Installation instructions are available here: http://avalon.apache.org/sandbox/merlin/starting/installation.html Anyway, where can I start? A big thing would be a review of the documentation -

[MERLIN] release preparation request for assistance

Merlin is an Avalon sandbox project that includes a set of containment facilities, a container, and a number of container extensions. http://avalon.apache.org/sandbox/merlin/index.html The project contains generic containment facilities for meta management, meta data generation, component asse

EOB, OpenORB, and Avalon

Hello, I'm sorry if this seems to be the wrong place to ask this, but I don't know where else to ask and most everyone with potential answers is here. Basically, if I'm following correctly, EOB (and AltRMI to an extent) and OpenORB both attempt to solve the same problem of distributed services.

RE: Empowering the Developers

> People work on what they feel like, when they feel like it > and as soon you begin trying to stop them from doing this > they will either stop doing the work or fork. Either way > can be a loss for the project. While those may be accurate statements, if the individual wants to work within a Comm

Re: [Fortress] DataSource / Server components

J Aaron Farr wrote: On Thu, 2003-05-29 at 21:11, Stephen McConnell wrote: Noel J. Bergman wrote: Why not an Avalon Library for reusable Avalon Components? +1 This is what I think Cornerstone could be (once the breakout into manageable units is completed). Cheers, Steve.

Re: [Fortress] DataSource / Server components

On Thu, 2003-05-29 at 21:11, Stephen McConnell wrote: > Noel J. Bergman wrote: > > >Why not an Avalon Library for reusable Avalon Components? > > > > +1 > > This is what I think Cornerstone could be (once the breakout into > manageable units is completed). > > Cheers, Steve. I'm just a lowly

Re: [Avalon] Major Issues that are in Conflict

After your clarifications and an explanation of what "support" means by another then "yes" to all four. On Thu, 29 May 2003 05:33 am, Berin Loritsch wrote: > According to your response, the PMC recognizes that you are in agreement > with three out of the four issues, and are in disagreement with

Re: [Fortress] DataSource / Server components

Noel J. Bergman wrote: Why not an Avalon Library for reusable Avalon Components? +1 This is what I think Cornerstone could be (once the breakout into manageable units is completed). Cheers, Steve. -- Stephen J. McConnell mailto:[EMAIL PROTECTED] http://www.osm.net Sent via James running un

Empowering the Developers

Hi, I don't have the original email but I do have some time to write an email so I figured I would do it now. A while back there was all sorts of claims made about my beliefs - very few of which were accurate. The discussion centered around who made the decisions (aka managers) and who did the

RE: [Fortress] DataSource / Server components

> > there is not really a place where general avalon components > > can live. Is that something that would be worth creating? > if you are willing to support them I would recomend you > submit them to jakarta-commons. I was under the impression that Jakarta-Commons doesn't want them. Why not an

Re: [Fortress] DataSource / Server components

On Thu, 29 May 2003 10:48 am, Leif Mortenson wrote: > Anyway, how does the avalon community want to handle these? There > is Avalon apps for Phoenix blocks, but there is not really a place where > general avalon components can live. Is that something that would be > worth creating? You need to s

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/impl AbstractContainer.java

bloritsch2003/05/29 14:09:29 Modified:fortress/src/java/org/apache/avalon/fortress/impl AbstractContainer.java Log: Fix problem when a component depends on a component not managed by this container. Revision ChangesPath 1.34 +8 -1 avalon

cvs commit: avalon-sandbox/merlin/merlin-core/src/java/org/apache/avalon/merlin/block/impl StandardBlock.java

mcconnell2003/05/29 14:01:38 Modified:merlin/merlin-core/src/java/org/apache/avalon/merlin/block/impl StandardBlock.java Log: Make the engine available explicity in context for a compoinent acting as a container (equivalent to getting the context classloader

cvs commit: avalon-sandbox/merlin/assembly/src/java/org/apache/avalon/assembly/appliance/impl DefaultAppliance.java

mcconnell2003/05/29 14:00:03 Modified:merlin/assembly/src/java/org/apache/avalon/assembly/appliance/impl DefaultAppliance.java Log: Addition of state validity checks on context accessor. Revision ChangesPath 1.8 +9 -1 avalon-sandbox/mer

cvs commit: avalon-sandbox/merlin/assembly-spi/src/java/org/apache/avalon/assembly/engine Engine.java

mcconnell2003/05/29 13:58:55 Modified:merlin/assembly-spi/src/java/org/apache/avalon/assembly/engine Engine.java Log: Addition of a KEY constant for the Engine interface. Revision ChangesPath 1.5 +3 -1 avalon-sandbox/merlin/assembly-spi

cvs commit: avalon-excalibur/fortress/src/tools/org/apache/avalon/fortress/tools Component.java

bloritsch2003/05/29 13:53:24 Modified:fortress/src/tools/org/apache/avalon/fortress/tools Component.java Log: Refactoring to increase readability and reliability. Ensures first match is used. Revision ChangesPath 1.12 +27 -20 avalon-excal

Re: Fortress ServiceManager question

Berin, I looked at the CVS code last night, and it seems like the latest code acquires the ServiceManager from the container-manager context, and then proceeds to wrap it in a DefaultServiceManager. Is there any reason why the wrapping needs to happen? In our application, we have a specializ

Re: Fortress ServiceManager question

Anton, Hello Shash! SC> I looked at the CVS code last night, and it seems like the latest code SC> acquires the ServiceManager from the container-manager context, and then SC> proceeds to wrap it in a DefaultServiceManager. Is there any reason why the SC> wrapping needs to happen? In our app

cvs commit: avalon-excalibur/fortress/src/tools/org/apache/avalon/fortress/tools Component.java

bloritsch2003/05/29 13:23:00 Modified:fortress/src/tools/org/apache/avalon/fortress/tools Component.java Log: Fix error where classes in the same package were not concidered. Revision ChangesPath 1.11 +26 -15 avalon-excalibur/fortress/src/

[Fortress] Is all ok with our InstrumentManager/Instrumentable hierarchy?

Hello, Developers! ComponentFactory.java name = configuration.getAttribute( "id" ); m_context.put( "component.name", name ); InstrumentableCreator.java says (pseudocode) instrumentableName = context.get( "component.name" ); m_instrumentManager.registerInstrumenta

[VOTE] Is Fortress Good Enough (tm) (was Re: Patch #14 -- providingone more extension point)

Anton Tagunov wrote: Hello Berin! BL> If we don't get any more patches in 24 hours, I will put it up for vote again. Plz don't cout this one, it's quite cosmetic, but something that I personally will probably use in the future. Yes, and Shash seems to have reported that they have been quite activ

cvs commit: avalon-excalibur/fortress/src/tools/org/apache/avalon/fortress/tools Component.java

bloritsch2003/05/29 12:56:23 Modified:fortress/src/tools/org/apache/avalon/fortress/tools Component.java Log: Fix NullPointerException Revision ChangesPath 1.10 +16 -6 avalon-excalibur/fortress/src/tools/org/apache/avalon/fortress/tools/C

Patch #14 -- providing one more extension point

Hello Berin! BL> If we don't get any more patches in 24 hours, I will put it up for vote again. Plz don't cout this one, it's quite cosmetic, but something that I personally will probably use in the future. Yes, and Shash seems to have reported that they have been quite active with producing addi

cvs commit: avalon-excalibur/fortress/src/tools/org/apache/avalon/fortress/tools Component.java

bloritsch2003/05/29 12:29:33 Modified:fortress/src/tools/org/apache/avalon/fortress/tools Component.java Log: Allow for deep dependency checking. Deep dependency checking is used to discover dependencies from abstract base classes, etc. It does not, and c

Re: Fortress ServiceManager question

Shash Chatterjee wrote: I looked at the CVS code last night, and it seems like the latest code acquires the ServiceManager from the container-manager context, and then proceeds to wrap it in a DefaultServiceManager. Is there any reason why the wrapping needs to happen? In our application, we ha

Re: Fortress ServiceManager question

Hello Shash! SC> I looked at the CVS code last night, and it seems like the latest code SC> acquires the ServiceManager from the container-manager context, and then SC> proceeds to wrap it in a DefaultServiceManager. Is there any reason why the SC> wrapping needs to happen? In our application,

Re: Fortress: BCEL llibrary problem

Berin Loritsch wrote: Peter Severin wrote: Hi Berin I guess a configuration option would be helpful. I would do it myself but at this moment a have no time for such things so I prefer hacks which of course cannot be contributed to the project :). But at least I can provide you with some feedba

cvs commit: avalon-excalibur/fortress/src/test/org/apache/avalon/fortress/test ContainerProfile.xconf ContainerProfile.roles ContainerProfile.java ContainerProfile.xlog

bloritsch2003/05/29 10:51:17 Modified:fortress/src/test/org/apache/avalon/fortress/impl/role/test Role2MetaInfoManagerTestCase.java ConfigurableRoleManagerTestCase.java AbstractRoleManagerTestCase.java

Re: Fortress: BCEL llibrary problem

1) Add an attribute to the root config element in the .xconf which identifies the type of config we want such as "proxy-type". 2) proxy-type="none" uses a NoopWrapperObjectFactory (one that does nothing) There have been many discussions about this in the past for people to find out about

Fortress ServiceManager question

I looked at the CVS code last night, and it seems like the latest code acquires the ServiceManager from the container-manager context, and then proceeds to wrap it in a DefaultServiceManager. Is there any reason why the wrapping needs to happen? In our application, we have a specialized lookup

Re: Fortress: BCEL llibrary problem

Shash Chatterjee wrote: Berin, 1) Add an attribute to the root config element in the .xconf which identifies the type of config we want such as "proxy-type". 2) proxy-type="none" uses a NoopWrapperObjectFactory (one that does nothing) There have been many discussions about this in the pas

Re: Fortress: BCEL llibrary problem

Berin, 1) Add an attribute to the root config element in the .xconf which identifies the type of config we want such as "proxy-type". 2) proxy-type="none" uses a NoopWrapperObjectFactory (one that does nothing) There have been many discussions about this in the past for people to find out

Re: Fortress: BCEL llibrary problem

Peter Severin wrote: Hi Berin I guess a configuration option would be helpful. I would do it myself but at this moment a have no time for such things so I prefer hacks which of course cannot be contributed to the project :). But at least I can provide you with some feedback which I think this p

Re: Fortress: BCEL llibrary problem

Peter Severin wrote: Hi Berin I guess a configuration option would be helpful. I would do it myself but at this moment a have no time for such things so I prefer hacks which of course cannot be contributed to the project :). But at least I can provide you with some feedback which I think this p

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/impl DefaultContainer.java AbstractContainer.java

bloritsch2003/05/29 10:14:45 Modified:fortress/src/java/org/apache/avalon/fortress/impl/factory ProxyManager.java fortress/src/java/org/apache/avalon/fortress/impl DefaultContainer.java AbstractContainer.java Log: Update

Re: Fortress: BCEL llibrary problem

Hi Berin I guess a configuration option would be helpful. I would do it myself but at this moment a have no time for such things so I prefer hacks which of course cannot be contributed to the project :). But at least I can provide you with some feedback which I think this project always needs.

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/impl/factory NoopObjectFactory.java AbstractObjectFactory.java BCELWrapperGenerator.java

bloritsch2003/05/29 09:42:45 Modified:fortress/src/java/org/apache/avalon/fortress/impl/factory AbstractObjectFactory.java BCELWrapperGenerator.java Added: fortress/src/java/org/apache/avalon/fortress/impl/factory

cvs commit: avalon-excalibur/fortress/src/java/org/apache/avalon/fortress/impl AbstractContainer.java

bloritsch2003/05/29 09:29:06 Modified:fortress/src/java/org/apache/avalon/fortress/impl AbstractContainer.java Log: Apply part II of Anton's patch 10.1--customize the lifecycle manager Revision ChangesPath 1.32 +166 -106 avalon-excalibur/for

Re: Fortress: BCEL llibrary problem

Peter Severin wrote: Hi all, I am progressing with less and less patience through fortress setup. I have an impression that there are not many users using this project as I see many problems that should be visible in any non trivial project. I was given an impression that fortress is very close

Re: [Fortress] Meta tags and javadocs

You can include multipole -tag arguments. Docu for the format is under the Javadoc tools in the JDK installlation. Cheers, Steve. Leif Mortenson wrote: Does anyone know had to get rid of errors like the following when generating javadocs for classes which include meta tags? [javadoc] C:

Re: [Fortress] Datasource and meta info

Anton, Actually I tried this exact thing yesterday. Great minds think alike. It was not working because the services.list file for the main jar still contained references to the services from all 3 jars. But good news is that I just tried it again, and it is now working correctly. Someone m

[Fortress] Meta tags and javadocs

Does anyone know had to get rid of errors like the following when generating (Bjavadocs for classes which include meta tags? (B (B[javadoc] (BC:\Tanuki\javautils\src\java\com\tanukisoftware\avalon\thread\ResourceLimitingThreadPoolService.java:43: (Bwarning - @avalon.component is an unknown tag

Fortress: BCEL llibrary problem

Hi all, I am progressing with less and less patience through fortress setup. I have an impression that there are not many users using this project as I see many problems that should be visible in any non trivial project. I was given an impression that fortress is very close to a release date b

Re: [RT] you make the decision?

--- Leo Simons <[EMAIL PROTECTED]> wrote: > > > I think it would be nice if someone with a need or desire for promoting > avalon, knowledge of all technologies listed and some writing skill > would take the bait and write a "You Make The Decision"-style document. > > You guys agree? Is th