Sorry for being short on the good details :) First of all I really dont care about the technology for the actual byte code manipulation. I'd really not even like to get into that stuff; I have too much other cool stuff to do.
While working on the initial parallel solution in maven I used a lot of what I call "thread mines"; objects that keep track of which threads have been in contact with a particular object. There are several distinct access patterns that can be automatically qualified as "incorrect". At some point in time I even created a small github project that can be seen at https://github.com/krosenvold/failfast-collections The typical access pattern we have in maven core is something like this: A lot of objects get instantiated by maven core Thread pool starts executing in parallel, all objects are effectively handed off to the single thread that gets "that" module. After this point in time, it is illegal for any other thread than the "owning" thread to touch the model, including reads, since we lazy-init. This and other checks can to some extent be automated. Kristian 2015-01-05 15:51 GMT+01:00 Igor Fedorenko <i...@ifedorenko.com>: > What kind of changes to the model do you expect? Can you give some > pointers that explain verification logic you have in mind? > > -- > Regards, > Igor > > > On 2015-01-05 9:11, Kristian Rosenvold wrote: >> >> I'd be interested in using cglib to generate a full set of subclasses >> for the entire maven model. These subclasses could assert stuff about >> "proper" thread correctness wrt the current "correct" threading model >> for maven. This would be capable of blowing up /immediately/ a plugin >> violates the contract and could be used to make a "formal" >> verficiation that the entire set of plugins performs to specification >> in a given build. >> >> I could potentially see this added as a "diagnostic" mode to core. >> >> I know how to create the verification logic, but I am totally blank >> when it comes to cglib. Is there anyone who can help me a bit ? Maybe >> even someone who could code the actual cglib bit :) ? >> >> Kristian >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
