Re: [VOTE] fulcrum deprecation

Henning P. Schmiedehausen wrote: Dan Diephouse <[EMAIL PROTECTED]> writes: Avalon's configuration classes are the only way to go. They *are* firmly embedded into the API and work very well. Commons-configuration Borg way. As I expected. "Adapt or die". Avalon Configuration was born way

Re: Torque Security Service

O.K. I will check the LDAP service and see if it is working after this change. I will check it after the latest patch (TTWS34) that I sent is applied. -- Humberto --- > Hi, > > as you might have noticed from the CVS checkins today, I now finally > have all the infrastructure nee

Re: [GUMP] Build Failure - jakarta-turbine-2

Henning P. Schmiedehausen wrote: [EMAIL PROTECTED] writes: [javac] /home/rubys/jakarta/jakarta-turbine-2/src/java/org/apache/turbine/services/crypto/provider/JavaCrypt.java:59: package org.apache.commons.codec.base64 does not exist [javac] import org.apache.commons.codec.base64.Base64; [j

Re: turbine, fulcrum, avalon, ...

On Mon, Jan 13, 2003 at 02:36:54AM +0100, Martin Poeschl wrote: > keep in mind fulcrum is used by scarab .. so you should definitly wait > for a statement from John True. I remembered that, but then promptly forgot. So we'll see. All I really need is to run my app in a container with the securit

Re: turbine, fulcrum, avalon, ...

Stephen Haberman wrote: On Mon, Jan 13, 2003 at 02:20:57AM +0100, Martin Poeschl wrote: after reading todays mail here are my thoughts: Sounds good. I'll still refrain from a mass checkin of deprecation-less, suddenly-Avalonized Fulcrum code, but hopefully I will get there sometime soon

Re: [VOTE] fulcrum deprecation

On Mon, Jan 13, 2003 at 02:24:03AM +0100, Martin Poeschl wrote: > it would be nice to make torque an avalon component and extend the > ComponentService to enable the configuration and initialisation of > avalon components .. so we can kill stratum Agreed. Getting rid of the stratum jar from my pro

Re: turbine, fulcrum, avalon, ...

On Mon, Jan 13, 2003 at 02:20:57AM +0100, Martin Poeschl wrote: > after reading todays mail here are my thoughts: Sounds good. I'll still refrain from a mass checkin of deprecation-less, suddenly-Avalonized Fulcrum code, but hopefully I will get there sometime soon and we can start seeing Fulcrum

Re: [VOTE] fulcrum deprecation

Stephen Haberman wrote: On Mon, Jan 13, 2003 at 12:36:15AM +, Henning P. Schmiedehausen wrote: Avalon's configuration classes are the only way to go. They *are* firmly embedded into the API and work very well. Commons-configuration Borg way. As I expected. "Adapt or die". Al

turbine, fulcrum, avalon, ...

after reading todays mail here are my thoughts: o turbine 2.x doesn't use fulcrum - you can use some of the fulcrum services, but most of them don't work caused by the different RunData interfaces - i don't think turbine 2.x should use fulcrum as long as fulcrum is not stable o turbine-3 an

Re: [VOTE] fulcrum deprecation

On Mon, Jan 13, 2003 at 12:36:15AM +, Henning P. Schmiedehausen wrote: > >Avalon's configuration classes are the only way to go. They > >*are* firmly embedded into the API and work very well. > >Commons-configuration > > Borg way. As I expected. "Adapt or die". All development is adaptation

Re: [VOTE] fulcrum deprecation

On Mon, Jan 13, 2003 at 12:33:09AM +, Henning P. Schmiedehausen wrote: > Stephen Haberman <[EMAIL PROTECTED]> writes: > And we configure 50% of the application (Turbine) in a properties file > and 50% (the services) in a XML file with completely different > syntax? But the services themselves a

Re: [VOTE] fulcrum deprecation

On Mon, Jan 13, 2003 at 12:28:57AM +, Henning P. Schmiedehausen wrote: > As you may have noticed, this is still the Turbine development list. > Fulcrum are decoupled services to be used with Turbine (2 and 3). If > you change the code so that the current Turbine user base falls wayside, > there

Re: [VOTE] fulcrum deprecation

Dan Diephouse <[EMAIL PROTECTED]> writes: >Avalon's configuration classes are the only way to go. They *are* >firmly embedded into the API and work very well. Commons-configuration Borg way. As I expected. "Adapt or die". >This is what I thought also... By comitting to avalon, we are I wil

Re: [VOTE] fulcrum deprecation

Stephen Haberman <[EMAIL PROTECTED]> writes: >So a straight forward conversion without the baggage of backwards >compatibility/deprecation in _only_ the initialization/lookup part >of it (that is also well documented, e.g. search, ideally >automatically, your source and replace a with b and x with

Re: [VOTE] fulcrum deprecation

Stephen Haberman <[EMAIL PROTECTED]> writes: >On Sun, Jan 12, 2003 at 11:11:46AM +, Henning P. Schmiedehausen wrote: >> >> 1) Changes to XML-based configuration, but we can probably set up an >> >> adaptor that reads in the services.xxx.yyy style and converts it to >> >> an Avalon Configuratio

Torque Security Service

Hi, as you might have noticed from the CVS checkins today, I now finally have all the infrastructure needed for the Torque Security Service implementation in place. :-) (No, not actually, I need to deprecate a few more methods and replace by getName and getId methods). Please check, especially wi

