[eclipse] Generate magma.locals on the fly based on Maven workspace resolution.
-------------------------------------------------------------------------------
Key: LABS-412
URL: https://issues.apache.org/jira/browse/LABS-412
Project: Labs
Issue Type: New Feature
Components: Magma
Affects Versions: Current
Reporter: Simone Gianni
Fix For: Current
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.)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
For additional commands, e-mail: labs-h...@labs.apache.org
