Re: Re: CVS update: MODIFIED: . ...

Svatopluk Dedic wrote:

> Hi, Petre,
>
> Petr Jiricka napsal(a):
> [snip]
>
>>
>> While I agree that declaring an implementation dependency is a better 
>> solution than declaring all classes public, I object to the general 
>> non-cooperative tone of this message. If you now agree with Svata, 
>> why didn't you object to IN 15163? Joe used approved internal Sun 
>> process to communicate the requested change (and we are paid by Sun 
>> to use these communication channels, right?), so you could have 
>> objected then.
>>
> Oh; so then cooperativeness is limited to SUN employees only, since we 
> (non-SUN persons) cannot listen to the internal channels, obviously, 
> but we ARE affected by such secretly-approved changes since we share 
> the codebase.
> I (or other non-SUN people) obviously could not read IN 15163, so it 
> does not really matter for me whether Joe used SUN's internal policies 
> or not and whether Vita listens to INF or not, sorry. 

I did not mean to say that the non-Sun community should be excluded from 
this, but that for Sun employees, requirements from other Sun groups 
should have high priority. That's why there are internal communication 
channels.

I apologize to Vita for some comments in my previous message, because as 
Martin Ryzl pointed out to me, Vita did not have time to react to Joe's 
integration notice (IN), as Joe did not wait for comments with his 
integration. Sorry, Vita.

Still, I believe Joe's commit was not *that* unreasonable - it did not 
really hurt anyone, while helping Joe accomplish his task. Especially 
since Joe stressed in his commit log that this is a temporary 
workaround. Rolling back changes is an extreme reaction, which did not 
need to be employed in this case.

>
>
> I wouldn't mind if such change occured in a SUN-private branch, but 
> prj40_prototype is the only branch open for new Projects development 
> and shared by both SUN and the community.
>
>> Also, I disagree that using implementation dependency qualifies as 
>> temporary solution. This document:
>>
>> http://openide.netbeans.org/unbranded-source/browse/~checkout~/openide/api/doc/org/openide/doc-files/classpath.html?rev=1.13.6.1&content-type=text/html
>> states clearly that implementation dependency is the correct way to 
>> express a "Friend API" dependency. An API that has been used by our 
>> colleagues at Sun for several IDE releases, definitely qualifies as 
>> "friend" at least, doesn't it?
>>
> IMHO it does; although the necessity to update the dependant's 
> manifest each time the provider's impl version changes makes it 
> somewhat troublesome. 

I agree, especially since the impl version changes automatically in 
every build. We may need to do something about this.

Petr

>
>
> -Svata
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>