Re: [Springframework-developer] Removing cyclic dependencies in sub-packages

[<jue...@we...>]

This could be as simple as collecting the public API in a readme: =
Package names for entirely public packages, individual class names for =
more specific cases. This should not be too hard to do.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of rod...@in...
Sent: Monday, March 29, 2004 3:01 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Removing cyclic dependencies in
sub-packages


>Strictly speaking, the AopUtils move is not backward-
compatible, but I'm not keen on keeping a deprecated class in=20
the old place. As we're talking about an internal class here,=20
I guess this won't break any existing application. This=20
raises the following issue: What exactly constitutes our=20
public API? We will occasionally face the need to revise=20
internals, even for point releases...

I'm happy with this move. The only legitimate reason people=20
might use it is to check whether a particular instance is an=20
AOP proxy in a test case (rather than application code).

I think we should publish a list of the public API contracts=20
that won't change. With the AOP stuff, I've made some of the=20
classes package-visible, but that's often impossible.

Axis did this way back and I thought it was a good idea.=20

Regards,
Rod


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer