On Mon, 17 Feb 2003, Leo Simons <[EMAIL PROTECTED]> wrote:
> Sam Ruby wrote:
>
>> 1) does the build of altrmi require phoenix?
>
> IIRC it requires phoenix-client.jar and phoenix-metagenerate.jar,
> but nothing else. This is true for many projects (like those in
> avalon-apps) which are listed to
Hi,
I just did a fresh co and this at the top of
ExcaliburComponentManager.java:
g`"ComponentHandler handler =
(ComponentHandler)m_componentHandlers.get( role );
Just thought it looked odd :-)
--
jvz.
Jason van Zyl
[EMAIL PROTECTED]
http://tambora.zenplex.org
In short, man creates fo
Leo Simons wrote:
ouch!
this slipped through I guess because just about everyone has a junit
lib inside their $ANT_HOME/lib. Which will probably fix things :D
Release has already been made and voted upon though, so can't change
that. No biggy I think. Feel free to patch cvs so it works in the
Leif Mortenson wrote:
2) does the build of excalibur component require altrmi?
excalibur component requires instrument-manager which requires
altrmi. Making altrmi an optional dependency for instrument-manager
is on the todo.
component should not need altrmi to build. Altrmi is on
leif2003/02/17 18:51:47
Modified:.depchecker.xml
Log:
Fix the fortress build to reflect the relocation of Altrmi
Reduced the number of duplicate jars stores in the repository.
Revision ChangesPath
1.46 +22 -22avalon-excalibur/depchecker.xml
Ind
leif2003/02/17 18:51:34
Modified:.build.xml
Log:
Fix the fortress build to reflect the relocation of Altrmi
Reduced the number of duplicate jars stores in the repository.
Revision ChangesPath
1.199 +4 -15 avalon-excalibur/build.xml
Index: build.
leif2003/02/17 18:51:22
Removed: instrument-client/lib altrmi-client-impl-0.9.1.jar
altrmi-client-interfaces-0.9.1.jar
altrmi-common-0.9.1.jar altrmi-generator-0.9.1.jar
altrmi-registry-0.9.1.jar
leif2003/02/17 18:51:07
Modified:fortress build.xml default.properties
instrument-client default.properties
instrument-manager default.properties
Log:
Fix the fortress build to reflect the relocation of Altrmi
Reduced the number of duplicate jars s
leif2003/02/17 18:50:46
Added: lib altrmi-client-impl-0.9.1.jar
altrmi-client-interfaces-0.9.1.jar
altrmi-common-0.9.1.jar altrmi-generator-0.9.1.jar
altrmi-registry-0.9.1.jar
altrm
2) does the build of excalibur component require altrmi?
excalibur component requires instrument-manager which requires altrmi.
Making altrmi an optional dependency for instrument-manager is on the
todo.
component should not need altrmi to build. Altrmi is only required by the
instrumen
leif2003/02/17 18:29:01
Modified:fortress default.properties
Log:
Fix line feeds. No other changes.
Revision ChangesPath
1.61 +178 -178 avalon-excalibur/fortress/default.properties
Index: default.properties
===
hammant 2003/02/17 15:29:37
Removed: site/excalibur/altrmi/api package-list stylesheet.css
Log:
altremi removed
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
hammant 2003/02/17 15:28:54
Removed: site/excalibur/altrmi/api/org/apache/excalibur/altrmi/client
package-frame.html package-summary.html
package-tree.html
site/excalibur/altrmi/api/org/apache/excalibur/altrmi/common
hammant 2003/02/17 15:28:27
Removed: site/excalibur/altrmi/api/org/apache/excalibur/altrmi/server/impl/direct
DirectServer.html package-frame.html
package-summary.html package-tree.html
site/excalibur/altrmi/api/org/apache/ex
hammant 2003/02/17 15:27:53
Removed: site/excalibur/altrmi/api/org/apache/excalibur/altrmi/client/impl/socket
package-summary.html package-tree.html
site/excalibur/altrmi/api/org/apache/excalibur/altrmi/client/impl/stream
Cli
hammant 2003/02/17 15:27:31
Removed: site/excalibur/altrmi/api/org/apache/excalibur/altrmi/common
package-tree.html
site/excalibur/altrmi/api/org/apache/excalibur/altrmi/generator
AbstractProxyGenerator.html
hammant 2003/02/17 15:27:26
Removed: site/excalibur/altrmi/api/org/apache/excalibur/altrmi/client/impl
AbstractSameVmBindableHostContext.html
ClientSideClassFactory.html
ClientStreamReadWriter.html
hammant 2003/02/17 15:20:07
Removed: site/excalibur/altrmi/api/org/apache/excalibur/altrmi/server/impl/socket
PartialSocketObjectStreamServer.html
SocketStreamServerConnection.html
package-frame.html package-summary.
hammant 2003/02/17 15:20:01
Removed: site/excalibur/altrmi/api/org/apache/excalibur/altrmi/server
ServerMonitor.html
site/excalibur/altrmi/api/org/apache/excalibur/altrmi/server/impl
AbstractServer.html ConsoleServerMonitor.h
hammant 2003/02/17 15:19:52
Removed: site/excalibur/altrmi/api/org/apache/excalibur/altrmi/common
ExposedObjectProxy.html FacadeRefHolder.html
GarbageCollectionReply.html
GarbageCollectionRequest.html
hammant 2003/02/17 15:19:43
Removed:
site/excalibur/altrmi/api/org/apache/excalibur/altrmi/client/impl/multiple
AbstractMultipleInvocationHandler.html
RotatingMultipleHostContext.html
RotatingMultipleInvocationHandl
hammant 2003/02/17 15:19:32
Removed: site/excalibur/altrmi/api allclasses-frame.html
allclasses-noframe.html constant-values.html
deprecated-list.html help-doc.html index-all.html
index.html
site/exca
hammant 2003/02/17 14:38:53
Added: common/lib altrmi-blocks-0.9.1.jar
altrmi-client-impl-0.9.1.jar
altrmi-client-interfaces-0.9.1.jar
altrmi-common-0.9.1.jar altrmi-generator-0.9.1.jar
altrm
hammant 2003/02/17 14:37:58
Modified:demo build.xml
demo/src/java/org/apache/avalon/apps/demos/altrmihelloworldserver
AltrmiHelloWorldServerTester.java
demo/src/manifest AltrmiHelloWorldTest.mf
Log:
AltRMI upgraded to Incubato
Sam Ruby wrote:
OK, I updated the gump descriptors to handle the move of altrmi to
incubator. I would appreciate it if some people verified a few things
for me:
1) does the build of altrmi require phoenix?
IIRC it requires phoenix-client.jar and phoenix-metagenerate.jar, but
nothing else. Th
Hi gang,
how quickly can you build a minimal "avalon-compliant" container?
Answer: rather quickly.
I was working on some ideas for a "container verification test suite"
and I wanted to find the "smallest framework-supported feature set"
among containers from the component view. I started out u
hammant 2003/02/17 13:55:02
Removed: hsql build.xml default.properties
hsql/lib readme.txt
hsql/src/conf avalon-hsql-assembly.xml
avalon-hsql-config.xml avalon-hsql-environment.xml
hsql/src/java/org/apache/avalon/hs
ouch!
this slipped through I guess because just about everyone has a junit lib
inside their $ANT_HOME/lib. Which will probably fix things :D
Release has already been made and voted upon though, so can't change
that. No biggy I think. Feel free to patch cvs so it works in the next
point release
hammant 2003/02/17 13:36:10
Removed: altrmi/src/java/org/apache/excalibur/altrmi/remotable
RemotableExtensionManager.xconfig
RemotableExtensionManager.xinfo
Log:
AltRMI removed from excalibur
---
hammant 2003/02/17 13:34:36
Removed: altrmi/src/java/org/apache/excalibur/altrmi/server
MethodInvocationHandler.java
MethodInvocationMonitor.java
altrmi/src/java/org/apache/excalibur/altrmi/server/impl/http
hammant 2003/02/17 13:34:04
Removed: altrmi/src/conf MANIFEST-blocks.MF MANIFEST-client-impl.MF
MANIFEST-client-interfaces.MF MANIFEST-client.MF
MANIFEST-common.MF MANIFEST-generator.MF
MANIFEST-registry.MF MANIFEST-
hammant 2003/02/17 13:32:39
Removed: altrmi/src/java/org/apache/excalibur/altrmi/server/impl/piped
PipedCustomStreamServer.java
PipedObjectStreamServer.java
PipedStreamServerConnection.java
altrmi/src/
hammant 2003/02/17 13:32:34
Removed: altrmi/src/java/org/apache/excalibur/altrmi/client/impl
DumbClientMonitor.java DynamicClassFactory.java
DynamicInvoker.java DynamicStub.java
NeverConnectionPinger.java
hammant 2003/02/17 13:30:52
Removed: altrmi/src/test/org/apache/excalibur/altrmi/test
TestInterfaceImpl.java TestObject.java
TestProvider.java TestProviderImpl.java
altrmi/src/test/org/apache/excalibur/altrmi/test/async
hammant 2003/02/17 13:30:46
Removed: altrmi/src/java/org/apache/excalibur/altrmi/server
ProxyGenerationEnvironmentException.java
ProxyGenerator.java PublicationDescription.java
PublicationDescriptionItem.java
hammant 2003/02/17 13:30:39
Removed: altrmi/src/java/org/apache/excalibur/altrmi/client/impl/socket
SocketObjectStreamFactoryHelper.java
SocketObjectStreamHostContext.java
SocketObjectStreamInvocationHandler.java
hammant 2003/02/17 13:30:34
Removed: altrmi .cvsignore README.txt ant.properties.sample
base.xml build.xml default.properties memleak.xml
altrmi/lib bcel.jar commons-attributes-0.1.jar
commons-httpclient.jar commons-logging
hammant 2003/02/17 13:25:45
Modified:instrument-client altrmiproxies.xml build.xml
default.properties
instrument-client/src/java/org/apache/excalibur/instrument/client
InstrumentManagerConnection.java
hammant 2003/02/17 13:23:10
Modified:instrument-manager ant.properties.sample build.xml
default.properties
instrument-manager/src/java/org/apache/excalibur/instrument/manager/altrmi
InstrumentManagerAltrmiConnector.java
hammant 2003/02/17 13:19:12
avalon-excalibur/instrument-manager/lib - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
hammant 2003/02/17 13:19:00
avalon-excalibur/instrument-client/lib - New directory
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
hammant 2003/02/17 13:18:56
Modified:instrument-client .cvsignore
Log:
Updated by TortoiseCVS
Revision ChangesPath
1.4 +1 -0 avalon-excalibur/instrument-client/.cvsignore
Index: .cvsignore
=
Hi,
When i download LogKit-1.2 to a fresh directory and do a build it fails
because it can't find junit. It turns out it is looking for:
${tools.dir}/lib/junit-3.7.jar
where by default:
tools.dir = ../avalon/tools
The latest version of framework puts the jar in ../avalon/lib, and only
Leo Sutic wrote:
Committers:
...cast them votes, people.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
OK, I updated the gump descriptors to handle the move of altrmi to
incubator. I would appreciate it if some people verified a few things
for me:
1) does the build of altrmi require phoenix?
2) does the build of excalibur component require altrmi?
3) does altrmi work with the BSD licensed versio
Leo Sutic wrote:
> Committers:
> ...cast them votes, people.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
hi all,
Avalon has some code which imports jetty, and does an autodownload as
well. Jetty is
based on the OSI-approved artistic license:
http://jetty.mortbay.org/jetty/LICENSE.html
http://www.opensource.org/licenses/artistic-license.php
I think it is okay to
- distribute unmodfied artistic-lic
Leo Sutic wrote, On 17/02/2003 10.25:
Subject says it all.
(It is my understanding that a vote must be held on this - i.e.
he's not getting his commit privs restored automagically.)
Committers:
...cast them votes, people.
If he wants, +1
--
Nicola Ken Barozzi [EMAIL PROTECT
Paul Hammant wrote, On 17/02/2003 14.04:
Folks,
We've had a number of ideas on what to do with Sevak, given we have license issues. I think the
last idea was:
* Keep Sevak API at Apache
* Keep Catalina impl at Apache
* Move Jo! impl to Sourceforge
* Move Jetty impl to Sourceforge
+1
With
Ulrich Mayring wrote:
Paul Hammant wrote:
We have had instruction on 'import'. Jars here or there are irrelvant.
Hello Paul,
so what about Sun's Java License? We're doing many imports of JDK
public APIs :)
Seriously, I don't want to spoil the party, but it sounds braindead to
me that we
> To: Private PMC mailing list for Avalon <[EMAIL PROTECTED]>
>
> > +1 from me.
>
> +1
It seems this is in the public arena... so FWDed.
- Paul
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music
Ulrich,
> so what about Sun's Java License? We're doing many imports of JDK public
> APIs :)
I tend to agree. However, for teh record, APIs provided by the compilation
environment as a
default are typically exempt from the complex licensing situations. The GPL itself,
however
amazingly viral
On Monday, February 17, 2003, at 12:07 PM, Paul Hammant wrote:
I can understand Jo! since it is GPL.
You mean LGPL, which is very different to teh GPL, but similarly
forbidden for use (import) at
Apache.
right :)
But Jetty's license is based off
the artistic license. What's wrong with that?
ECM has become dependent on Fortress (AbstractContainer).
Is this intentional? I don't like it.
/LS
> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
> > Sevak API is fine. The impls, clearly, import other people's
> > codebases. "using public APIs" also
> > counts GPL. Here we are only talking about LGPL and a proprietary
> > credit-affording license for
> > Jetty.
>
> I can understand Jo! since it is GPL.
You mean LGPL, which is very d
On Monday, February 17, 2003, at 09:33 AM, Paul Hammant wrote:
Sevak API is fine. The impls, clearly, import other people's
codebases. "using public APIs" also
counts GPL. Here we are only talking about LGPL and a proprietary
credit-affording license for
Jetty.
I can understand Jo! since it
Leo Sutic wrote:
One question - are you using the lifecycle extensions in any way?
(If you don't know what that is, the answer is "no".)
From: Leo Sutic [mailto:[EMAIL PROTECTED]]
Everone is given a default lifecycle extension manager with no
extensions.
---
On Mon, Feb 17, 2003 at 10:25:17AM +0100, Leo Sutic wrote:
Subject says it all.
(It is my understanding that a vote must be held on this - i.e.
he's not getting his commit privs restored automagically.)
Committers:
...cast them votes, people.
+1
welcome back
-pete
--
Leo Sutic wrote:
http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/component/src/java/or
g/apache/avalon/excalibur/component/ExcaliburComponentManager.java?rev=1
.24&content-type=text/vnd.viewcvs-markup
Berin,
could you re-commit that file? I assume you have a working copy of it
with all the la
Leo Sutic wrote:
Berin,
this sounds like an issue with proxies. The StaticBucketMap should
be able to handle proxies, as long as the key being put == the
key being get.
I'm not that keen on the solution applied - it assumes that a
component's
toString() method returns the same value all the time
> From: J Aaron Farr [mailto:[EMAIL PROTECTED]]
>
> proxies to not equal() each other?
They don't. A Proxy isn't even equal() to itself many times.
Consider the case where an object O is wrapped by a proxy P.
P.equals (P) leads to O.equals (P), which in most cases is false
due to class mism
Leo Sutic wrote:
Subject says it all.
(It is my understanding that a vote must be held on this - i.e.
he's not getting his commit privs restored automagically.)
Committers:
...cast them votes, people.
Peter:
You haven't asked to have your privs restored, I'm merely
assuming that you want them
Paul Hammant wrote:
We have had instruction on 'import'. Jars here or there are irrelvant.
Hello Paul,
so what about Sun's Java License? We're doing many imports of JDK public
APIs :)
Seriously, I don't want to spoil the party, but it sounds braindead to
me that we have to move our own, se
On Mon, 2003-02-17 at 11:12, Leo Sutic wrote:
> Appears to be a bug in StaticBucketMap.
>
> Remove tests like this:
>
> if( n.key == null || ( n.key != null && n.key.equals( key ) ) )
>
> but get tests like this:
>
> if( n.key == key || ( n.key != null && n.key.equals( key ) ) )
>
On Mon, 2003-02-17 at 10:50, Leo Sutic wrote:
> One question - are you using the lifecycle extensions in any way?
>
> (If you don't know what that is, the answer is "no".)
>
No. Normal Lifecycles. No extensions.
> > From: Leo Sutic [mailto:[EMAIL PROTECTED]]
>
>
> -
I've found a bug in the StaticBucketMap class, the remove(Object)
method:
/**
* Implements {@link Map#remove(Object)}.
*/
public Object remove( Object key )
{
int hash = getHash( key );
synchronized( m_locks[ hash ] )
{
Node n = m_buckets
Leo Sutic wrote:
Subject says it all.
(It is my understanding that a vote must be held on this - i.e.
he's not getting his commit privs restored automagically.)
Committers:
...cast them votes, people.
+1
fede
Peter:
You haven't asked to have your privs restored, I'm merely
assuming that y
Appears to be a bug in StaticBucketMap.
Remove tests like this:
if( n.key == null || ( n.key != null && n.key.equals( key ) ) )
but get tests like this:
if( n.key == key || ( n.key != null && n.key.equals( key ) ) )
and of course the equals() comparison dies on proxies
One question - are you using the lifecycle extensions in any way?
(If you don't know what that is, the answer is "no".)
> From: Leo Sutic [mailto:[EMAIL PROTECTED]]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional co
> From: J Aaron Farr [mailto:[EMAIL PROTECTED]]
>
> One thing you might want to know is that I did try changing
> it from a StaticBucketMap to a normal Hashtable and still had
> the same issue. So apparently, the key that's being put is
> NOT the key that is being "get" even though the toSt
On Mon, 2003-02-17 at 04:31, Leo Sutic wrote:
> Berin,
>
> this sounds like an issue with proxies. The StaticBucketMap should
> be able to handle proxies, as long as the key being put == the
> key being get.
>
> I'm not that keen on the solution applied - it assumes that a
> component's
> toStrin
Ulrich,
> > With respect to the former, I think sevak api should go to say incubator. The
>catalina impl
> > should either go with it, or end up with Catalina (as a separate download?).
>
> I think the Sevak API should remain with Phoenix, because it is a
> central feature to an application
Paul:
My preference is to keep Servak here as I think there is still more
cooking to be done on this particular facility. What exactly are the
license issues that would need to deal with?
Cheers, Steve.
Paul Hammant wrote:
Folks,
We've had a number of ideas on what to do with Sevak, given
Paul Hammant wrote:
With respect to the former, I think sevak api should go to say incubator. The catalina impl
should either go with it, or end up with Catalina (as a separate download?).
I think the Sevak API should remain with Phoenix, because it is a
central feature to an application ser
Folks,
We've had a number of ideas on what to do with Sevak, given we have license issues. I
think the
last idea was:
* Keep Sevak API at Apache
* Keep Catalina impl at Apache
* Move Jo! impl to Sourceforge
* Move Jetty impl to Sourceforge
With respect to the former, I think sevak api should g
Folks,
The hsql component now sites in SourceForge CVS (renamed etc etc). It is identical
source to that
here.
We had three votes in favor of the move a week ago, I going to delete from our CVS
here tonight
unless there are objections. To recap, this is sensible - it can keep in step with
it
> I've upgraded jsch to 0.1.0 last week and they seem to have changed
> the jsch API in a backwards incompatible manner.
>
> jsch now also uses a BSDish license, but this is not related to the
> AltRMI build failure.
Well, I've dropped the JSCH stuff as it did not work anyway. The Stream-forward
Leo Sutic ::
-oOo-
That said, the proxying results in other problems. We moved to
the service.* classes due to the need of putting non-component
objects in the service manager, such as a CORBA ORB.
Since the ORB doesn't have an interface - i.e. there is no
ORB interface, o
mcconnell2003/02/17 04:15:33
Modified:merlin-bootstrap/src/java Merlin.java
Log:
Fixed bug relating to resolution of the configuration overides.
Revision ChangesPath
1.3 +8 -3 avalon-sandbox/merlin-bootstrap/src/java/Merlin.java
Index: Merlin.java
==
mcconnell2003/02/17 04:15:02
Modified:merlin/src/repository/demo config.xml
Log:
Updating message to make it clear where the message is comming from.
Revision ChangesPath
1.2 +1 -1 avalon-sandbox/merlin/src/repository/demo/config.xml
Index: config.xml
==
mcconnell2003/02/17 04:13:50
Modified:merlin/src/java/org/apache/avalon/merlin/kernel/impl
DefaultKernel.java
Log:
Normalized logging messages.
Revision ChangesPath
1.10 +7 -12
avalon-sandbox/merlin/src/java/org/apache/avalon/merlin/kerne
mcconnell2003/02/17 04:13:15
Modified:merlin/src/java/org/apache/avalon/merlin/container/impl
DefaultContainer.java
Log:
Identification and documentation of semantic conflict related to container
startup/suspend/resume/shutdown.
Revision ChangesPath
mcconnell2003/02/17 04:12:23
Modified:merlin/src/java/org/apache/avalon/merlin/block/impl
DefaultBlockLoader.java
Log:
Updated to better leverage the appliance manager in url establishment.
Revision ChangesPath
1.11 +23 -19
avalon-sandbox/
mcconnell2003/02/17 04:11:57
Modified:merlin/src/java/org/apache/avalon/merlin/block/impl
DefaultBlock.java
Log:
Updated to better leverage the appliance manager in url establishment.
Revision ChangesPath
1.7 +19 -11
avalon-sandbox/merlin
mcconnell2003/02/17 04:09:44
Modified:assembly/src/test/config block.xml
Log:
Corrected defitnition of complex component xinfo.
Revision ChangesPath
1.9 +6 -8 avalon-sandbox/assembly/src/test/config/block.xml
Index: block.xml
mcconnell2003/02/17 04:08:47
Modified:assembly/src/test/org/apache/avalon/playground
ComplexComponent.java SimpleComponent.java
assembly/src/test/org/apache/avalon/playground/basic
BasicComponent.java
Log:
Made logging me
mcconnell2003/02/17 04:07:44
Modified:assembly/src/java/org/apache/avalon/assembly/lifecycle/initialization
DefaultInitializationService.java
Log:
Minor enhancement to logging information.
Revision ChangesPath
1.6 +10 -6
avalon-sandbox/a
mcconnell2003/02/17 04:07:22
Modified:assembly/src/java/org/apache/avalon/assembly/lifecycle
DefaultAssemblyService.java
Log:
Minor enhancement to logging information.
Revision ChangesPath
1.8 +6 -6
avalon-sandbox/assembly/src/java/org/
mcconnell2003/02/17 04:06:34
Modified:assembly/src/java/org/apache/avalon/assembly/appliance
DefaultApplianceContext.java
Log:
Javadoc updates.
Revision ChangesPath
1.10 +3 -2
avalon-sandbox/assembly/src/java/org/apache/avalon/assembly/a
mcconnell2003/02/17 04:06:03
Modified:assembly/src/java/org/apache/avalon/assembly/appliance
DefaultAppliance.java
Log:
Updated appliance URL creation so that the base url comes from the appliance manager
instead of the appliance context.
Revision Chang
mcconnell2003/02/17 04:05:10
Modified:assembly/src/java/org/apache/avalon/assembly/appliance
DefaultApplianceRepository.java
Log:
Corrected a bug relating to the creation of appliance base URLs.
Revision ChangesPath
1.3 +4 -4
avalon-san
mcconnell2003/02/17 04:04:34
Modified:assembly/src/java/org/apache/avalon/assembly/engine
EngineClassLoader.java
Log:
Modified the newInstance utility operation to take the name of the partition that is
being created. This is used to provide the sub-partitio
On Mon, 17 Feb 2003, Leo Simons <[EMAIL PROTECTED]> wrote:
> Would be nice to get it running again in GUMP, too (believe this has
> to do with jsch
yes
> and licensing...).
no ;-)
I've upgraded jsch to 0.1.0 last week and they seem to have changed
the jsch API in a backwards incompatible manne
Hi Steve,
> >here is a patch for my proposed support for -linkoffline.
> Since I noticed lately a problem with attachments on this
> list, I post the contents here. My solution is to use
> linkoffline always and provide for both URLs the same value
> by default. This should work, but I cannot
Leo Sutic wrote:
Subject says it all.
(It is my understanding that a vote must be held on this - i.e.
he's not getting his commit privs restored automagically.)
Committers:
...cast them votes, people.
+1
Leif
-
To unsubscr
Paul Hammant wrote:
Folks,
AltRMI has landed at incubator.
cool! Go-go-gadget-altrmi!
I'll go thru the avalon* packages later and update references
(and import Jars), before deleting the excalibur CVS presence for this.
sounds like a plan. Would be nice to get it running again in GUMP, too
On Mon, Feb 17, 2003 at 10:25:17AM +0100, Leo Sutic wrote:
> Subject says it all.
>
> (It is my understanding that a vote must be held on this - i.e.
> he's not getting his commit privs restored automagically.)
>
> Committers:
> ...cast them votes, people.
+1
--Jeff
>
> /LS
Leo Sutic wrote:
From: Paul Hammant [mailto:[EMAIL PROTECTED]]
We're confusing CVS refactoring with real work again (no offence).
It would be more Maven friendly with separate project hierarchys.
Is a CVS module the smallest unit Maven can handle?
nope.
I don't
really understand how it bec
Leo Sutic wrote:
Committers:
...cast them votes, people.
+1
- Leo Simons
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Oops please ignore. I see there was a previous message about this.
> -Oorspronkelijk bericht-
> Van: Unico Hommes
> Verzonden: maandag 17 februari 2003 11:26
> Aan: Avalon-Dev (E-mail)
> Onderwerp: ECM broken
>
>
>
> Hi,
>
> ExcaliburComponentManager.java in CVS is not compiling.
>
1 - 100 of 113 matches
Mail list logo
