Major Description
magma.locals is a file that magma:run reads when starting a Magma web application. It offers a way for the developer to tell Magma to load stuff from unpacked projects instead of loading it from packed jars. This is extremely useful when debugging/writing resource files, like css or javascript.
In fact, it is currently limited to resource folders.
Since now we have an Eclipse plugin that cooperates with Maven inside Eclipse, we have a way to know which dependencies of a web project are present in the workspace and where to locate them on the hard drive, so we could generate magma.locals automatically (eventually with a different name, inside the target folder, so that user additions are possible).
Moreover, since we have now a builder inside Eclipse, we could extend magma.locals to load also classes in target-eclipse/classes if they are present, so that we don't require the user to "clean install" all artifacts when running a debug session from Eclipse.
A few checks should be in place to do this however :
- Do that only if target-eclipse/classes exists, obviously
- Do that only if target-eclipse/classes is more recent than the repository jar file or target/classes
- What to do if the user has his own workspace version of an artifact but a new one is found on the repository? I'd go for the workspace version (only when running from Eclipse?)
(same problems are already there for resources, and resources from magma.locals always take precedence over jar resources, but resources does not usually crash the application, so probably we should care more if adding also classes folders).
Another thing to evaluate is that classes in target-eclipse/classes are not compiled with -XterminateAfterCompile, and this could create some problems to the running instance due to some AspectJ bugs.
(just to name them explicitly, AspectJ is not yet ready for parallel development of aspect libraries. So, closures generated by AspectJ takes progressive numbers relative to the current compiler environment, and it could happen that if two different packages are both independently weaving into a third one, generated closures share the same number and conseguently the same class names, creating conflicts on the running instance. Another error happens when package B depends on package A that has aspect weaving inside package B classes; if package A then REMOVES one of these aspects, package B still refers to it, but the weaver SHOULD find out that the aspect is not there anymore and remove it, instead it complains with an error, requiring package B to be recompiled, making aspects analogous to public interfaces when it comes to binary compatibility.)