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 2003/01/31 07:01:09 UTC
[Proposal] LogKit Release Plan
LogKit is at the bottom of our food chain, and there are some minor
issues we need to work out before we do a release. Below is the
order of precedence. If we cannot get consensus we will take the
easiest route to get a release.
#1 Remove circular dependency on Framework
-------------------------------------------
The particular class that forces the dependency is an "Avalon"
formatter that can handle the nested exceptions from Avalon.
It is a hold-over from when we did a first release after we
moved to Jakarta. I think it is relatively safe to remove the
class as it merely extends the correct version. It has been
deprecated from about the second release.
+1 from me.
#2 Maven integration for build
-------------------------------
The build is very simple, and nothing really major needs to
be done. LogKit's Ant build isn't problematic, so it is
ok to leave it alone as well. The question is before or after
release? If we cannot resolve the issue soon, we will merely
make it after the release.
#3 Documentation
-----------------
LogKit documentation is fairly sparse. We have *something*,
but nothing that covers all the features and how to set it up.
The current docs are OK while we make a quick release, but we
do need to put some attention into those docs soon. LogKit
hasn't changed much, so there is a good chance the docs will
be good for a long time. We could release now, and add docs
as they come in to the web site.
Aside from a few Status changes, and the resolution of these
issues, there should be nothing holding back the release of
LogKit.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [VOTE:DIFF] Removing the ancient back-compatibility classes (was:
Re: [Proposal] LogKit Release Plan)
Posted by Leo Simons <le...@apache.org>.
Peter Donald wrote:
> On Fri, 31 Jan 2003 17:01, Berin Loritsch wrote:
>
>>#1 Remove circular dependency on Framework
>>-------------------------------------------
>>The particular class that forces the dependency is an "Avalon"
>>formatter that can handle the nested exceptions from Avalon.
>>It is a hold-over from when we did a first release after we
>>moved to Jakarta. I think it is relatively safe to remove the
>>class as it merely extends the correct version. It has been
>>deprecated from about the second release.
>
>
> I would prefer to leave it in. We should not be breaking backwards
> compatability in released code for anything as silly as academic purity. If
> you want to break the dependency chain then do the following;
>
> From memory the formatter uses avalons ExceptionUtil to get the cause of the
> exception so it can printout nested exceptions. I would recomend what you do
> is copy the ExceptionUtil code into the formatter in logkit package (or at
> least the reflection based part of it).
>
> That way we don't break backwards compatability.
this sounds feasible, and a better alternative, with a lower impact on
the logkit userbase while still attaining the goal of a clean dependency
chain. Hence, I'll change my vote to -1 on the original diff and +1 on
doing things the way Pete outlines.
cheers,
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Peter Donald <pe...@realityforge.org>.
On Fri, 31 Jan 2003 17:01, Berin Loritsch wrote:
> #1 Remove circular dependency on Framework
> -------------------------------------------
> The particular class that forces the dependency is an "Avalon"
> formatter that can handle the nested exceptions from Avalon.
> It is a hold-over from when we did a first release after we
> moved to Jakarta. I think it is relatively safe to remove the
> class as it merely extends the correct version. It has been
> deprecated from about the second release.
I would prefer to leave it in. We should not be breaking backwards
compatability in released code for anything as silly as academic purity. If
you want to break the dependency chain then do the following;
From memory the formatter uses avalons ExceptionUtil to get the cause of the
exception so it can printout nested exceptions. I would recomend what you do
is copy the ExceptionUtil code into the formatter in logkit package (or at
least the reflection based part of it).
That way we don't break backwards compatability.
> #2 Maven integration for build
> -------------------------------
mavens kool but I can't see a need to fix anything that aint broke. We can
always do it later.
--
Cheers,
Peter Donald
----------------------------------------------
Money is how people with no talent keep score.
----------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Stephen McConnell <mc...@apache.org>.
Berin Loritsch wrote:
> LogKit is at the bottom of our food chain, and there are some minor
> issues we need to work out before we do a release. Below is the
> order of precedence. If we cannot get consensus we will take the
> easiest route to get a release.
>
> #1 Remove circular dependency on Framework
> -------------------------------------------
> The particular class that forces the dependency is an "Avalon"
> formatter that can handle the nested exceptions from Avalon.
> It is a hold-over from when we did a first release after we
> moved to Jakarta. I think it is relatively safe to remove the
> class as it merely extends the correct version. It has been
> deprecated from about the second release.
>
> +1 from me.
me too +1
>
>
>
> #2 Maven integration for build
> -------------------------------
> The build is very simple, and nothing really major needs to
> be done. LogKit's Ant build isn't problematic, so it is
> ok to leave it alone as well. The question is before or after
> release? If we cannot resolve the issue soon, we will merely
> make it after the release.
Putting in place a Maven build in parrallel with the ant build is not
going to harm anyone. In fact its a positive thing because it lets us
experiment a bit. With the resolution of the recusvie depedency stuff
noted above - this becomes easy and provides a good starting point for
people who want to experiment. I.e. Maven is this context is not a
release issue - it just a good idea. We the realease against ant and
publish against the result of the ant build.
>
> #3 Documentation
> -----------------
> LogKit documentation is fairly sparse. We have *something*,
> but nothing that covers all the features and how to set it up.
> The current docs are OK while we make a quick release, but we
> do need to put some attention into those docs soon. LogKit
> hasn't changed much, so there is a good chance the docs will
> be good for a long time. We could release now, and add docs
> as they come in to the web site.
I'm not too fussed about this - the only complains I've been receiving
about logkit concern the absence of the ability to release a logging
channel. I havn't seen any issues concerning documentation (which is
not the same case for Excalibur logger - but that's further down the
food chain).
>
> Aside from a few Status changes, and the resolution of these
> issues, there should be nothing holding back the release of
> LogKit.
I agree.
1. lets eliminate the recursice dependency.
2. get a good clean framework independent build in place
3. release
Next stop - framework.
Cheers, Steve.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>>What's your definition of "a while"? We need a plan for removing them.
>>
>>How about a plan of "We don't remove them". No need to break code on a
>
> whim.
>
> How's about Avalon 5? I agree that unless you know what your existing
> client base is using, that you need not break backwards compatibility within
> a major version.
+1
We have to assure that our users are confortable with mixing our
deliverables easily.
> Seems to me that lesson ought to have been learned by now ...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Proposal] LogKit Release Plan
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > How's about Avalon 5?
> AValon5 refers to framework classes which are on a completely different
> release schedule than logkit and Logkit should never need another major
> version.
AV5 also refers to a container and component packages.
As an aside, I disagree with respect to the release schedule on the
following grounds.
When we release James vX, we release all of it. There may be classes,
entire subsystems, that haven't changed in ages. But they are all part of a
single, defined, tagged, supported Release build.
Any project that adopts a piecemeal approach to release management
encounters problems. This isn't to say that there aren't reasons to do so.
In some cases it makes sense, but it rarely doesn't cause problems, so it
should be avoided when possible.
Yes, someone else can take Frameworks and Components, and write their own
container. But that is their problem to support. The Avalon PMC is
responsible for what it ships.
This isn't to say that there isn't a place for releasing supplimental
packages separate from the main release. But a coordinated approach to code
release should be normative, in my view.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 1 Feb 2003 09:59, Noel J. Bergman wrote:
> > > What's your definition of "a while"? We need a plan for removing them.
> >
> > How about a plan of "We don't remove them". No need to break code on a
>
> whim.
>
> How's about Avalon 5?
AValon5 refers to framework classes which are on a completely different
release schedule than logkit and Logkit should never need another major
version.
> I agree that unless you know what your existing
> client base is using, that you need not break backwards compatibility
> within a major version.
>
> Seems to me that lesson ought to have been learned by now ...
You would think...
Seems silly to break backwards compatability at anytime regardless of
versioinng unless there is more to gain than is lost by futzing with existing
users.
--
Cheers,
Peter Donald
*----------------------------------------------------*
| "Luck is the residue of design" -- Branch Rickey |
*----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
RE: [Proposal] LogKit Release Plan
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > What's your definition of "a while"? We need a plan for removing them.
> How about a plan of "We don't remove them". No need to break code on a
whim.
How's about Avalon 5? I agree that unless you know what your existing
client base is using, that you need not break backwards compatibility within
a major version.
Seems to me that lesson ought to have been learned by now ...
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 1 Feb 2003 07:30, Berin Loritsch wrote:
> What's your definition of "a while"? We need a plan for removing them.
How about a plan of "We don't remove them". No need to break code on a whim.
--
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: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Peter Royal <pr...@apache.org>.
On Friday, January 31, 2003, at 03:30 PM, Berin Loritsch wrote:
>> The JDK still has deprecated classes from Java 1.1 ... I'm +1 on a
>> 'compat.jar', after its been in there for awhile we can the remove
>> permanently.
>> -pete
>
> What's your definition of "a while"? We need a plan for removing them.
>
> It's been there for a long while. I have the code ready to completely
> remove them, but I haven't committed it yet. I am waiting to here
> back from everyone.
6mo in a compat jar. thats arbitrary though. If most want them gone,
remove them.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Friday, January 31, 2003, at 09:18 AM, Berin Loritsch wrote:
>
>>> +1. Maybe we can release put some kind of compat.jar in with the
>>> distribution that contains this class?
>>
>>
>> I don't think its necessary. That *deprecated* class has been there
>> from almost the beginning. If people are still using it, shame on
>> them!
>>
>> It should be safe to remove it after 1.5 years don't you think?
>
>
> The JDK still has deprecated classes from Java 1.1 ... I'm +1 on a
> 'compat.jar', after its been in there for awhile we can the remove
> permanently.
> -pete
What's your definition of "a while"? We need a plan for removing them.
It's been there for a long while. I have the code ready to completely
remove them, but I haven't committed it yet. I am waiting to here
back from everyone.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release
Plan )
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
>
> Stephen McConnell wrote:
> ...
>
>>
>> Honestly - I think its a bad thing to do. Deprecation is something
>> that can be formally applied at a Java source file level and
>> inforomally defined on other artificats (configs, etc). I would
>> prefer this sort of thing to be managed at the CVS level in
>> conjuntion with appropriate build procedures. If you tag something
>> in CVS as a 1_X branch, then under that a 1_1 branch, and things get
>> deprecated - when you do the 2_X branch - that's the point where the
>> deprecated content dissapears. By introducing a xxx/classic and
>> xxx/compat your basically moving the notion of branching out of CVS
>> and into the file structure.
>
>
> This is not what I intend.
>
> In 1.0 I have a class.
> In 1.1 i deprecated it and move it in the src/deprecated dir.
> In 2.0 I remove the deprecated stuff.
>
> The benefits in 1.1 are that I can be *sure* that the core package
> doesn't need the deprecated classes to compile, that the users
> understand better that they are deprecated, and that users that want
> to not use deprecated stuff can do so without having the deprecated
> stuff in the classpath.
This works when you have a relatively clean seperation - e.g. building
framework without the component package is a viable proposition.
However, if you look at the logkit scenario you have non-deprecated
class that are referencing depricated classes. Which means that
deprecated classes need to be brought back into the standard java/src in
order to build. I.e. the strategy breaks because of the non-deprecated
referencing depricated cases.
>
> Look at Cocoon, we cannot build a Cocoon without dozens of deprecated
> classes. This means that deprecation has been totally inefective.
Actually I think there is a darker problem underlying all of this. When
we do "COP" we design with an ever present notionof service verus work
interface. When we think about changing things, I've seen several cases
of changes that maintain the service interface but break the inheritance
based usage. Based on the problesm I am seeing related to COP usage -
I'm moving in favour of component classes being declared final, but
backed by a non-final abstract class. The reason is that making
promises relative to inhertence is a totally different subject relative
to maintaining a service contract.
>
>> Clearly things in the file structure tend to be easier to manage -
>> but at the same time I think it has a bunch of hidden problems. Test
>> cases in one example, but what about configurations, property files,
>> etc. At the end of the day I think that this comes down to better
>> management of CVS tags and synchronizing builds against tagged content.
>
>
> Hmmm, probably you don't get the point, see above.
>
> The simplest thing is to do the following:
>
> 1) compile the source
> 2) compile the deprecated classes with (1) in classpath
> 3) use the two packages combined in all following steps
>
> In this way you get the separation benefits without additional problems.
Assuming there are not deprecated classes referenced in you main src tree.
(and that's a big assumption)
Cheers, Steve.
>
>
>>> Yeah, that's why it's a proposal. ;-)
>>>
>>
>> I understand what your aiming at - just not convinced about the
>> approach ;-)
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release
Plan )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
...
>
> Honestly - I think its a bad thing to do. Deprecation is something that
> can be formally applied at a Java source file level and inforomally
> defined on other artificats (configs, etc). I would prefer this sort of
> thing to be managed at the CVS level in conjuntion with appropriate
> build procedures. If you tag something in CVS as a 1_X branch, then
> under that a 1_1 branch, and things get deprecated - when you do the 2_X
> branch - that's the point where the deprecated content dissapears. By
> introducing a xxx/classic and xxx/compat your basically moving the
> notion of branching out of CVS and into the file structure.
This is not what I intend.
In 1.0 I have a class.
In 1.1 i deprecated it and move it in the src/deprecated dir.
In 2.0 I remove the deprecated stuff.
The benefits in 1.1 are that I can be *sure* that the core package
doesn't need the deprecated classes to compile, that the users
understand better that they are deprecated, and that users that want to
not use deprecated stuff can do so without having the deprecated stuff
in the classpath.
Look at Cocoon, we cannot build a Cocoon without dozens of deprecated
classes. This means that deprecation has been totally inefective.
> Clearly
> things in the file structure tend to be easier to manage - but at the
> same time I think it has a bunch of hidden problems. Test cases in one
> example, but what about configurations, property files, etc. At the end
> of the day I think that this comes down to better management of CVS tags
> and synchronizing builds against tagged content.
Hmmm, probably you don't get the point, see above.
The simplest thing is to do the following:
1) compile the source
2) compile the deprecated classes with (1) in classpath
3) use the two packages combined in all following steps
In this way you get the separation benefits without additional problems.
>> Yeah, that's why it's a proposal. ;-)
>>
>
> I understand what your aiming at - just not convinced about the approach
> ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release
Plan )
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
>
>>
>>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Peter Donald wrote:
>>>
>>>> On Sat, 1 Feb 2003 01:18, Berin Loritsch wrote:
>>>>
>>>>>> +1. Maybe we can release put some kind of compat.jar in with the
>>>>>> distribution that contains this class?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I don't think its necessary. That *deprecated* class has been there
>>>>> from almost the beginning. If people are still using it, shame on
>>>>> them!
>>>>>
>>>>> It should be safe to remove it after 1.5 years don't you think?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I would prefer us to maintain compatability in released code.
>>>> Especially when there is no real reason to break it.
>>>
>>>
>>>
>>>
>>> Peter, this is what deprecation is all about, no?
>>> Keep the stuff in for others to have time to change, then remove it.
>>>
>>> Removing deprecated classes between major versions is a safe bet.
>>> Between point versions it's a possibility.
>>> Between fixes it's an error.
>>>
>>> I'd suggest the following as a guideline:
>>>
>>> - deprecating classes results in @deprecated being added
>>> - in the next minor point release, they are moved to a
>>> deprecated source tree for the component that is compiled
>>> *after* the main ones, so that we are sure that /we/ do not
>>> rely on those.
>>> - in the major releases the classes can be removed with a vote.
>>>
>>> Thoughts?
>>
>>
>>
>>
>> Hi Nicola:
>>
>> I think the notion of "moving" depreciated classes needs more cooking.
>
>
> Yes, I'm still experimenting with Cocoon, but I find it *very*
> interesting.
>
>> Take logkit as an example. There is a src/java and a source/compat.
>> You cannot build one with the other.
>
>
> Ahhh, ok. Yes, this is kinda wierd.
>
>> If on the other hand you were talking about moving a class source to
>> a deprecated set of sources - AND - the main sources could be built
>> without it - i.e. independently - then this would more sense.
>
>
> Yes, I mean this :-)
>
>> However - in doing this you implicitly complicate you structure and
>> while probably not significant in itself, if your looking at
>> automating tools for building on a project like Avalon then its a
>> significant point. Its significant because it is suggesting that any
>> Avalon project could include a src/compat directory that needs to be
>> included in the compile targets.
>
>
> Ant is an automated too :-)
>
> If we use the same dir structure for all projects, we just need a
> single build.xml and import it in all the project builds, it's not a
> problem.
>
>> Taking this further - does the same policy apply to test cases?
>
>
> Good point. What do you think?
Honestly - I think its a bad thing to do. Deprecation is something that
can be formally applied at a Java source file level and inforomally
defined on other artificats (configs, etc). I would prefer this sort of
thing to be managed at the CVS level in conjuntion with appropriate
build procedures. If you tag something in CVS as a 1_X branch, then
under that a 1_1 branch, and things get deprecated - when you do the 2_X
branch - that's the point where the deprecated content dissapears. By
introducing a xxx/classic and xxx/compat your basically moving the
notion of branching out of CVS and into the file structure. Clearly
things in the file structure tend to be easier to manage - but at the
same time I think it has a bunch of hidden problems. Test cases in one
example, but what about configurations, property files, etc. At the end
of the day I think that this comes down to better management of CVS tags
and synchronizing builds against tagged content.
But keep in mind that I'm not a CVS expert - I'm just expressing an
observation!
:-)
>
>> Eeek - lots of little things pop up because not all of the
>> implications have been considered.
>
>
> Yeah, that's why it's a proposal. ;-)
>
I understand what your aiming at - just not convinced about the approach ;-)
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release
Plan )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Peter Donald wrote:
>>
>>> On Sat, 1 Feb 2003 01:18, Berin Loritsch wrote:
>>>
>>>>> +1. Maybe we can release put some kind of compat.jar in with the
>>>>> distribution that contains this class?
>>>>
>>>>
>>>>
>>>> I don't think its necessary. That *deprecated* class has been there
>>>> from almost the beginning. If people are still using it, shame on
>>>> them!
>>>>
>>>> It should be safe to remove it after 1.5 years don't you think?
>>>
>>>
>>>
>>>
>>> I would prefer us to maintain compatability in released code.
>>> Especially when there is no real reason to break it.
>>
>>
>>
>> Peter, this is what deprecation is all about, no?
>> Keep the stuff in for others to have time to change, then remove it.
>>
>> Removing deprecated classes between major versions is a safe bet.
>> Between point versions it's a possibility.
>> Between fixes it's an error.
>>
>> I'd suggest the following as a guideline:
>>
>> - deprecating classes results in @deprecated being added
>> - in the next minor point release, they are moved to a
>> deprecated source tree for the component that is compiled
>> *after* the main ones, so that we are sure that /we/ do not
>> rely on those.
>> - in the major releases the classes can be removed with a vote.
>>
>> Thoughts?
>
>
>
> Hi Nicola:
>
> I think the notion of "moving" depreciated classes needs more cooking.
Yes, I'm still experimenting with Cocoon, but I find it *very* interesting.
> Take logkit as an example. There is a src/java and a source/compat.
> You cannot build one with the other.
Ahhh, ok. Yes, this is kinda wierd.
> If on the other hand you were
> talking about moving a class source to a deprecated set of sources - AND
> - the main sources could be built without it - i.e. independently - then
> this would more sense.
Yes, I mean this :-)
> However - in doing this you implicitly complicate you structure and
> while probably not significant in itself, if your looking at automating
> tools for building on a project like Avalon then its a significant
> point. Its significant because it is suggesting that any Avalon project
> could include a src/compat directory that needs to be included in the
> compile targets.
Ant is an automated too :-)
If we use the same dir structure for all projects, we just need a single
build.xml and import it in all the project builds, it's not a problem.
> Taking this further - does the same policy apply to
> test cases?
Good point. What do you think?
> Eeek - lots of little things pop up because not all of the
> implications have been considered.
Yeah, that's why it's a proposal. ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release
Plan )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Berin Loritsch wrote:
> Stephen McConnell wrote:
...
>> I think the notion of "moving" depreciated classes needs more
>> cooking. Take logkit as an example. There is a src/java and a
>> source/compat. You cannot build one with the other. If on the other
>> hand you were talking about moving a class source to a deprecated set
>> of sources - AND - the main sources could be built without it - i.e.
>> independently - then this would more sense.
>
> I can make it happen so that LogKit does not do this, and passes its
> test cases.
Go for it then. +1
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release
Plan )
Posted by Berin Loritsch <bl...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Peter Donald wrote:
>>
>>> On Sat, 1 Feb 2003 01:18, Berin Loritsch wrote:
>>>
>>>>> +1. Maybe we can release put some kind of compat.jar in with the
>>>>> distribution that contains this class?
>>>>
>>>>
>>>>
>>>> I don't think its necessary. That *deprecated* class has been there
>>>> from almost the beginning. If people are still using it, shame on
>>>> them!
>>>>
>>>> It should be safe to remove it after 1.5 years don't you think?
>>>
>>>
>>>
>>>
>>> I would prefer us to maintain compatability in released code.
>>> Especially when there is no real reason to break it.
>>
>>
>>
>> Peter, this is what deprecation is all about, no?
>> Keep the stuff in for others to have time to change, then remove it.
>>
>> Removing deprecated classes between major versions is a safe bet.
>> Between point versions it's a possibility.
>> Between fixes it's an error.
>>
>> I'd suggest the following as a guideline:
>>
>> - deprecating classes results in @deprecated being added
>> - in the next minor point release, they are moved to a
>> deprecated source tree for the component that is compiled
>> *after* the main ones, so that we are sure that /we/ do not
>> rely on those.
>> - in the major releases the classes can be removed with a vote.
>>
>> Thoughts?
>
>
>
> Hi Nicola:
>
> I think the notion of "moving" depreciated classes needs more cooking.
> Take logkit as an example. There is a src/java and a source/compat.
> You cannot build one with the other. If on the other hand you were
> talking about moving a class source to a deprecated set of sources - AND
> - the main sources could be built without it - i.e. independently - then
> this would more sense.
I can make it happen so that LogKit does not do this, and passes its
test cases.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release
Plan )
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Peter Donald wrote:
>
>> On Sat, 1 Feb 2003 01:18, Berin Loritsch wrote:
>>
>>>> +1. Maybe we can release put some kind of compat.jar in with the
>>>> distribution that contains this class?
>>>
>>>
>>> I don't think its necessary. That *deprecated* class has been there
>>> from almost the beginning. If people are still using it, shame on
>>> them!
>>>
>>> It should be safe to remove it after 1.5 years don't you think?
>>
>>
>>
>> I would prefer us to maintain compatability in released code.
>> Especially when there is no real reason to break it.
>
>
> Peter, this is what deprecation is all about, no?
> Keep the stuff in for others to have time to change, then remove it.
>
> Removing deprecated classes between major versions is a safe bet.
> Between point versions it's a possibility.
> Between fixes it's an error.
>
> I'd suggest the following as a guideline:
>
> - deprecating classes results in @deprecated being added
> - in the next minor point release, they are moved to a
> deprecated source tree for the component that is compiled
> *after* the main ones, so that we are sure that /we/ do not
> rely on those.
> - in the major releases the classes can be removed with a vote.
>
> Thoughts?
Hi Nicola:
I think the notion of "moving" depreciated classes needs more cooking.
Take logkit as an example. There is a src/java and a source/compat.
You cannot build one with the other. If on the other hand you were
talking about moving a class source to a deprecated set of sources - AND
- the main sources could be built without it - i.e. independently - then
this would more sense.
However - in doing this you implicitly complicate you structure and
while probably not significant in itself, if your looking at automating
tools for building on a project like Avalon then its a significant
point. Its significant because it is suggesting that any Avalon project
could include a src/compat directory that needs to be included in the
compile targets. Taking this further - does the same policy apply to
test cases? Eeek - lots of little things pop up because not all of the
implications have been considered.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release
Plan )
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Royal wrote:
...
> I'm in agreement on this provided that a major release constitutes X.0
> -> Y.0. This would be consistent with Sun's usage of deprecation, where
> no JDK deprecated classes have been removed since we have only gone from
> 1.0 -> 1.4.
Yes, exactly. I agree :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release Plan )
Posted by Peter Royal <pr...@apache.org>.
On Saturday, February 1, 2003, at 04:26 AM, Nicola Ken Barozzi wrote:
> Removing deprecated classes between major versions is a safe bet.
> Between point versions it's a possibility.
> Between fixes it's an error.
>
> I'd suggest the following as a guideline:
>
> - deprecating classes results in @deprecated being added
> - in the next minor point release, they are moved to a
> deprecated source tree for the component that is compiled
> *after* the main ones, so that we are sure that /we/ do not
> rely on those.
> - in the major releases the classes can be removed with a vote.
>
> Thoughts?
I'm in agreement on this provided that a major release constitutes X.0
-> Y.0. This would be consistent with Sun's usage of deprecation, where
no JDK deprecated classes have been removed since we have only gone
from 1.0 -> 1.4.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
[PROPOSAL] Deprecation policy ( Re: [Proposal] LogKit Release Plan
)
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Donald wrote:
> On Sat, 1 Feb 2003 01:18, Berin Loritsch wrote:
>
>>>+1. Maybe we can release put some kind of compat.jar in with the
>>>distribution that contains this class?
>>
>>I don't think its necessary. That *deprecated* class has been there
>>from almost the beginning. If people are still using it, shame on
>>them!
>>
>>It should be safe to remove it after 1.5 years don't you think?
>
>
> I would prefer us to maintain compatability in released code. Especially when
> there is no real reason to break it.
Peter, this is what deprecation is all about, no?
Keep the stuff in for others to have time to change, then remove it.
Removing deprecated classes between major versions is a safe bet.
Between point versions it's a possibility.
Between fixes it's an error.
I'd suggest the following as a guideline:
- deprecating classes results in @deprecated being added
- in the next minor point release, they are moved to a
deprecated source tree for the component that is compiled
*after* the main ones, so that we are sure that /we/ do not
rely on those.
- in the major releases the classes can be removed with a vote.
Thoughts?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Peter Donald <pe...@realityforge.org>.
On Sat, 1 Feb 2003 01:18, Berin Loritsch wrote:
> > +1. Maybe we can release put some kind of compat.jar in with the
> > distribution that contains this class?
>
> I don't think its necessary. That *deprecated* class has been there
> from almost the beginning. If people are still using it, shame on
> them!
>
> It should be safe to remove it after 1.5 years don't you think?
I would prefer us to maintain compatability in released code. Especially when
there is no real reason to break it.
--
Cheers,
Peter Donald
*---------------------------------------------------------*
| Contrary to popular belief, UNIX is user-friendly. It |
| just happens to be selective on who it makes friendship |
| with. |
| - Richard Cook |
*---------------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Berin Loritsch <bl...@apache.org>.
Peter Royal wrote:
> On Friday, January 31, 2003, at 09:18 AM, Berin Loritsch wrote:
>
>>> +1. Maybe we can release put some kind of compat.jar in with the
>>> distribution that contains this class?
>>
>>
>> I don't think its necessary. That *deprecated* class has been there
>> from almost the beginning. If people are still using it, shame on
>> them!
>>
>> It should be safe to remove it after 1.5 years don't you think?
>
>
> The JDK still has deprecated classes from Java 1.1 ... I'm +1 on a
> 'compat.jar', after its been in there for awhile we can the remove
> permanently.
> -pete
What's your definition of "a while"? We need a plan for removing them.
It's been there for a long while. I have the code ready to completely
remove them, but I haven't committed it yet. I am waiting to here
back from everyone.
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Peter Royal wrote:
> On Friday, January 31, 2003, at 09:18 AM, Berin Loritsch wrote:
>
>>> +1. Maybe we can release put some kind of compat.jar in with the
>>> distribution that contains this class?
>>
>>
>> I don't think its necessary. That *deprecated* class has been there
>> from almost the beginning. If people are still using it, shame on
>> them!
>>
>> It should be safe to remove it after 1.5 years don't you think?
>
>
> The JDK still has deprecated classes from Java 1.1 ... I'm +1 on a
> 'compat.jar', after its been in there for awhile we can the remove
> permanently.
Yes.
In Cocoon I have moved the deprecated classes to a separate dir, so that
I can try to compile all Cocoon without the deprecated classes.
Guess what, surprise surprise!, we are not able to do it! ;-)
Sun has used deprecation as "supported but not preferred", which
somewhat broke the meaning. HEck, why not remopve stuff from 1.1 now,
isn't it time, my sUn? Hmmm, does it still compile? ;-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Peter Royal <pr...@apache.org>.
On Friday, January 31, 2003, at 09:18 AM, Berin Loritsch wrote:
>> +1. Maybe we can release put some kind of compat.jar in with the
>> distribution that contains this class?
>
> I don't think its necessary. That *deprecated* class has been there
> from almost the beginning. If people are still using it, shame on
> them!
>
> It should be safe to remove it after 1.5 years don't you think?
The JDK still has deprecated classes from Java 1.1 ... I'm +1 on a
'compat.jar', after its been in there for awhile we can the remove
permanently.
-pete
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Berin Loritsch <bl...@apache.org>.
Leo Simons wrote:
> Berin Loritsch wrote:
>
>> #1 Remove circular dependency on Framework
>> -------------------------------------------
>> The particular class that forces the dependency is an "Avalon"
>> formatter that can handle the nested exceptions from Avalon.
>> It is a hold-over from when we did a first release after we
>> moved to Jakarta. I think it is relatively safe to remove the
>> class as it merely extends the correct version. It has been
>> deprecated from about the second release.
>>
>> +1 from me.
>
>
> +1. Maybe we can release put some kind of compat.jar in with the
> distribution that contains this class?
I don't think its necessary. That *deprecated* class has been there
from almost the beginning. If people are still using it, shame on
them!
It should be safe to remove it after 1.5 years don't you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org
Re: [Proposal] LogKit Release Plan
Posted by Leo Simons <le...@apache.org>.
Berin Loritsch wrote:
> #1 Remove circular dependency on Framework
> -------------------------------------------
> The particular class that forces the dependency is an "Avalon"
> formatter that can handle the nested exceptions from Avalon.
> It is a hold-over from when we did a first release after we
> moved to Jakarta. I think it is relatively safe to remove the
> class as it merely extends the correct version. It has been
> deprecated from about the second release.
>
> +1 from me.
+1. Maybe we can release put some kind of compat.jar in with the
distribution that contains this class?
> #2 Maven integration for build
> -------------------------------
> The build is very simple, and nothing really major needs to
> be done. LogKit's Ant build isn't problematic, so it is
> ok to leave it alone as well. The question is before or after
> release? If we cannot resolve the issue soon, we will merely
> make it after the release.
put maven in if you want, try it, use ant for building the release.
Don't include the project.xml in the distribution just yet. We can
probably do the next point release using maven beta8.
> #3 Documentation
> -----------------
> LogKit documentation is fairly sparse. We have *something*,
> but nothing that covers all the features and how to set it up.
> The current docs are OK while we make a quick release, but we
> do need to put some attention into those docs soon. LogKit
> hasn't changed much, so there is a good chance the docs will
> be good for a long time. We could release now, and add docs
> as they come in to the web site.
no one ever really felt the itch to work on logkit docs, and no one ever
really asked for them either I think. I do agree there a bit sparse, but
it's okay to release without writing more docs first.
> Aside from a few Status changes, and the resolution of these
> issues, there should be nothing holding back the release of
> LogKit.
+1
- Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org