anchor.diff:  
   === Limitations of jtrag/jtwfg
   
  -* At the moment jtrag/jtwfg support only simple, synchronous dependencies.
  -* jtrag doesn't fully encapsulate jtwfg at the moment. Therefore you need to program using the jtrag *and* the https://github.com/Petikoch/jtwfg[jtwfg] API and understand both of them.
  -* The algorithms are not yet tuned and work more or less in a "brute force" manner. Please create a github issue if you have zillions of tasks/resources and run into performance / memory issues.
  +* At the moment jtrag/jtwfg support only simple, synchronous dependencies in graphs.
  +* jtrag doesn't fully encapsulate jtwfg (1.0.0). Therefore you need to program using the jtrag *and* the https://github.com/Petikoch/jtwfg[jtwfg] API and understand both of them.
  +* The algorithms are not yet tuned and work more or less in a "brute force" manner. Please create a github issue if you have zillions of tasks/resources and run into performance/memory issues.
   
   == Requirements
   
  
positive.code: 
  == My motivation to create jtrag
  
  Any "task resource assignment graph" cycle detection problem can be used with a simple "task wait for graph" model:
  Just use tasks for resources.
  But: A "task resource assignment graph" API is more intuitive to use *if* you have tasks *and* resources in your domain model.
  Therefore jtrag is a valid extension to https://github.com/Petikoch/jtwfg[jtwfg].
  
  Best regards,
  
  
negative.code: 
  == Introduction
  
  *jtrag* is is a small java library on top of https://github.com/Petikoch/jtwfg[jtwfg].
  It adds a "task resource assignment graph" API to the "task wait for graph" API of https://github.com/Petikoch/jtwfg[jtwfg].
  
  The typical use case for someone is having some kind of own "execution engine" implementation
  (local, distributed, grid...) with some kind of tasks and resources in it, with optional dependencies between the tasks and resources.
  