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