You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by pr...@apache.org on 2002/07/12 22:11:34 UTC
cvs commit: jakarta-avalon/src/java/org/apache/avalon/framework/configuration ConfigurationUtil.java
proyal 2002/07/12 13:11:34
Added: src/java/org/apache/avalon/framework/configuration
ConfigurationUtil.java
Log:
* Moved from org.apache.excalibur.configuration.ConfigurationUtil (inside merlin)
* Added branch() per thread http://marc.theaimsgroup.com/?t=102347724100002&r=1&w=2
Revision Changes Path
1.1 jakarta-avalon/src/java/org/apache/avalon/framework/configuration/ConfigurationUtil.java
Index: ConfigurationUtil.java
===================================================================
/*
* Copyright (C) The Apache Software Foundation. All rights reserved.
*
* This software is published under the terms of the Apache Software License
* version 1.1, a copy of which has been included with this distribution in
* the LICENSE.TXT file.
*
* Original contribution by OSM SARL, http://www.osm.net
*/
package org.apache.avalon.framework.configuration;
import java.util.Vector;
import org.apache.avalon.framework.CascadingRuntimeException;
/**
* General utility supporting static operations for generating string
* representations of a configuration suitable for debugging.
* @author Stephen McConnell <mc...@osm.net>
*/
public class ConfigurationUtil
{
private static final Configuration[] EMPTY_CONFS = new Configuration[0];
/**
* Returns a simple string representation of the the supplied configuration.
* @param config a configuration
* @return a simplified text representation of a configuration suitable
* for debugging
*/
public static String list( Configuration config )
{
final StringBuffer buffer = new StringBuffer();
list( buffer, " ", config );
buffer.append( "\n" );
return buffer.toString();
}
private static void list( StringBuffer buffer, String lead, Configuration config )
{
buffer.append( "\n" + lead + "<" + config.getName() );
String[] names = config.getAttributeNames();
if( names.length > 0 )
{
for( int i = 0; i < names.length; i++ )
{
buffer.append( " "
+ names[i] + "=\""
+ config.getAttribute( names[i], "???" ) + "\"" );
}
}
Configuration[] children = config.getChildren();
if( children.length > 0 )
{
buffer.append( ">" );
for( int j = 0; j < children.length; j++ )
{
list( buffer, lead + " ", children[j] );
}
buffer.append( "\n" + lead + "</" + config.getName() + ">" );
}
else
{
if( config.getValue( null ) != null )
{
buffer.append( ">...</" + config.getName() + ">" );
}
else
{
buffer.append( "/>" );
}
}
}
/**
* Return all occurance of a configuration child containing the supplied attribute name.
* @param config the configuration
* @param element the name of child elements to select from the configuration
* @param attribute the attribute name to filter
* @param value the attribute value to match (null will match any attribute value)
* @return an array of configuration instances matching the query
*/
public static Configuration[] match( Configuration config, String element, String attribute )
{
return match( config, element, attribute, null );
}
/**
* Return occurance of a configuration child containing the supplied attribute name and value.
* @param config the configuration
* @param element the name of child elements to select from the configuration
* @param attribute the attribute name to filter
* @param value the attribute value to match (null will match any attribute value)
* @return an array of configuration instances matching the query
*/
public static Configuration[] match(
final Configuration config, final String element, final String attribute, final String value )
{
Vector vector = new Vector();
Configuration[] children = config.getChildren( element );
for( int i = 0; i < children.length; i++ )
{
String v = children[i].getAttribute( attribute, null );
if( v != null )
{
if( ( value == null ) || v.equals( value ) )
{
// it's a match
vector.add( children[i] );
}
}
}
return ( Configuration[] ) vector.toArray( EMPTY_CONFS );
}
/**
* Return the first occurance of a configuration child containing the supplied attribute name and value
* or create a new empty configuration if no match found.
* @param config the configuration
* @param element the name of child elements to select from the configuration
* @param attribute the attribute name to filter
* @param value the attribute value to match (null will match any attribute value)
* @return a configuration instances matching the query or empty configuration
*/
public static Configuration matchFirstOccurance(
Configuration config, String element, String attribute, String value )
{
try
{
return matchFirstOccurance( config, element, attribute, value, true );
}
catch( ConfigurationException e )
{
// will not happen
throw new CascadingRuntimeException( "Unexpected exception condition.", e );
}
}
/**
* Return the first occurance of a configuration child containing the supplied attribute
* name and value. If the supplied creation policy if TRUE and no match is found, an
* empty configuration instance is returned, otherwise a null will returned.
* @param config the configuration
* @param element the name of child elements to select from the configuration
* @param attribute the attribute name to filter
* @param value the attribute value to match (null will match any attribute value)
* @param create the creation policy if no match
* @return a configuration instances matching the query
*/
public static Configuration matchFirstOccurance(
Configuration config, String element, String attribute, String value, boolean create )
throws ConfigurationException
{
Configuration[] children = config.getChildren( element );
for( int i = 0; i < children.length; i++ )
{
String v = children[i].getAttribute( attribute, null );
if( v != null )
{
if( ( value == null ) || v.equals( value ) )
{
// it's a match
return children[i];
}
}
}
if( create )
return new DefaultConfiguration( element, null );
return null;
}
public static Configuration branch( final Configuration config, final String name )
{
final DefaultConfiguration c = createNew( config, name );
final String[] attributes = config.getAttributeNames();
final Configuration[] kids = config.getChildren();
c.setValue( config.getValue( null ) );
for( int i = 0; i < attributes.length; i++ )
{
try
{
c.setAttribute( attributes[i], config.getAttribute( attributes[i] ) );
}
catch( ConfigurationException e )
{
throw new CascadingRuntimeException( "Configuration is missing advertised attribute", e );
}
}
for( int i = 0; i < kids.length; i++ )
{
c.addChild( kids[i] );
}
c.makeReadOnly();
return c;
}
private static DefaultConfiguration createNew( final Configuration config, final String name )
{
if( config instanceof AbstractConfiguration )
{
try
{
return new DefaultConfiguration( name,
config.getLocation(),
config.getNamespace(),
( ( AbstractConfiguration ) config ).getPrefix() );
}
catch( ConfigurationException e )
{
//Ignore. If there is an error in the namespaces, we won't copy namespaces stuff
}
}
return new DefaultConfiguration( name, config.getLocation() );
}
}
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:
jakarta-avalon/src/java/org/apache/avalon/framework/configuration
ConfigurationUtil.java
Posted by Peter Donald <pe...@apache.org>.
At 06:35 PM 7/12/2002 -0400, you wrote:
> > -1 on addition to framework CVS. Too much clutter and not consistent with
> > the rest of packages. Move to excalibur.util package if it is really
> > desired.
>
>How about the creation of an excalibur.configuration ?
If there is more than 2 classes maybe but until then
>Or would you prefer excalibur.util.configuration ?
+1
>ps. i have block configuration validation working, expect a commit soon,
>whoho!
woohoo!
>--
>peter royal -> proyal@apache.org
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon/src/java/org/apache/avalon/framework/configuration ConfigurationUtil.java
Posted by Peter Royal <pr...@apache.org>.
On Saturday 13 July 2002 11:41 am, Stephen McConnell wrote:
> >I'll do that. It'll be a good chance to learn some CVS skills on reverting
> > to revive those classes.
>
> Let me know what its done and I'll update the dependecies in Merlin 1,
> Merlin 2 and content over on Avalon Apps.
Done. I updated Merlin 1 (exalibur/merlin). If you could handle the rest
that'd be superb
> >Configuration information. A phoenix block can declare a schema type
> >(relax-ng, xml schema, etc) and phoenix will look for a file named
> ><class>-schema.xml next to the class file (just like xinfo).
> >
> >Then when phoenix is starting up an application, the configuration
> > information for a block is verified with the schema before loading it.
>
> Cool - I have a simpler need for such a thing under Merlin 2.
> Will this be going under the configuration package or Phoenix ?
I've developed it inside of the phoenix hierarchy, but there are no explicit
dependencies upon phoenix.
I have no problem with moving it over to the excalibur configuration package,
but I'm going to finish up the rest of the new work before doing so (see
http://www.mail-archive.com/avalon-phoenix-dev%40jakarta.apache.org/msg00197.html
for my plans).
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to
using the jakarta-commons-sandbox version
Posted by Peter Donald <pe...@apache.org>.
At 08:27 PM 7/15/2002 +0200, you wrote:
> > I would like to keep the CVS history for the tar and bzip projects
>>(mainly as it will help when/if I try to migrate it back into ant). So
>>this will need filesystem hackery to get going.
>
>Ok.
I have done bzip. I think I removed all the avalon bits from it though I
suspect not... Anyways will do tar sometime later this week.
Not subscribed to the list so give me any heads up before you do any
massive changes and if you need me to come back to do a drive by vote ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to
using the jakarta-commons-sandbox version
Posted by Peter Donald <pe...@apache.org>.
At 08:27 PM 7/15/2002 +0200, you wrote:
>>Long story short - it makes life so much easier if they are separated
>>because I am working on automated dependency tracking and linking for myrmidon.
>
>Oh, cool.
>Something like Maven's Reactor?
Not sure. Basically every jar is capable of declaring extensions it
supports and extensions it requires. The extensions are stored in manifest.
Currently the jars are loaded from directories but they could be loaded
from elsewhere.
>>BTW I believe Stefan Bodewig was lurking (or active?) on commons and is
>>also an ant developer. If you could recruit him to help out it would make
>>it much easier to get it migrated back into core ant.
>
>Active.
>I already asked if he would like to use the commons packages with Ant,
>*without* moving code back to Ant, making Ant use the commons releases.
>
>He's +1 for it conceptually, but there is always the Gump
>Ant-is-Ant-builds-Ant-don't-wanna-dependency problem.
>If you could sort this out with Stefan it would be great.
kool. I'll let you handle it as anything with my name on it he is most
likely to block out of hand ;)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to using
the jakarta-commons-sandbox version
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Mon, 15 Jul 2002 09:22, Nicola Ken Barozzi wrote:
>
>>>not really. They are still versioned and distributed as a package (even
>>>if in multiple jars). Myrmidon is automatically tracking dependencies and
>>>as soon as they start to get chunk and contain unrelated bits things
>>>start to fall down.
>>
>>Sorry, Peter, but I don't understand what you're saying.
>
> Long story short - it makes life so much easier if they are separated because
> I am working on automated dependency tracking and linking for myrmidon.
Oh, cool.
Something like Maven's Reactor?
>>I'll see if over at commons they are ok at reseparating them even if
>>under the same "project".
>
>
> kool. If you want I can actually do the required work (assuming it is still in
> sandbox).
Sure. I asked a vote for promotion but it was -1 till FileUtil(s) get
merged, deprecated methods get thrown out and some other minor things.
> I would like to keep the CVS history for the tar and bzip projects
> (mainly as it will help when/if I try to migrate it back into ant). So this
> will need filesystem hackery to get going.
Ok.
> So if you dont mind I will go in and chuck it in sandbox as separate projects
> with all their CVS history in tact.
I never mind when someone does something for me ;-)
Sometimes people get upset when someone does something they should do
instead, I find it kinda amusing at times.
> When/if they get promoted to commons proper I would like to still have access
> to the bzip package (mainly as it still needs a bit of tweaking to get
> resource usage down).
Of course.
> BTW I believe Stefan Bodewig was lurking (or active?) on commons and is also
> an ant developer. If you could recruit him to help out it would make it much
> easier to get it migrated back into core ant.
Active.
I already asked if he would like to use the commons packages with Ant,
*without* moving code back to Ant, making Ant use the commons releases.
He's +1 for it conceptually, but there is always the Gump
Ant-is-Ant-builds-Ant-don't-wanna-dependency problem.
If you could sort this out with Stefan it would be great.
> So just give me the nod and I will start doing filesystem hackery to get it
> all good.
*nod*
BTW, I put the unit tests in the same packages for consistency with
existing tests and to enable whitebox testing.
Do as you prefer, just telling you why you'll find them there.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to using the jakarta-commons-sandbox version
Posted by Peter Donald <pe...@apache.org>.
On Mon, 15 Jul 2002 09:22, Nicola Ken Barozzi wrote:
> > not really. They are still versioned and distributed as a package (even
> > if in multiple jars). Myrmidon is automatically tracking dependencies and
> > as soon as they start to get chunk and contain unrelated bits things
> > start to fall down.
>
> Sorry, Peter, but I don't understand what you're saying.
Long story short - it makes life so much easier if they are separated because
I am working on automated dependency tracking and linking for myrmidon.
> I'll see if over at commons they are ok at reseparating them even if
> under the same "project".
kool. If you want I can actually do the required work (assuming it is still in
sandbox). I would like to keep the CVS history for the tar and bzip projects
(mainly as it will help when/if I try to migrate it back into ant). So this
will need filesystem hackery to get going.
So if you dont mind I will go in and chuck it in sandbox as separate projects
with all their CVS history in tact.
When/if they get promoted to commons proper I would like to still have access
to the bzip package (mainly as it still needs a bit of tweaking to get
resource usage down).
BTW I believe Stefan Bodewig was lurking (or active?) on commons and is also
an ant developer. If you could recruit him to help out it would make it much
easier to get it migrated back into core ant.
So just give me the nod and I will start doing filesystem hackery to get it
all good.
--
Cheers,
Peter Donald
---------------------------------------------------
"Wise men don't need advice. Fools don't take it."
-Benjamin Franklin
---------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to using
the jakarta-commons-sandbox version
Posted by Henri Yandell <ba...@generationjava.com>.
> >(what the hell has unix zip support got to do with bzip or utilities to
> > copy streams?)
>
> Files?
java.io ?
Then again, zips are in java.util.zip.
>
> > BTW there seems to be a lot of accumulated crapola in the package. FileUtil vs
> > FIleUtils and very little rhyme or reason for it all. That going to disapear?
>
> It's gonna get fixed, yes.
> Seems like I fired too early ;-)
Commons.IO has not really been worked on since various bits were merged,
at a guess the state was that of the merged components living in the same
project. The merger was February or so. Getting Lang promoted and released
had been a higher priority.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to using
the jakarta-commons-sandbox version
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Sun, 14 Jul 2002 19:33, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote:
>>
>>>At 05:51 PM 7/13/2002 +0200, you wrote:
>>>
>>>>I have finished the move of the io, bzip, zip and tar packages
>>>>in excalibur in the Jakarta Commons Sandbox, project io.
>>>>
>>>>excalibur/io -> org.apache.commons.io.*;
>>>>excalibur/bzip2 -> org.apache.commons.io.compress.bzip2.*;
>>>>excalibur/zip -> org.apache.commons.io.compress.zip.*;
>>>>excalibur/tar -> org.apache.commons.io.compress.tar.*;
>>>
>>>Grumble grumble.
>>>
>>>You merged all the packages together making it difficult for me to use.
>>>They were separated out for damn good reason.
>>
>>If I make the jar target output one jar per package, would that be ok?
>
>
> not really. They are still versioned and distributed as a package (even if in
> multiple jars). Myrmidon is automatically tracking dependencies and as soon
> as they start to get chunk and contain unrelated bits things start to fall
> down.
Sorry, Peter, but I don't understand what you're saying.
I'll see if over at commons they are ok at reseparating them even if
under the same "project".
>(what the hell has unix zip support got to do with bzip or utilities to
> copy streams?)
Files?
> BTW there seems to be a lot of accumulated crapola in the package. FileUtil vs
> FIleUtils and very little rhyme or reason for it all. That going to disapear?
It's gonna get fixed, yes.
Seems like I fired too early ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to using the jakarta-commons-sandbox version
Posted by Peter Donald <pe...@apache.org>.
On Sun, 14 Jul 2002 19:33, Nicola Ken Barozzi wrote:
> Peter Donald wrote:
> > At 05:51 PM 7/13/2002 +0200, you wrote:
> >> I have finished the move of the io, bzip, zip and tar packages
> >> in excalibur in the Jakarta Commons Sandbox, project io.
> >>
> >> excalibur/io -> org.apache.commons.io.*;
> >> excalibur/bzip2 -> org.apache.commons.io.compress.bzip2.*;
> >> excalibur/zip -> org.apache.commons.io.compress.zip.*;
> >> excalibur/tar -> org.apache.commons.io.compress.tar.*;
> >
> > Grumble grumble.
> >
> > You merged all the packages together making it difficult for me to use.
> > They were separated out for damn good reason.
>
> If I make the jar target output one jar per package, would that be ok?
not really. They are still versioned and distributed as a package (even if in
multiple jars). Myrmidon is automatically tracking dependencies and as soon
as they start to get chunk and contain unrelated bits things start to fall
down. (what the hell has unix zip support got to do with bzip or utilities to
copy streams?)
BTW there seems to be a lot of accumulated crapola in the package. FileUtil vs
FIleUtils and very little rhyme or reason for it all. That going to disapear?
--
Cheers,
Peter Donald
*------------------------------------------------*
| The student who is never required to do what |
| he cannot do never does what he can do. |
| - John Stuart Mill |
*------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar...
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Leo Simons wrote:
>>Sure.
>>I'm getting ready for the release on Commons, so I guess it'll be:
>>1. release on commons
>
> 1.5 get current users of these packages to verify the commons ones still
> do what they need them to do; allow some time for this
Ok
>>2. move over here to the new version
>
>
> 2.5. leave packages around here for quite some time to allow people that
> use them to move to the commons ones
Is it ok if I just leave the jars here?
>>3. nuke the packages here
>
>
> and then I'm +1
>
> IOW, make sure there's a slow timetable.
slow but steady ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar...
Posted by Leo Simons <le...@apache.org>.
> Sure.
> I'm getting ready for the release on Commons, so I guess it'll be:
> 1. release on commons
1.5 get current users of these packages to verify the commons ones still
do what they need them to do; allow some time for this
> 2. move over here to the new version
2.5. leave packages around here for quite some time to allow people that
use them to move to the commons ones
> 3. nuke the packages here
and then I'm +1
IOW, make sure there's a slow timetable.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to using
the jakarta-commons-sandbox version
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> At 05:51 PM 7/13/2002 +0200, you wrote:
>
>> I have finished the move of the io, bzip, zip and tar packages
>> in excalibur in the Jakarta Commons Sandbox, project io.
>>
>> excalibur/io -> org.apache.commons.io.*;
>> excalibur/bzip2 -> org.apache.commons.io.compress.bzip2.*;
>> excalibur/zip -> org.apache.commons.io.compress.zip.*;
>> excalibur/tar -> org.apache.commons.io.compress.tar.*;
>
>
> Grumble grumble.
>
> You merged all the packages together making it difficult for me to use.
> They were separated out for damn good reason.
If I make the jar target output one jar per package, would that be ok?
>> Therefore I propose that we remove the above packages from excalibur
>> and start using the commons version.
>
> Leave the ones in excalibur until everyone moves across.
Sure.
I'm getting ready for the release on Commons, so I guess it'll be:
1. release on commons
2. move over here to the new version
3. nuke the packages here
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to
using the jakarta-commons-sandbox version
Posted by Peter Donald <pe...@apache.org>.
At 05:51 PM 7/13/2002 +0200, you wrote:
>I have finished the move of the io, bzip, zip and tar packages
>in excalibur in the Jakarta Commons Sandbox, project io.
>
>excalibur/io -> org.apache.commons.io.*;
>excalibur/bzip2 -> org.apache.commons.io.compress.bzip2.*;
>excalibur/zip -> org.apache.commons.io.compress.zip.*;
>excalibur/tar -> org.apache.commons.io.compress.tar.*;
Grumble grumble.
You merged all the packages together making it difficult for me to use.
They were separated out for damn good reason.
>Therefore I propose that we remove the above packages from excalibur and
>start using the commons version.
Leave the ones in excalibur until everyone moves across.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Remove excalibur io, bzip2, zip, tar and switch to using the jakarta-commons-sandbox version
Posted by Berin Loritsch <bl...@apache.org>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> I have finished the move of the io, bzip, zip and tar
> packages in excalibur in the Jakarta Commons Sandbox, project io.
>
> excalibur/io -> org.apache.commons.io.*;
> excalibur/bzip2 -> org.apache.commons.io.compress.bzip2.*;
> excalibur/zip -> org.apache.commons.io.compress.zip.*;
> excalibur/tar -> org.apache.commons.io.compress.tar.*;
>
> The package compiles, the tests run without failing, and the
> move seems
> globally ok.
>
> Therefore I propose that we remove the above packages from
> excalibur and
> start using the commons version.
>
> +1
Better, provide compatibility layer, with everything deprecated.
In most cases it can be done by extending the real classes with
the ones we have--and making sure the deprecation flags are working.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Remove excalibur io, bzip2, zip, tar and switch to using the
jakarta-commons-sandbox version
Posted by Nicola Ken Barozzi <ni...@apache.org>.
I have finished the move of the io, bzip, zip and tar packages
in excalibur in the Jakarta Commons Sandbox, project io.
excalibur/io -> org.apache.commons.io.*;
excalibur/bzip2 -> org.apache.commons.io.compress.bzip2.*;
excalibur/zip -> org.apache.commons.io.compress.zip.*;
excalibur/tar -> org.apache.commons.io.compress.tar.*;
The package compiles, the tests run without failing, and the move seems
globally ok.
Therefore I propose that we remove the above packages from excalibur and
start using the commons version.
+1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon/src/java/org/apache/avalon/framework/configuration
ConfigurationUtil.java
Posted by Stephen McConnell <mc...@osm.net>.
Peter Royal wrote:
>On Friday 12 July 2002 08:51 pm, Stephen McConnell wrote:
>
>
>>>How about the creation of an excalibur.configuration ?
>>>
>>>
>>+1
>>That's where is was up until a few weeks ago. I would prefer to see
>>this as small package containing just the configuration utilities
>>(CascadingConfiguration, ConfigurationUtil, and other specifically
>>related to configuration management). Putting it back under
>>excalibur/configuration also maintains consistentency with respect to
>>the other users of the package outside of Avalon.
>>
>>
>
>I'll do that. It'll be a good chance to learn some CVS skills on reverting to
>revive those classes.
>
>
Let me know what its done and I'll update the dependecies in Merlin 1,
Merlin 2 and content over on Avalon Apps.
>
>
>>>ps. i have block configuration validation working, expect a commit soon,
>>>whoho!
>>>
>>>
>>What exactly are you validating here ?
>>
>>
>
>Configuration information. A phoenix block can declare a schema type
>(relax-ng, xml schema, etc) and phoenix will look for a file named
><class>-schema.xml next to the class file (just like xinfo).
>
>Then when phoenix is starting up an application, the configuration information
>for a block is verified with the schema before loading it.
>-pete
>
>
Cool - I have a simpler need for such a thing under Merlin 2.
Will this be going under the configuration package or Phoenix ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon/src/java/org/apache/avalon/framework/configuration ConfigurationUtil.java
Posted by Peter Royal <pr...@apache.org>.
On Friday 12 July 2002 08:51 pm, Stephen McConnell wrote:
> >How about the creation of an excalibur.configuration ?
>
> +1
> That's where is was up until a few weeks ago. I would prefer to see
> this as small package containing just the configuration utilities
> (CascadingConfiguration, ConfigurationUtil, and other specifically
> related to configuration management). Putting it back under
> excalibur/configuration also maintains consistentency with respect to
> the other users of the package outside of Avalon.
I'll do that. It'll be a good chance to learn some CVS skills on reverting to
revive those classes.
> >ps. i have block configuration validation working, expect a commit soon,
> >whoho!
>
> What exactly are you validating here ?
Configuration information. A phoenix block can declare a schema type
(relax-ng, xml schema, etc) and phoenix will look for a file named
<class>-schema.xml next to the class file (just like xinfo).
Then when phoenix is starting up an application, the configuration information
for a block is verified with the schema before loading it.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon/src/java/org/apache/avalon/framework/configuration
ConfigurationUtil.java
Posted by Stephen McConnell <mc...@osm.net>.
Peter Royal wrote:
>On Friday 12 July 2002 05:50 pm, Peter Donald wrote:
>
>
>>At 08:11 PM 7/12/2002 +0000, you wrote:
>>
>>
>>>proyal 2002/07/12 13:11:34
>>>
>>> Added: src/java/org/apache/avalon/framework/configuration
>>> ConfigurationUtil.java
>>> Log:
>>> * Moved from org.apache.excalibur.configuration.ConfigurationUtil
>>>(inside merlin)
>>> * Added branch() per thread
>>>http://marc.theaimsgroup.com/?t=102347724100002&r=1&w=2
>>>
>>>
>>-1 on addition to framework CVS. Too much clutter and not consistent with
>>the rest of packages. Move to excalibur.util package if it is really
>>desired.
>>
>>
>
>How about the creation of an excalibur.configuration ?
>
+1
That's where is was up until a few weeks ago. I would prefer to see
this as small package containing just the configuration utilities
(CascadingConfiguration, ConfigurationUtil, and other specifically
related to configuration management). Putting it back under
excalibur/configuration also maintains consistentency with respect to
the other users of the package outside of Avalon.
>Or would you prefer excalibur.util.configuration ?
>
-1
Clutters up dependecies with extra stuff.
>
>I'm going to be moving CascadingConfiguration to be visible outside of merlin
>soon too, so it and ConfigurationUtil should live together.
>
+1
>
>I'm fine for either approach, but it'll be sat before i get a chance to do so.
>-pete
>
>ps. i have block configuration validation working, expect a commit soon,
>whoho!
>
>
What exactly are you validating here ?
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit: jakarta-avalon/src/java/org/apache/avalon/framework/configuration ConfigurationUtil.java
Posted by Peter Royal <pr...@apache.org>.
On Friday 12 July 2002 05:50 pm, Peter Donald wrote:
> At 08:11 PM 7/12/2002 +0000, you wrote:
> >proyal 2002/07/12 13:11:34
> >
> > Added: src/java/org/apache/avalon/framework/configuration
> > ConfigurationUtil.java
> > Log:
> > * Moved from org.apache.excalibur.configuration.ConfigurationUtil
> > (inside merlin)
> > * Added branch() per thread
> > http://marc.theaimsgroup.com/?t=102347724100002&r=1&w=2
>
> -1 on addition to framework CVS. Too much clutter and not consistent with
> the rest of packages. Move to excalibur.util package if it is really
> desired.
How about the creation of an excalibur.configuration ?
Or would you prefer excalibur.util.configuration ?
I'm going to be moving CascadingConfiguration to be visible outside of merlin
soon too, so it and ConfigurationUtil should live together.
I'm fine for either approach, but it'll be sat before i get a chance to do so.
-pete
ps. i have block configuration validation working, expect a commit soon,
whoho!
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: cvs commit:
jakarta-avalon/src/java/org/apache/avalon/framework/configuration
ConfigurationUtil.java
Posted by Peter Donald <pe...@apache.org>.
At 08:11 PM 7/12/2002 +0000, you wrote:
>proyal 2002/07/12 13:11:34
>
> Added: src/java/org/apache/avalon/framework/configuration
> ConfigurationUtil.java
> Log:
> * Moved from org.apache.excalibur.configuration.ConfigurationUtil
> (inside merlin)
> * Added branch() per thread
> http://marc.theaimsgroup.com/?t=102347724100002&r=1&w=2
-1 on addition to framework CVS. Too much clutter and not consistent with
the rest of packages. Move to excalibur.util package if it is really desired.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>