labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Gianni (JIRA)" <>
Subject [jira] Created: (LABS-412) [eclipse] Generate magma.locals on the fly based on Maven workspace resolution.
Date Sun, 16 Aug 2009 13:58:14 GMT
[eclipse] Generate magma.locals on the fly based on Maven workspace resolution.

                 Key: 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:
For additional commands, e-mail:

View raw message