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

Petr Jiricka <[email protected]> Fri, 12 Sep 2003 10:59:22 +0200
Newsgroups gmane.comp.java.netbeans.modules.projects.devel
Message-ID <[email protected]>
Vitezslav Stejskal wrote:

> Hi All,
>
> Svata is absolutely correct. Let me remind you all that:
>
> - the APIs are in high resistant mode - 
> http://projects.netbeans.org/openissues/incompatible_issues.html
> - this was huge and unwanted API change
> - this wasn't discussed on aliases (but even internally with projects 
> developers)
>
> We _intentionally_ restricted access to all classes in java module 
> since they were never meant to be a public and maintained API of java 
> module. We are willing to replace all neccessary contracts by some 
> other way in new java project APIs. Please, ask your requirements for 
> these contracts. Some of them can be probably satisfied even now, some 
> of them probably not, but we don't know how modules were using classes 
> from old java module and what all they really need. Help us to find 
> out all these usages by asking reguirements.
>
> The commit was rolled back already. If there is an urgent need for 
> temporary solution I would suggest to declare implementation 
> dependency on java module. Using implementation dependencies allows 
> you to access internal classes of module you depend on, but remember 
> that such dependencies can easily get broken when changes are done 
> that module. It's the responsibility of maintainers of dependent 
> module to keep their module in sync or better to remove the 
> implementation dependency as soon as possible. Use the implementation 
> dependency only as _temporary_ solution.


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.

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?

Petr

>
>
> -vita
>
> Svatopluk Dedic wrote:
>
>> [email protected] napsal(a):
>>
>>>   User: jwarzecha
>>>   Date: 03/09/08 17:13:02
>>>
>>>   Modified:    .        Tag: prj40_prototype manifest.mf
>>>   Log:
>>>   IN=15163 - Change manifest, make all packages public
>>>              (temp workaround so ejb editor works in SunOne Studio)
>>>   
>>
>>
>> Did I see an announcement, or a discussion concerning this change on 
>> nbdev@ or dev@projects ? I don't think so.
>>
>> Writing "IN=15163", that presumably points at some SUN internal 
>> resource does not help too much.
>>
>> -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]
>