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

Vitezslav Stejskal wrote:

> Hi Petr,
>
> I am sorry if my mail sounded non-cooperative. I understand that Joe 
> was in an urgent need to solve this somehow. But still I think that 
> removing the public-packages declaration in someone else's module is 
> unacceptable. This is in fact the API change in that module and will 
> cause anybody looking at this module to think that everything in the 
> module is public and can be used _and_ that it is supported. So, doing 
> that Joe exposed internal stuff of java module to everybody instead of 
> exposing it just to himself. I think the implementation dependencies 
> exist in our module system exactly to help in this situation. 


Ok, understood and point taken :)

BTW, if people are interested in having a better support for unstable 
"friend" APIs in the IDE module system, check issue 
http://www.netbeans.org/issues/show_bug.cgi?id=36064 that Tonda N. filed.

Petr

>
>
> So, sorry again for my unfriendly tone, but rollback was the only 
> thing we could do at this situation.
>
> -vita
>
> Petr Jiricka wrote:
>
>> 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]
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>