check plugin dependencies at compile time

run the target 'checksDependV2'
you can change the parameter maxPluginsToProcess but be carefull with the value.

If you process all the plugins (128), it will probably take more than 1 hour (I never went to the end because I killed the process after an hour).

Fabien

I would like to have a look at the source of your target (more than 1 hour to analyze dependencies between 128 plugins sounds like a bug).

Can you tell me which directory contains the sources of your target?

Regards.

You can find it here:
/JNode-Builder/src/builder/org/jnode/build/dependencies/DependencyChecker.java

But most of the job is done by the classycle library.

Through a script, I specify set of classes and then say what sets should be independants.
From this script, it scans all *.class and check that the sets are really independents.

Maybe we can meet on irc to discuss about it...

Fabien

good idea.
Sebastian

It may also be usefull to check the security at compile time.

It can be done by searching dependencies on SecurityException or any class that inherits from it and walking to the callers and check that they have the right. So, the analysis is at the method level.

To ease the task, it may be better to only warn of dependencies on a SecurityException instead of analysing all method calls.

Fabien

Depending on what should be the outcome of the analysis, it may be better to do the analysis by executing the plugin or so with a special SecurityManager or so that prints out all permission checks.

To figure out which permissions a plugin requires you will otherwise have to step through all possible combinations of method calls, not simply analyze dependencies to SecurityException. (E.g. if class A calls method1 of class B that doesn't throw a SecurityException, but its method2 does, it depends on SecurityException, but will never throw one.)

Another issue is that classes may be loaded dynamically using Class.forName() having the name of the class to be loaded determined at runtime.

Sebastian

I see what you mean. I would like to only check dependencies on SecurityException as heuristic (so not exhaustive) to quickly find potential security problems and warn the user that class A depends of class B that depends on SecturityException.

But this quick approach may be a mean to eliminate classes that will never have security problems. Thus the amount of job to do is reduced for a further analysis (exhaustive search on remaing classes).

PS: where are you with BCEL and dependency checking

Fabien

I have started writing the dependency checker task and noticed that there are unresolved dependencies (i.e. missing classes) for number of plugins. This does not mean these plugins won't work, but probably certain (rarely-used) features of the plugins won't work.

I have made a list that contains the plugins that have unresolved dependencies: List of plugins with unresolved dependencies.

It would be nice if the creators of these plugins could comment if the unresolved dependency is known/intentional or not. (It may also well be that some dependencies are unresolved because the plugin is under development currently.)

Thanks.

Sebastian

The tasks performs the following checks:
a) A warning is issued when a class is defined in more than one package. (The task will stop here and won't proceed to the following checks if any class is defined in two packages, because duplicate classes may lead to false failures in the remaining tests.)
b) A warning is issued when no Jar file is found for a plugin.
c) A warning is issued when a plugin neither exports classes, nor implements an extension point (doesn't apply to fragments).
d) A warning is issued for every class used by a class contained in the plugin which is not covered by the dependencies declared in the plugin descriptor.
e) A warning is issued for every plugin that is referenced in the plugin descriptor, but couldn't be found. (This test leads to many failures currently, because a number of versions are currently incorrect).
f) A warning is issued for every plugin that is referenced in the plugin descriptor, but doesn't contain any classes actually used by the classes contained in the plugin under evaluation.