Hi all, and especially Mark S.--in case I've not done it publicly enough yet, many thanks to Mark for picking up where I had left off with the privilizer/weaver code. I think the two of us (others? :D) would like to reach a point at which the library is usable, so I submit the following talking points:
Weaver#weave(): Currently there are separate methods for weaving a class vs. a method. I think it would be sufficient and cleaner to have a class weaving method only; having provided its "interests," the Weaver can presumably figure out what to do with a class that has been determined to match. Next, it feels a little odd to use a loaded Class instance to represent a class intended for modification. Should we just use classname here? Weaver#getInterest(): Rather than providing List<Class<? extends Annotation>>, I wonder whether it would be more future-proof for this method (pluralized?) to return Map<Class<? extends Annotation>, ElementType> to say not only which Annotation types it is interested in, but where they are expected to be found. This could work comfortably with the type of search registration APIs we've discussed for [classscan] in the future. Weaver#configure(): This method supplies a target directory where classes are to be found. Perhaps too optimistically, I envision a future that could include a [weaver] ClassLoader to apply our advice at run, rather than build, time. Does anyone have any relevant experience that would guide us in providing the most flexible API to permit weaving of classfiles whether on the filesystem or otherwise? Is it going too far to pull in [vfs] v2-core as a dependency? Thanks, Matt
