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

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.

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]
>
>