yes, I totally agree. In fact a while back, I originally wrote compilewithwalls on the ant-contrib project which does those kind of tricks at compiletime. Problem was it was really not clean.
I wrote a new task on ant-contrib project now called verifydesign which uses bcel. It does have limitations like when someone depends on public static final String CONSTANT and are not supposed too, I can't tell with bcel as that info is lost. This I believe is the only exceptional case though. Other than that, I think I find all other violations of unallowed dependencies. As far as checking after the compile, we use automated builds at my company and if the autobuild fails, the jar simply isn't released and everyone gets mail that the build is down, so you can see, it "can" work depending on the environment/atmosphere. Also, I could program into the verifydesign task to blow away the jar on failure so when people run the build, the jar appears and dissappears if failed(this may be a very good idea to prevent what you were talking about). One last thing I have though about is producing a picture of the package design based on the design file. thanks for the ideas. thanks, dean ----- Original Message ----- From: "Kees Jan Koster" <[EMAIL PROTECTED]> To: "BCEL Users List" <[email protected]> Sent: Saturday, January 15, 2005 9:32 AM Subject: Re: newb: How to determine package dependencies from one jar? > Dear Dean, > > > Actually, I have seen Jdepend before. It does metrics from what I > > understand. > > > Yes, it is rather finer grained than you suggest you need. From what you > tell me, I think your project would benefit from such analysis, even if it > won't generate warnings directly. > > You are trying to find circular dependencies between packages in your > project. Right? > > The root of this issue is the fact that all source code is built in one > huge blob, rather than as individual packages. EDI's such as Eclipse are > very helpful by ignoring all package borders when compiling code. > > You are trying to analyse the compiled code for dependencies. That is one > way of solving it. Trouble is, your code is already compiled and probably > the test cases run, so when you wave the dependency violation to your > teammates, there is a decent chance that they will say "sure, we'll fix it > later." Post-compilation checks are simply too late in the process to make > people fix this. > > If you use Ant to build the code, you can split the compilation target up > into one target for each package. You then limit the class path for each > compilation to the compilation units that it may legally depend on. That > way, if your code has illegal dependencies, it will simply > not compile. > > Perhaps you could consider writing your own PMD/findbugs/checkstyle rules > to alert programmers to the problems you are seeing. > > As you can tell, I would be reluctant to use BCEL to dig around JAR files > for this particular purpose. YMMV > > Kees Jan > > --------------------------------------------------------------------- > 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]
