You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Berin Loritsch <bl...@apache.org> on 2002/10/24 01:22:27 UTC
collections is released!
I will go through the process of committing the full deprecation on
Avalon collections and move it to Commons. We can get rid of that
dependency completely from our CVS. The question is, when do we want
to remove the dead code with a CVS delete?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: collections is released!
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> I will go through the process of committing the full deprecation on
>>> Avalon collections and move it to Commons. We can get rid of that
>>> dependency completely from our CVS. The question is, when do we want
>>> to remove the dead code with a CVS delete?
>>
>>
>>
>>
>> Some questions:
>>
>> 1. has the Excalibur Collections even been officially released?
>
>
> As part of Excalibur 4.0, yes.
<groan/>
>
>> 2. do we know of anyone using it
>
>
> Every ECM user.
>
>> 3. what is the impact on an Excalibur Collections user to migrate?
>
>
> In most cases it is as simple as changing the classname. I.e.
> org.apache.avalon.excalibur.collections.BucketMap becomes
> org.apache.commons.collections.StaticBucketMap.
>
> The interface is identical.
So a migration buildfile would basically be a replacement of package
imports ?
If so, could we add a migration.xml to the base directory ?
>
>
>
>> Some suggestions:
>>
>> 1. Insead of deleting put README in place that states clearly that
>> the package is dead
>> 2. Move the package into something like
>> jakarta-avalon-excalibur/subset/collections
>> 3. Delete the build file so as to prevent inadvertent CVS builds
>
>
> The big thing is that we need to establish the procedure now. Already,
> the JavaDocs are set up so that everything is deprecated and pointing
> to the new class names.
>
> Should we have a "dead" directory, and move the dead projects there
> before deleting? In this case, we would have:
Actually - I made a small mistake in the above message - instead of
"subset" - I meant to say "sunset". Its more gentle the "dead" which
certain cultures tend to avoid at all costs.
So, I would +1 an jakarta-avalon-excalibur/sunset/collection real fast.
>
>
> jakarta-avalon-excalibur/dead/collections
>
> The build file would still work, but no wasted effort will be used to
> maintain the collections.
>
> Would that be sufficient?
>
Yes with:
dead --> sunset
migration.xml
correcting the license even if it going into retiement
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: collections is released!
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Thu, 24 Oct 2002 12:41, Berin Loritsch wrote:
>>
>>> Should we have a "dead" directory, and move the dead projects there
>>> before deleting? In this case, we would have:
>>>
>>> jakarta-avalon-excalibur/dead/collections
>>>
>>> The build file would still work, but no wasted effort will be used to
>>> maintain the collections.
>>>
>>> Would that be sufficient?
>>
>>
>> I would prefer to leave it as is. Theres no real need to separate out
>> the code. The deprecation warnings say it all. Maybe we could add an
>> extra WARNING.txt file to base directory but that should be it.
>>
>> We don't separate out stable/alpha stuff so I don't see any need to
>> separate out graveyard stuff and I would thing that quite a few
>> people would still object if we did it to ECM
>
>
> When a project is dead, that means some months from now, IMHO it would
> be ok just to delete all the files in collections, thus nudging them
> to the Attic, adding a Warning and redirecting downloads to a CVS
> tarball in the distributions
>
> avalon-collections-mummified.tar.gz
>
> I see people get confused when "dead" code is left there in CVS.
Agreed - getting a grip on the status of different Excalibur projects is
really difficult. Seperating out dead content is a positive move.
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: collections is released!
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Thu, 24 Oct 2002 12:41, Berin Loritsch wrote:
>
>>Should we have a "dead" directory, and move the dead projects there
>>before deleting? In this case, we would have:
>>
>>jakarta-avalon-excalibur/dead/collections
>>
>>The build file would still work, but no wasted effort will be used to
>>maintain the collections.
>>
>>Would that be sufficient?
>
> I would prefer to leave it as is. Theres no real need to separate out the
> code. The deprecation warnings say it all. Maybe we could add an extra
> WARNING.txt file to base directory but that should be it.
>
> We don't separate out stable/alpha stuff so I don't see any need to separate
> out graveyard stuff and I would thing that quite a few people would still
> object if we did it to ECM
When a project is dead, that means some months from now, IMHO it would
be ok just to delete all the files in collections, thus nudging them to
the Attic, adding a Warning and redirecting downloads to a CVS tarball
in the distributions
avalon-collections-mummified.tar.gz
I see people get confused when "dead" code is left there in CVS.
--
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: collections is released!
Posted by Peter Donald <pe...@apache.org>.
On Thu, 24 Oct 2002 12:41, Berin Loritsch wrote:
> Should we have a "dead" directory, and move the dead projects there
> before deleting? In this case, we would have:
>
> jakarta-avalon-excalibur/dead/collections
>
> The build file would still work, but no wasted effort will be used to
> maintain the collections.
>
> Would that be sufficient?
I would prefer to leave it as is. Theres no real need to separate out the
code. The deprecation warnings say it all. Maybe we could add an extra
WARNING.txt file to base directory but that should be it.
We don't separate out stable/alpha stuff so I don't see any need to separate
out graveyard stuff and I would thing that quite a few people would still
object if we did it to ECM
--
Cheers,
Peter Donald
"The ability to quote is a serviceable substitute for wit." -- Maugham
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: collections is released!
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Berin Loritsch wrote:
>
>> I will go through the process of committing the full deprecation on
>> Avalon collections and move it to Commons. We can get rid of that
>> dependency completely from our CVS. The question is, when do we want
>> to remove the dead code with a CVS delete?
>
>
>
> Some questions:
>
> 1. has the Excalibur Collections even been officially released?
As part of Excalibur 4.0, yes.
> 2. do we know of anyone using it
Every ECM user.
> 3. what is the impact on an Excalibur Collections user to migrate?
In most cases it is as simple as changing the classname. I.e.
org.apache.avalon.excalibur.collections.BucketMap becomes
org.apache.commons.collections.StaticBucketMap.
The interface is identical.
> Some suggestions:
>
> 1. Insead of deleting put README in place that states clearly that the
> package is dead
> 2. Move the package into something like
> jakarta-avalon-excalibur/subset/collections
> 3. Delete the build file so as to prevent inadvertent CVS builds
The big thing is that we need to establish the procedure now. Already,
the JavaDocs are set up so that everything is deprecated and pointing
to the new class names.
Should we have a "dead" directory, and move the dead projects there
before deleting? In this case, we would have:
jakarta-avalon-excalibur/dead/collections
The build file would still work, but no wasted effort will be used to
maintain the collections.
Would that be sufficient?
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: collections is released!
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> I will go through the process of committing the full deprecation on
> Avalon collections and move it to Commons. We can get rid of that
> dependency completely from our CVS. The question is, when do we want
> to remove the dead code with a CVS delete?
Some questions:
1. has the Excalibur Collections even been officially released?
2. do we know of anyone using it
3. what is the impact on an Excalibur Collections user to migrate?
Some suggestions:
1. Insead of deleting put README in place that states clearly that the
package is dead
2. Move the package into something like
jakarta-avalon-excalibur/subset/collections
3. Delete the build file so as to prevent inadvertent CVS builds
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>