cvs commit: jakarta-turbine-2/xdocs/services security-service.xml

henning 2003/01/12 16:13:22 Modified:conf TurbineResources.properties conf/master TurbineResources.master src/java/org/apache/turbine/services/security BaseSecurityService.java SecurityService.java src/java/org/apac

Re: [VOTE] fulcrum deprecation

Stephen Haberman wrote: On Sun, Jan 12, 2003 at 11:11:46AM +, Henning P. Schmiedehausen wrote: 1) Changes to XML-based configuration, but we can probably set up an adaptor that reads in the services.xxx.yyy style and converts it to an Avalon Configuration object. So this would be transparent

cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/services/security/db DBSecurityService.java DBUserManager.java

henning 2003/01/12 14:42:14 Modified:src/java/org/apache/turbine/services/security/db DBSecurityService.java DBUserManager.java Log: - Next round of style and doc fixes from our internal CVS - Add checks to addGroup/addRole/addPermission/createUser to

Re: fulcrum short-term

On Sun, Jan 12, 2003 at 11:13:03AM +, Henning P. Schmiedehausen wrote: > Stephen Haberman <[EMAIL PROTECTED]> writes: > > >Perhaps some of the Maven devs can chip in on how it has been > >working out for them? It is a lot more directories, but are the > >perceived benefits worth it? > > Try l

Re: [VOTE] fulcrum deprecation

On Sun, Jan 12, 2003 at 11:08:11AM +, Henning P. Schmiedehausen wrote: > But: To hell with deprecation. Interface compatibility, backward > compatibility and everything else. We will have a new code base that > shares some code with the current turbine. Then we can as well rename > it (just as

Re: [VOTE] fulcrum deprecation

On Sun, Jan 12, 2003 at 11:11:46AM +, Henning P. Schmiedehausen wrote: > >> 1) Changes to XML-based configuration, but we can probably set up an > >> adaptor that reads in the services.xxx.yyy style and converts it to > >> an Avalon Configuration object. So this would be transparent to > >> use

cvs commit: jakarta-turbine-fulcrum project.properties maven.xml

stephenh2003/01/12 11:43:48 Modified:.project.properties maven.xml Log: Fixed to re-add the functionality of only generating om classes after a schema change. Revision ChangesPath 1.9 +4 -2 jakarta-turbine-fulcrum/project.properties Index: project

cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/services/security/db DBUserManager.java

henning 2003/01/12 08:29:25 Modified:src/java/org/apache/turbine/services/security BaseSecurityService.java SecurityService.java TurbineSecurity.java src/java/org/apache/turbine/services/security/db DB

cvs commit: jakarta-turbine-2/xdocs/services index.xml

henning 2003/01/12 08:22:48 Modified:conf TurbineResources.properties conf/master TurbineResources.master xdocs/services index.xml Log: Added the crypto-service docs from Fulcrum. As we need the crypto service for the Security Service, we better do

cvs commit: jakarta-turbine-2/xdocs/services crypto-service.xml

henning 2003/01/12 08:22:07 Added: xdocs/services crypto-service.xml Log: Actually add the crypto docs... Revision ChangesPath 1.1 jakarta-turbine-2/xdocs/services/crypto-service.xml Index: crypto-service.xml =

cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/services/security/db DBUserManager.java

henning 2003/01/12 08:04:10 Modified:src/java/org/apache/turbine/services/security/db DBUserManager.java Log: More doc and style fixes from our internal CVS Revision ChangesPath 1.5 +66 -53 jakarta-turbine-2/src/java/org/apache/turbine/se

cvs commit: jakarta-turbine-2/xdocs/services security-service.xml

henning 2003/01/12 07:19:27 Modified:conf TurbineResources.properties conf/master TurbineResources.master xdocs/services security-service.xml Log: And that's exactly why I _hate_ working on two code bases... Revision ChangesPath 1.28

cvs commit: jakarta-turbine-2/conf/master TurbineResources.master

henning 2003/01/12 07:11:54 Modified:conf TurbineResources.properties conf/master TurbineResources.master Log: Sync up the Turbine.master and Turbine.properties, add the security service acl configuration property. Revision ChangesPath 1.27 +34 -

cvs commit: jakarta-turbine-2/xdocs/services index.xml security-service.xml

henning 2003/01/12 07:11:05 Modified:src/java/org/apache/turbine/services/security BaseSecurityService.java SecurityService.java src/java/org/apache/turbine/services/security/db DBSecurityService.java src/java/

cvs commit: jakarta-turbine-2/xdocs features.xml getting-started.xml project-map.xml

henning 2003/01/12 07:03:05 Modified:xdocsfeatures.xml getting-started.xml project-map.xml Log: Remove some old references to Logging and Resources Service Revision ChangesPath 1.4 +5 -4 jakarta-turbine-2/xdocs/features.xml Index: features.xml ==

