You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@avalon.apache.org by bl...@apache.org on 2003/03/11 15:16:28 UTC
cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
bloritsch 2003/03/11 06:16:27
Removed: cli .cvsignore README.txt ant.properties.sample
build.xml default.properties
cli/examples README.txt
cli/examples/basic BasicCLI.java README.txt
cli/examples/incompat_options IncompatOptions.java
README.txt
cli/examples/no_aliasing NoAlias.java README.txt
cli/examples/option_arguments OptionArguments.java
README.txt
cli/src/java/org/apache/avalon/excalibur/cli
AbstractParserControl.java CLArgsParser.java
CLOption.java CLOptionDescriptor.java CLUtil.java
ParserControl.java Token.java package.html
cli/src/test/org/apache/avalon/excalibur/cli/test
CLITestSuite.java ClutilTestCase.java
cli/src/xdocs index.xml menu.xml
collections .cvsignore WARNING.txt ant.properties.sample
build.xml default.properties
collections/src/java/org/apache/avalon/excalibur/collections
ArrayEnumeration.java ArrayStack.java
BinaryHeap.java BucketMap.java Buffer.java
BufferOverflowException.java
BufferUnderflowException.java CircularBuffer.java
FixedSizeBuffer.java IteratorEnumeration.java
ListUtils.java PriorityQueue.java
SynchronizedPriorityQueue.java
VariableSizeBuffer.java package.html
collections/src/test ListTest.java
collections/src/test/org/apache/avalon/excalibur/collections/test
BinaryHeapTestCase.java BucketMapTestCase.java
ThreadedMapTest.java
VariableSizeBufferTestCase.java
collections/src/xdocs book.xml index.xml tabs.xml
concurrent .cvsignore ant.properties.sample build.xml
default.properties
concurrent/src/java/org/apache/avalon/excalibur/concurrent
ConditionalEvent.java DijkstraSemaphore.java
DjikstraSemaphore.java Lock.java Mutex.java
ReadWriteLock.java Semaphore.java Sync.java
ThreadBarrier.java package.html
concurrent/src/test/org/apache/avalon/excalibur/concurrent/test
ReadWriteLockTestCase.java
concurrent/src/xdocs book.xml index.xml tabs.xml
util.concurrent-1.3.1.jar
container .cvsignore WARNING.txt ant.properties.sample
build.xml default.properties
container/src/etc project.mf
container/src/java/org/apache/excalibur/container/lifecycle
AbstractAccessor.java AbstractCreator.java
Accessor.java Creator.java package.html
container/src/test README.txt
container/src/xdocs attributes.xml book.xml extension.xml
index.xml list.xml tabs.xml
io .cvsignore README.txt WARNING.txt
ant.properties.sample build.xml default.properties
io/src/java/org/apache/avalon/excalibur/io
AndFileFilter.java
ClassLoaderObjectInputStream.java
DemuxInputStream.java DemuxOutputStream.java
DirectoryFileFilter.java EndianUtil.java
ExtensionFileFilter.java FileUtil.java IOUtil.java
InvertedFileFilter.java OrFileFilter.java
PrefixFileFilter.java SwappedDataInputStream.java
package.html
io/src/test/org/apache/avalon/excalibur/io/test
DemuxTestCase.java FileUtilTestCase.java
IOTestSuite.java IOUtilTestCase.java
io/src/xdocs index.xml menu.xml
Log:
all these packages are merged into compatibility or replaced by lifecycle
---------------------------------------------------------------------
To unsubscribe, e-mail: cvs-unsubscribe@avalon.apache.org
For additional commands, e-mail: cvs-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Leo Simons <le...@apache.org>.
because I'm totally lost on OSX atm. Its on my todo too, but lower :D
- Leo
Noel J. Bergman wrote:
> Why don't you work with Sam to get GUMP running on moof?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by "Noel J. Bergman" <no...@devtech.com>.
Leo,
Why don't you work with Sam to get GUMP running on moof?
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Leo Simons <le...@apache.org>.
Noel J. Bergman wrote:
> Admittedly, this concern
> comes in part because James HEAD no longer builds against Avalon HEAD
> because of changes to Excalibur packaging.
on my todo list right after excalibur phase I release is a full, clean
gump run. I should have my own machine with a full gump install this
weekend if things go as planned; I've postponed further work on gump and
the stuff that goes with it till then.
but, rest assured, your concerns have been duly noted (already ;).
in fact, here's my ASF todo list:
1) new machine
2) gump on new machine
3) clean gump of avalon and cocoon and all dependencies
4) DwA
5) java-repo (need something soon)
6) play with moof
7) go over and fix avalon.apache.org (again)
grz,
- LSD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Peter Donald <pe...@realityforge.org>.
> On Wed, 12 Mar 2003 07:37, Berin Loritsch wrote:
> > Peter Donald wrote:
> > > On Wed, 12 Mar 2003 01:16, bloritsch@apache.org wrote:
> > >> Log:
> > >> all these packages are merged into compatibility or replaced by
> > >> lifecycle
> > >
> > > -1 on cli and io being removed as free standing projects. There is no
> > > justification for doing so and they worked fine as they were
> > > previously. Why break something that worked and add extra cruft into
> > > dependency trees of projects that don't need that cruft?
>
> ...
>
> From a simple management viewpoint, it is easier to track deprecated
> code if it is all encapsulated in one JAR.
disagree. I think it is much easier to see what is deprecated by the
deprecated messages that go by when compiling. Then I can gradually move away
from the deprecated jars as needed.
--
Cheers,
Peter Donald
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 12 Mar 2003 07:37, Berin Loritsch wrote:
>
>>Peter Donald wrote:
>>You also had listed these projects as something to move out because
>>they do not fit the charter. Are you changing your mind?
>
>
> nope. They can be deprecated in place or moved as a whole into a compat
> subdirectory but theres no need to merge the projects.
>
From a simple management viewpoint, it is easier to track deprecated
code if it is all encapsulated in one JAR. Sure we could provide tools
to determine if a JAR is deprecated or not--but it is not what I want
to be maintaining myself.
Besides, a large JAR with additional cruft provides additional incentive
to migrate away from using it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 07:37, Berin Loritsch wrote:
> Peter Donald wrote:
> > On Wed, 12 Mar 2003 01:16, bloritsch@apache.org wrote:
> >> Log:
> >> all these packages are merged into compatibility or replaced by
> >> lifecycle
> >
> > -1 on cli and io being removed as free standing projects. There is no
> > justification for doing so and they worked fine as they were previously.
> > Why break something that worked and add extra cruft into dependency trees
> > of projects that don't need that cruft?
...
> I had already posted a vote on this subject last week, and noone
> responded negatively.
I believe I was at a week long music festival.
> You also had listed these projects as something to move out because
> they do not fit the charter. Are you changing your mind?
nope. They can be deprecated in place or moved as a whole into a compat
subdirectory but theres no need to merge the projects.
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by "Noel J. Bergman" <no...@devtech.com>.
>>>We will support users as much as we can. We've said it before, we say it
>>>again. Any incompatible change made was completely unintentional.
>> "saying" != "doing"
> I hope you aren't implying that incompatibilities in this case
> are intentional?
I perceived his comment to be saying that saying they'll be fixed is not the
same as doing it. I am not piling on, Berin. Just explaining how I
understood his comment.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 12 Mar 2003 09:40, Nicola Ken Barozzi wrote:
>
>>Peter Donald wrote, On 11/03/2003 22.15:
>>...
>>
>>
>>>...backward incompatible
>>>changes are all the rage in AValon these days. Supporting users is sooo
>>>yesterday.
>>
>>It's not.
>>
>>We will support users as much as we can. We've said it before, we say it
>>again. Any incompatible change made was completely unintentional.
>
>
> "saying" != "doing"
I hope you aren't implying that incompatibilities in this case are
intentional?
>>What do you all think should be our unit test policy?
>
>
> 100% coverage and 100% passing for toolkits or as close to as possible. ie an
> example of good quality would be
> http://spice.sourceforge.net/configkit/clover/index.html
>
> For integration components and containers we probably can't reasonably as
> stringent but should aim for high quality rather than this lets just change
> something and hope it compiles ... let alone works policy that is now in
> place.
Are you volunteering to help shore up our testcases?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 09:40, Nicola Ken Barozzi wrote:
> Peter Donald wrote, On 11/03/2003 22.15:
> ...
>
> > ...backward incompatible
> > changes are all the rage in AValon these days. Supporting users is sooo
> > yesterday.
>
> It's not.
>
> We will support users as much as we can. We've said it before, we say it
> again. Any incompatible change made was completely unintentional.
"saying" != "doing"
> To catch these early (yes, Gump should be our *last* resort), we should
> have unit tests running regularly on the classes; they would have
> probably caught these signature changes.
doubtful their signatures would have just been updated at the same time.
Besides how many people actually run the unit tests - given the number of
"stable" packages that have/had unit tests that fail I don't think there is a
lot.
> What do you all think should be our unit test policy?
100% coverage and 100% passing for toolkits or as close to as possible. ie an
example of good quality would be
http://spice.sourceforge.net/configkit/clover/index.html
For integration components and containers we probably can't reasonably as
stringent but should aim for high quality rather than this lets just change
something and hope it compiles ... let alone works policy that is now in
place.
--
Cheers,
Peter Donald
---------------------------------------------------
"It is easy to dodge our responsibilities, but we
cannot dodge the consequences of dodging our
responsibilities." -Josiah Stamp
---------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote, On 11/03/2003 22.15:
...
> ...backward incompatible
> changes are all the rage in AValon these days. Supporting users is sooo
> yesterday.
It's not.
We will support users as much as we can. We've said it before, we say it
again. Any incompatible change made was completely unintentional.
To catch these early (yes, Gump should be our *last* resort), we should
have unit tests running regularly on the classes; they would have
probably caught these signature changes.
What do you all think should be our unit test policy?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Peter Donald [mailto:peter@realityforge.org]
>
> Then again even if it did build james would not because
> backward incompatible changes are all the rage in AValon these days.
> Supporting users is sooo yesterday.
But whining is *timeless*.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 08:12, Peter Donald wrote:
> On Wed, 12 Mar 2003 07:51, Noel J. Bergman wrote:
> > IF there is compatibility, that is reasonable, but you cannot break
> > compatibility within AV 4, right? I'm becoming concerned that things are
> > being moved before the compatibility is in place. Admittedly, this
> > concern comes in part because James HEAD no longer builds against Avalon
> > HEAD because of changes to Excalibur packaging.
>
> Don't worry - half of Avalon is not building atm for the same reason so you
> are not alone.
Then again even if it did build james would not because backward incompatible
changes are all the rage in AValon these days. Supporting users is sooo
yesterday.
--
Cheers,
Peter Donald
----------------------------------------
Why does everyone always overgeneralize?
----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 07:51, Noel J. Bergman wrote:
> IF there is compatibility, that is reasonable, but you cannot break
> compatibility within AV 4, right? I'm becoming concerned that things are
> being moved before the compatibility is in place. Admittedly, this concern
> comes in part because James HEAD no longer builds against Avalon HEAD
> because of changes to Excalibur packaging.
Don't worry - half of Avalon is not building atm for the same reason so you
are not alone.
--
Cheers,
Peter Donald
------------------------------------------------
| We shall not cease from exploration, and the |
| end of all our exploring will be to arrive |
| where we started and know the place for the |
| first time -- T.S. Eliot |
------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Berin Loritsch <bl...@apache.org>.
Noel J. Bergman wrote:
> Berin,
>
>
>>We are getting away from supporting those projects, and they have
>>reasonable replacements (most of them any way). The compatibility
>>project is used to provide a holding place for all projects we
>>are no longer actively supporting--so that users have time to migrate
>>away from those projects.
>
>
> IF there is compatibility, that is reasonable, but you cannot break
> compatibility within AV 4, right? I'm becoming concerned that things are
> being moved before the compatibility is in place. Admittedly, this concern
> comes in part because James HEAD no longer builds against Avalon HEAD
> because of changes to Excalibur packaging.
There was a lack of GUMP nagging, so we did not know about those build
breaks.
I updated GUMP today, and hopefully all should build again.
I also reverted the changes to the ThreadPool so that JAMES would
continue to build.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 08:10, Berin Loritsch wrote:
> > How about a couple of weeks? Any chance of you fixing the mess you made
> > with all the incompatible changes to thread stuff?
>
> Let me look at the gump complaints on thread stuff.
They are what I have already outlined. Incompatible changes in signature both
return type of all the methods.
> Also do you know why we are not getting nags? We are supposed to be
> informed when our stuff doesn't build.
Gump produces nags when builds fail (and I assume we will see a few next run
for things like excalibur-cli). It does not by default produce nags when
prereqs fail which means the fact that swathes are not building (ie phoenix)
will never get informed of this. I used to send nags on prereq failures for
somethings but because more time was spent failing to build than actually
building I disabled it.
--
Cheers,
Peter Donald
*----------------------------------------------------*
| "the mother of idiots is always pregnant." |
*----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 12 Mar 2003 07:57, Berin Loritsch wrote:
>
>>>IF there is compatibility, that is reasonable, but you cannot break
>>>compatibility within AV 4, right? I'm becoming concerned that things are
>>>being moved before the compatibility is in place. Admittedly, this
>>>concern comes in part because James HEAD no longer builds against Avalon
>>>HEAD because of changes to Excalibur packaging.
>>
>>What do you mean before compatibility is in place?
>
>
> Gump is not building.
That can be fixed.
>>Are you saying we
>>cannot move anything until all our dependent projects notify us and
>>tell us that they are ready?
>
>
> Or maybe things should not be removed until they have been verified in new
> location and everyone agrees to the deletion.
Fair enough
>>Can we handle a temporary incompatibility that lasts for a day--or at
>>the most two?
>
>
> How about a couple of weeks? Any chance of you fixing the mess you made with
> all the incompatible changes to thread stuff?
Let me look at the gump complaints on thread stuff.
Also do you know why we are not getting nags? We are supposed to be
informed when our stuff doesn't build.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 07:57, Berin Loritsch wrote:
> > IF there is compatibility, that is reasonable, but you cannot break
> > compatibility within AV 4, right? I'm becoming concerned that things are
> > being moved before the compatibility is in place. Admittedly, this
> > concern comes in part because James HEAD no longer builds against Avalon
> > HEAD because of changes to Excalibur packaging.
>
> What do you mean before compatibility is in place?
Gump is not building.
> Are you saying we
> cannot move anything until all our dependent projects notify us and
> tell us that they are ready?
Or maybe things should not be removed until they have been verified in new
location and everyone agrees to the deletion.
> Can we handle a temporary incompatibility that lasts for a day--or at
> the most two?
How about a couple of weeks? Any chance of you fixing the mess you made with
all the incompatible changes to thread stuff?
--
Cheers,
Peter Donald
----------------------------------------
Whatever you do will be insignificant,
but it is very important that you do it.
--Gandhi
----------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Berin Loritsch <bl...@apache.org>.
gstein@lyra.org wrote:
> In article <3E...@apache.org>, "Berin Loritsch"
> <bl...@apache.org> wrote:
>
>>...
>>What do you mean before compatibility is in place? Are you saying we
>>cannot move anything until all our dependent projects notify us and tell
>>us that they are ready?
>>
>>Can we handle a temporary incompatibility that lasts for a day--or at
>>the most two?
>
> 1) revert the changes to restore compat
> 2) come up with another mechanism to establish back-compat
> (some kind of extra jar containing deprecated code(?) is what I think
> Berin suggested; I'm obviously out of my element here :-)
Apparently ANT is stricter about requiring all path elements to exist
in CVS--which is why the GUMP build failed last night.
Hopefully I have resolved these issues for the compatibility and
lifecycle packages
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Deprecation, repackaging, and compatibility
Posted by Peter Donald <pe...@realityforge.org>.
On Thu, 13 Mar 2003 05:42, Noel J. Bergman wrote:
> Moving a type from one package to another creates a new type.
> Compatibility requires either source changes in the client, or a proxy
> class in the old package.
>
> With respect to method changes, given existing type E, old type O, new type
> N:
>
> Case #1:
>
> void E.m(O) => void E.m(N)
>
> Short form: A solution is to have both signatures, and provide the name of
> the jar containing O.
I think we can get away with moving parameters to more abstract types as long
as long as the more abstract type does not appear as a parameter in the
interface previously. This was how it was originally implemented
> Case #2:
>
> O E.m() => N E.m()
>
> #2.1 O = E.m(); // compatibility requires N extends O
> #2.2 f(E.m()); // either N extends O, or add f(N)
>
> If N does not extend O, the change is incompatible. If N extends O, the
> change is source compatible because N can be promoted to O. In the current
> case, it means a new class would be extending a deprecated one, but it does
> compile. Binary compatibility is also a concern.
thats how it used to be.
--
Cheers,
Peter Donald
*----------------------------------------------------------*
The phrase "computer literate user" really means the person
has been hurt so many times that the scar tissue is thick
enough so he no longer feels the pain.
-- Alan Cooper, The Inmates are Running the Asylum
*----------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Deprecation, repackaging, and compatibility
Posted by "Noel J. Bergman" <no...@devtech.com>.
Moving a type from one package to another creates a new type. Compatibility
requires either source changes in the client, or a proxy class in the old
package.
With respect to method changes, given existing type E, old type O, new type
N:
Case #1:
void E.m(O) => void E.m(N)
Short form: A solution is to have both signatures, and provide the name of
the jar containing O.
Long form: This can be handled by adding a new method and deprecating the
existing one. No real issue from my perspective if Berin wants to push O
into a compatibility jar, so long as the latter does exist, and we're told
where. :-)
With respect to CVS vs release, GUMP promotes that such changes be committed
at the same time or within some reasonable timeframe, because otherwise GUMP
cannot provide its continuous integration function.
Case #2:
O E.m() => N E.m()
#2.1 O = E.m(); // compatibility requires N extends O
#2.2 f(E.m()); // either N extends O, or add f(N)
If N does not extend O, the change is incompatible. If N extends O, the
change is source compatible because N can be promoted to O. In the current
case, it means a new class would be extending a deprecated one, but it does
compile. Binary compatibility is also a concern.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by gs...@lyra.org.
In article <3E...@apache.org>, "Berin Loritsch"
<bl...@apache.org> wrote:
>...
> What do you mean before compatibility is in place? Are you saying we
> cannot move anything until all our dependent projects notify us and tell
> us that they are ready?
>
> Can we handle a temporary incompatibility that lasts for a day--or at
> the most two?
The group voted on this change, it was done, and now there are some issues
with it. The answer is to move forward and fix the problems, rather than
always needing to go backwards.
In this case, Peter said "it broke compatibility". So the requirement is
to fix that, not necessarily to revert. Remember: a veto has a technical
reason behind it. The solution is to address the *reason* rather than to
simply revert changes. Thus, there would seem to be two solutions:
1) revert the changes to restore compat
2) come up with another mechanism to establish back-compat
(some kind of extra jar containing deprecated code(?) is what I think
Berin suggested; I'm obviously out of my element here :-)
Also, it is important to keep in mind that these are changes to CVS. It
would seem to be perfectly acceptable to allow incompatibilities to exist
within CVS for any period of time. For the *releases* ... yes, it does
seem to be extremely important to retain backwards compat (even if that
means whole swaths of deprecated classes/methods).
So... what are the constructive ways to move forward? What are the
choices?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Deprecation, repackaging, and compatibility
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 09:20, Berin Loritsch wrote:
> The Thread changes are now reverted--however I think your messages got
> lost in the deluge of posts.
Not the ones to the excalibur-thread package - can you also do as I recomended
and rever them so we don't break backwards compatability due to change
signatures esp return values?
Oh and if it will make you move any faster consider this a -1 on changes in
excalibur-thread you committed due to the fact that it broke backwards
compatability.
--
Cheers,
Peter Donald
----------------------------------------------------------------
Fools ignore complexity. Pragmatists suffer it.
Some can avoid it. Geniuses remove it.
-- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982
----------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: Deprecation, repackaging, and compatibility
Posted by "Noel J. Bergman" <no...@devtech.com>.
> To the best of our ability we try to maintain that compatibility--esp.
> for released components. Things like GUMP are tools to help in the
> process.
I know you have that as a goal, Berin. Which made this recent issue rather
surprising.
> The Thread changes are now reverted--however I think your messages got
> lost in the deluge of posts.
Apparently so. The only person who responded was Peter Donald. I would
have expected responses from you or Stephen.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Deprecation, repackaging, and compatibility
Posted by Berin Loritsch <bl...@apache.org>.
Noel J. Bergman wrote:
>>What do you mean before compatibility is in place? Are you saying
>>we cannot move anything until all our dependent projects notify us
>>and tell us that they are ready?
>
>
> You cannot depend upon your dependent projects to notify you, period. What
> makes you think that more than 1% of Avalon dependents track your CVS or
> uses GUMP? It is Avalon's job to maintain compatibility, not theirs to
> notify you after things are broken.
To the best of our ability we try to maintain that compatibility--esp.
for released components. Things like GUMP are tools to help in the
process.
If we make a change that is not backwards compatible, it is usually
not intentional.
>>Can we handle a temporary incompatibility that lasts for a day--or at
>>the most two?
>
>
> James as been broken for longer than that now. Ever since the thread
> changes. I have posted about that several times. I'm surprised that you
> haven't noticed.
The Thread changes are now reverted--however I think your messages got
lost in the deluge of posts.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: Deprecation, repackaging, and compatibility
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> The Thread changes are now reverted--however I think your messages got
> lost in the deluge of posts.
tip: have your e-mail client mark or move messages containing
Re: cvs commit
Fw: cvs commit
Re: [GUMP]
Fw: [GUMP]
these usually identify human replies to problematic changes, and as such
deserve special treatment :D
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Deprecation, repackaging, and compatibility
Posted by "Noel J. Bergman" <no...@devtech.com>.
> What do you mean before compatibility is in place? Are you saying
> we cannot move anything until all our dependent projects notify us
> and tell us that they are ready?
You cannot depend upon your dependent projects to notify you, period. What
makes you think that more than 1% of Avalon dependents track your CVS or
uses GUMP? It is Avalon's job to maintain compatibility, not theirs to
notify you after things are broken.
> Can we handle a temporary incompatibility that lasts for a day--or at
> the most two?
James as been broken for longer than that now. Ever since the thread
changes. I have posted about that several times. I'm surprised that you
haven't noticed.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Berin Loritsch <bl...@apache.org>.
Noel J. Bergman wrote:
> Berin,
>
>
>>We are getting away from supporting those projects, and they have
>>reasonable replacements (most of them any way). The compatibility
>>project is used to provide a holding place for all projects we
>>are no longer actively supporting--so that users have time to migrate
>>away from those projects.
>
>
> IF there is compatibility, that is reasonable, but you cannot break
> compatibility within AV 4, right? I'm becoming concerned that things are
> being moved before the compatibility is in place. Admittedly, this concern
> comes in part because James HEAD no longer builds against Avalon HEAD
> because of changes to Excalibur packaging.
What do you mean before compatibility is in place? Are you saying we
cannot move anything until all our dependent projects notify us and
tell us that they are ready?
Can we handle a temporary incompatibility that lasts for a day--or at
the most two?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by "Noel J. Bergman" <no...@devtech.com>.
Berin,
> We are getting away from supporting those projects, and they have
> reasonable replacements (most of them any way). The compatibility
> project is used to provide a holding place for all projects we
> are no longer actively supporting--so that users have time to migrate
> away from those projects.
IF there is compatibility, that is reasonable, but you cannot break
compatibility within AV 4, right? I'm becoming concerned that things are
being moved before the compatibility is in place. Admittedly, this concern
comes in part because James HEAD no longer builds against Avalon HEAD
because of changes to Excalibur packaging.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Berin Loritsch <bl...@apache.org>.
Peter Donald wrote:
> On Wed, 12 Mar 2003 01:16, bloritsch@apache.org wrote:
>
>> Log:
>> all these packages are merged into compatibility or replaced by lifecycle
>
>
> -1 on cli and io being removed as free standing projects. There is no
> justification for doing so and they worked fine as they were previously. Why
> break something that worked and add extra cruft into dependency trees of
> projects that don't need that cruft?
>
We are getting away from supporting those projects, and they have
reasonable replacements (most of them any way). The compatibility
project is used to provide a holding place for all projects we
are no longer actively supporting--so that users have time to migrate
away from those projects.
I had already posted a vote on this subject last week, and noone
responded negatively. We need to look at removing the requirement
to support free standing projects that do not fit in our charter.
You also had listed these projects as something to move out because
they do not fit the charter. Are you changing your mind?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: cvs commit: avalon-excalibur/io/src/xdocs index.xml menu.xml
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 12 Mar 2003 01:16, bloritsch@apache.org wrote:
> bloritsch 2003/03/11 06:16:27
>
> Removed: cli .cvsignore README.txt ant.properties.sample
> build.xml default.properties
> cli/examples README.txt
> cli/examples/basic BasicCLI.java README.txt
> cli/examples/incompat_options IncompatOptions.java
> README.txt
> cli/examples/no_aliasing NoAlias.java README.txt
> cli/examples/option_arguments OptionArguments.java
> README.txt
> cli/src/java/org/apache/avalon/excalibur/cli
> AbstractParserControl.java CLArgsParser.java
> CLOption.java CLOptionDescriptor.java CLUtil.java
> ParserControl.java Token.java package.html
> cli/src/test/org/apache/avalon/excalibur/cli/test
> CLITestSuite.java ClutilTestCase.java
> cli/src/xdocs index.xml menu.xml
> collections .cvsignore WARNING.txt ant.properties.sample
> build.xml default.properties
> collections/src/java/org/apache/avalon/excalibur/collections
> ArrayEnumeration.java ArrayStack.java
> BinaryHeap.java BucketMap.java Buffer.java
> BufferOverflowException.java
> BufferUnderflowException.java CircularBuffer.java
> FixedSizeBuffer.java IteratorEnumeration.java
> ListUtils.java PriorityQueue.java
> SynchronizedPriorityQueue.java
> VariableSizeBuffer.java package.html
> collections/src/test ListTest.java
>
> collections/src/test/org/apache/avalon/excalibur/collections/test
> BinaryHeapTestCase.java BucketMapTestCase.java ThreadedMapTest.java
> VariableSizeBufferTestCase.java
> collections/src/xdocs book.xml index.xml tabs.xml
> concurrent .cvsignore ant.properties.sample build.xml
> default.properties
> concurrent/src/java/org/apache/avalon/excalibur/concurrent
> ConditionalEvent.java DijkstraSemaphore.java
> DjikstraSemaphore.java Lock.java Mutex.java
> ReadWriteLock.java Semaphore.java Sync.java
> ThreadBarrier.java package.html
>
> concurrent/src/test/org/apache/avalon/excalibur/concurrent/test
> ReadWriteLockTestCase.java
> concurrent/src/xdocs book.xml index.xml tabs.xml
> util.concurrent-1.3.1.jar
> container .cvsignore WARNING.txt ant.properties.sample
> build.xml default.properties
> container/src/etc project.mf
> container/src/java/org/apache/excalibur/container/lifecycle
> AbstractAccessor.java AbstractCreator.java
> Accessor.java Creator.java package.html
> container/src/test README.txt
> container/src/xdocs attributes.xml book.xml extension.xml
> index.xml list.xml tabs.xml
> io .cvsignore README.txt WARNING.txt
> ant.properties.sample build.xml default.properties
> io/src/java/org/apache/avalon/excalibur/io
> AndFileFilter.java
> ClassLoaderObjectInputStream.java
> DemuxInputStream.java DemuxOutputStream.java
> DirectoryFileFilter.java EndianUtil.java
> ExtensionFileFilter.java FileUtil.java IOUtil.java
> InvertedFileFilter.java OrFileFilter.java
> PrefixFileFilter.java SwappedDataInputStream.java
> package.html
> io/src/test/org/apache/avalon/excalibur/io/test
> DemuxTestCase.java FileUtilTestCase.java
> IOTestSuite.java IOUtilTestCase.java
> io/src/xdocs index.xml menu.xml
> Log:
> all these packages are merged into compatibility or replaced by lifecycle
-1 on cli and io being removed as free standing projects. There is no
justification for doing so and they worked fine as they were previously. Why
break something that worked and add extra cruft into dependency trees of
projects that don't need that cruft?
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "Religion is what the common people see as true, the |
| wise people see as false, and the rulers see as |
| useful" --Seneca |
*------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org