avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [LOGKIT] dist target failure
Date Sun, 09 Feb 2003 21:25:05 GMT


Berin Loritsch wrote:

> Stephen McConnell wrote:
>
>>
>>
>> Berin Loritsch wrote:
>>
>>> Stephen McConnell wrote:
>>>
>>>>
>>>> Having problems building the dist target for logkit:
>>>>
>>>>   1. javadoc errors due to the fact that the compat sources are not 
>>>> included in the target
>>>
>>>
>>>
>>>
>>> It doesn't prevent you from building the dist.
>>
>>
>>
>>
>> It means that te documentation provided with the release does not 
>> include any of the depricated classes. 
>
>
> Good.  If people don't know about them, they won't use them.


So lets ignore the fact that deprecation is a statement that something 
is GOING AWAY and pretend that this is a statement that something has 
GONE AWAY therefore because is GONE we don't need to tell the user 
anything. Yep - sounds good to me - treat them like idiots and they will 
probably come back for more!

ROTFL

>
>
>>>>   3. javadoc warning under a 1.4 build because of a ?? in a method 
>>>> description
>>>
>>>
>>>
>>>
>>> Again, it does not prevent us from building the dist.
>>
>>
>>
>>
>> True - but is this a satisfactory level of quality for a 
>> distribution? If this was the only issue - I would pass - but I 
>> happen to think that the missing javadoc and manifest issues are 
>> sufficient to require a RC7.
>
>
> It's not like its not already been released like that.  What I don't
> want to see, and what I get the feeling I will see is I make an RC7
> and then there are a few "niggling" more points that you won't budge on.
>
> We have bigger fish to fry, let's catch them.


Go fishing - its the after effect that pissing me off.  
That standard answer is do a 1.2.1 - i.e. "its not my problem because 
I'm in a hurry".
 Is that the approach we are going to take for the entire ACR?

>>
>> You are obviously not leveraging extension management.  Non-inclusion 
>> of a manifest detailing an extension name, version and implementation 
>> version means that users *must* declare the jar in a classpath and 
>> cannot leverage extension mechanisms in containers such a Tomcat, 
>> Merlin, Phoenix, etc.  These declarations are included 
>> across-the-board in the framework, excalibur, sandbox, and 
>> cornerstone jars. Getting this in place in LogKit is fixing an 
>> oversight that is well and truly overdue.
>
>
> What does it *really* buy you?  You are right, I am not leveraging
> extension management. 90% of the people out there won't know what
> it *really* buys them.  The skip it.  Esp. when you have very popular
> IDEs like JBuilder, etc. which do not directly support their generation.


All good reasons why you don't need this.

:-)

>
>>> Is this something that would prevent LogKit from working properly? 
>>
>>
>> It will not prevent logkit from working properly but it does 
>> complicate matters if a user is building jar files that declare 
>> extension depedecies on other jar files.  Without the manifest logkit 
>> cannot participate as a shareable extension and must be explicity 
>> included in a classpath. 
>
>
> All that's hidden by the o.a.a.f.logger.LogEnabled interface anyway.
> It's not that big a deal.  If any component has an explicit dependency
> on LogKit as opposed to Framework, it is broken IMO.


LogKit is a product that can be used independently of the framework 
irrespective of your opinion.  Such an application is NOT broken.  Its 
simply an application using content that we are providing!  Ok, so you 
personally don't see any benefit in doing things that make the life of 
users easier - that's ok - but at least stay away from unfounded 
opinions - after all - we don't want to misslead anyone do we!

Oh well - I guess its a pattern - we stuffed up a earlier release of 
LogKit because we left out some adapters.  We stuffed up an earlier 
release of framework because we left out an entire package.  Gee - we 
can stuff up this release by leaving leaving out the really important 
information about what is changing.  But at least we are consistent!

;-)

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message