cvs commit: jakarta-turbine-2/xdocs/services index.xml logging-service.xml resources-service.xml

henning 2003/01/12 06:54:56 Modified:xdocs/services index.xml logging-service.xml resources-service.xml Log: Updated the docs concerning Logging and Resources Service to resemble something like the current Turbine code. Revision ChangesPath 1.6

cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/services/security SecurityService.java

henning 2003/01/12 05:58:53 Modified:src/java/org/apache/turbine/services/security SecurityService.java Log: Create the Name of the USER_MANAGER_DEFAULT directly from the class, making it less fragile Revision ChangesPath 1.7 +3 -2 ja

cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/services/security/db DBSecurityService.java

henning 2003/01/12 05:52:27 Modified:src/java/org/apache/turbine/services/security BaseSecurityService.java src/java/org/apache/turbine/services/security/db DBSecurityService.java Log: Convert the Security Service to use

cvs commit: jakarta-turbine-2/src/test/org/apache/turbine/services/security - New directory

henning 2003/01/12 05:39:01 jakarta-turbine-2/src/test/org/apache/turbine/services/security - New directory -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: [VOTE] fulcrum deprecation

Henning P. Schmiedehausen wrote: Nicola Ken Barozzi <[EMAIL PROTECTED]> writes: If you want XML based configuration, you should add an adaptor to the commons-configuration and simply use it. That way, people who want to keep their properties files won't get fucked up. Or send us a patch so

Re: [VOTE] fulcrum deprecation

Nicola Ken Barozzi <[EMAIL PROTECTED]> writes: >> If you want XML based configuration, you should add an adaptor to the >> commons-configuration and simply use it. That way, people who want to >> keep their properties files won't get fucked up. >Or send us a patch so that Avalon can use property

cvs commit: jakarta-turbine-2/src/java/org/apache/turbine/util/security AccessControlList.java DataBackendException.java EntityExistsException.java GroupSet.java PasswordMismatchException.java PermissionSet.java RoleSet.java TurbineSecurityException.java UnknownEntityException.java

henning 2003/01/12 04:33:12 Modified:src/java/org/apache/turbine/om/security Group.java Permission.java Role.java SecurityEntity.java User.java src/java/org/apache/turbine/services/security BaseSecurit

Re: [VOTE] fulcrum deprecation

Henning P. Schmiedehausen wrote: Dan Diephouse <[EMAIL PROTECTED]> writes: 1) Changes to XML-based configuration, but we can probably set up an adaptor that reads in the services.xxx.yyy style and converts it to an Avalon Configuration object. So this would be transparent to users, e.g. Turbin

Re: [GUMP] Build Failure - jakarta-turbine-2

[EMAIL PROTECTED] writes: >[javac] >/home/rubys/jakarta/jakarta-turbine-2/src/java/org/apache/turbine/services/crypto/provider/JavaCrypt.java:59: > package org.apache.commons.codec.base64 does not exist >[javac] import org.apache.commons.codec.base64.Base64; >[javac]

cvs commit: jakarta-turbine-2 gump.xml

henning 2003/01/12 03:14:56 Modified:.gump.xml Log: Make gump happy again by pulling commons-codec in. Revision ChangesPath 1.2 +1 -0 jakarta-turbine-2/gump.xml Index: gump.xml ===

Re: fulcrum short-term

Stephen Haberman <[EMAIL PROTECTED]> writes: >Perhaps some of the Maven devs can chip in on how it has been >working out for them? It is a lot more directories, but are the >perceived benefits worth it? Try looking for a certain property on http://jakarta.apache.org/turbine/maven Then you would

Re: [VOTE] fulcrum deprecation

Dan Diephouse <[EMAIL PROTECTED]> writes: >> 1) Changes to XML-based configuration, but we can probably set up an >> adaptor that reads in the services.xxx.yyy style and converts it to >> an Avalon Configuration object. So this would be transparent to >> users, e.g. TurbineResources.properties wil

Re: [VOTE] fulcrum deprecation

Stephen Haberman <[EMAIL PROTECTED]> writes: >So besides forgetting my initial +1, there is another alternative >where we keep the TurbineXxx classes, and the Service interface, but >still (preferably) kill BaseService/ServiceBroker/BaseServiceBroker >and instead add a AvalonToServiceAdaptor class

[GUMP] Build Failure - jakarta-turbine-stratum-full

This email is autogenerated from the output from: Buildfile: build-gump.xml jar: [javac] Compiling 9 sourc

[GUMP] Build Failure - jakarta-turbine-tdk

This email is autogenerated from the output from: Buildfile: build.xml BUILD FAILED Target `jar' does not exist in this

[GUMP] Build Failure - jakarta-turbine-fulcrum

This email is autogenerated from the output from: Build results exceed maximum length. Please see URL above for deta

[GUMP] Build Failure - jakarta-turbine-2

This email is autogenerated from the output from: Buildfile: build-gump.xml jar: [mkdir] Created dir: /home/rubys/jak