[
https://issues.apache.org/jira/browse/LABS-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
jan iversen closed LABS-412.
----------------------------
Resolution: Won't Fix
outdated and closed, if not correct please reopen.
> [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: Next
> Reporter: Simone Gianni
> Fix For: Next
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
