The model will track where information originally came from, so when an edit happens it will be made at the location the data came from. The is possible because Sapphire models are views on underlying data, so a model element for say servlet mapping would wrap either a XML DOM element from descriptor parse or the JDT AST node for the annotation.
When new content is added, it's destination will be based on policy that we will need to develop. For instance, if descriptor exists new content can be sent to the descriptor, otherwise it can go to annotations. We can also come up with preferences to control desired destination.
Eventually, we may add some actions to help the user in moving declarations from one system to another.
Senior Development Manager
Eclipse Tools Group
A few questions about the editor...
From the description section:
would bring in information from the module's XML configuration file
as well as the relevant annotations
into a unified view. A user working with the editor will not
necessarily know what flavor of configuration
is being edited.
How will the configuration output be determined when being edited in
the unified view? Does this imply that the editor will continue
updating a configuration based on where that config was read? If
so, what is the granularity? What if the configuration is mixed
between annotations and XML? Would there be some sort of user
defined preferences to determine where edits will take place by
default (when there is no existing metadata to go by or the config
On 4/22/2011 8:38 PM, Konstantin Komissarchik wrote:
wtp-dev mailing list
Attached is a draft proposal for Java EE
Configuration Editors project that I mentioned on this list
before EclipseCon. Please review and comment. I have kept the
document brief and to the point. If anything is unclear,
please ask for more detail.
I am looking for some +1s from WTP PMC and
Chuck (as Java EE Tools lead) before sending this over to EMO
to start the official project creation process.