[developer][eclipse] Revamp developer tools in eclipse plugin
-------------------------------------------------------------
Key: LABS-400
URL: https://issues.apache.org/jira/browse/LABS-400
Project: Labs
Issue Type: New Feature
Components: Magma
Affects Versions: Current
Reporter: Simone Gianni
Assignee: Simone Gianni
Fix For: Current
Developer tools are the first Magma fragment that has been created. They are
currently a small set of web based information panels.
Now that we have an Eclipse plugin for Magma, it would be nice to see more and
better developer tools for Magma inside Eclipse.
Main needs while developing in Magma are :
- Understand the current configuration
... Which packages/versions are being used (analysis of classpath entries)
... Which configuration files are being used (analysis of classpath resources)
... The complete list of configuration directives
... Current user and mode
- The complete URI space
- Understand which file, and following which "path" (similar to a stack trace),
is generating a specific part of a page
- Track environment interactions :
... read and write to session/cookies etc..
... Database interactions
... Email interactions
... (an extensible system would be great :D )
- Track log elements
- Track internationalization issues
... Missing keys for a specified language
... Which context and which key to use for a specified string
These functionalities are conceptually split in two different sets. Generic
ones (apply to the whole running Magma instance) and page specific ones.
The first category can be obtained quite simply by calling specific URLs on a
running instance, and obtaining some form (XML/Json/even HTML) dumps of data.
Current developer implementation already offer some data, which should be
reviewed and adapted to recent changes in Magma. This data should also be
enriched enough to help the Eclipse plugin track the originating files and
eventually line numbers.
Offering these informations via JMX is a possible way to expose them as well.
The second category is a mix of gathering data during page rendering,
annotating the page so that those informations can be retrieved and offering a
retrieve system. Again, data should be rich enough to help Eclipse track down
single files and line numbers.
Gathering data is easy using a tracing aspect. Two different tracing systems
should be in place :
- One system should track "global events", like access to
session/cookies/request, database stuff, emails etc..
- Another system should track single output events, and annotate them properly.
Global events tracing will place events in a list and give each an ID, save the
list with a "page ID", and annotate the output with that page ID for later
retrival.
A similar mechanism will be used to save informations about single output
events, except that these events will be more a tree than a list. In fact,
calling a certain page will trigger output from a template, which will
aggregate a number of components, that in turn will delegate to other
components or producers, which may use files (like velocity templates). So,
when looking at a box in the page resulting from a velocity template, all this
trace should be present.
(If creating and managing a tree of identifier is too complex, then it can be
handled on the server side. That is, the client will always require
informations about a node, and the server will know that the given node is
child of another one and so on. Moving this knowledge to the server makes the
output annotation flat, instead of having a structured annotation system).
To annotate the output, XML/HTML comments are the only way that will preserve
page integrity. Magma will inject comments inside the resulting HTML containing
an ID to retrieve who is sending to output that part, and in which context.
Using progressive IDs for both tracing systems could help to integrate the two
different tracings and present the user a single timeline of events.
To give enough informations so that Eclipse can find the originating file, we
will have to use Maven Eclipse resolution of packages. In fact, using
URLClassLoader specific methods, it's possible to find from which jar a given
resource (.class file, or anything else) is coming. Given the presence in that
jar file of the pom.xml, or using Maven naming conventions, it is possible to
extract a Maven artifact key (groupid, artifactid, version), resolve it in
Eclipse to obtain a JAR, a source folder or a dependant project, and then
search the file there.
If such a resolution is not possible (for example, the file is being loaded
from a "magma.locals" folder, so not from a maven jar) complete path of the
resource will be given, so that inside Eclipse it will be possible to resolve
it to a project folder in the workspace, or open directly the file outside the
workspace.
--
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
