labs-labs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Gianni (JIRA)" <j...@apache.org>
Subject [jira] Created: (LABS-400) [developer][eclipse] Revamp developer tools in eclipse plugin
Date Wed, 05 Aug 2009 01:38:14 GMT
[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-unsubscribe@labs.apache.org
For additional commands, e-mail: labs-help@labs.apache.org


Mime
View raw message