[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[virgo-dev] Virgo Tools and Server Editor
- From: Giamma <gm.romanato@xxxxxxxxx>
- Date: Fri, 25 Sep 2015 12:17:22 +0000
- Delivered-to: email@example.com
first of all thank you everyone for the warm welcome.
I started having a look at the Virgo Tools code base and I have a fewÂ questions, maybe some one can give an answer or point me to some documentation.
First question is about the header Javadoc comment that is found at the
beginning of each source file. I believe there must be some
documentation on the Ecilpse site about it and some guide lines but I
could not find it with google. Can anyone point me to the documentation?
Second questionÂ isÂ about formatting. Looks like the Virgo IDE source code repository contains JDT preference files which enable automatic formatting as a save action. But not all sources are formatted according to that preferences, which means that even a trivial change may re-flow the whole text and make history unreadable. So do you mind if I disable the auto format save action?
Third, about the Server form editor. I found what I think is an unexpected behaviour.
Yesterday I started looking at the artefact ordering section to enable multi-selection and I found out that whenever the user makes a change, the editor enters dirty state and the change is immediately applied to the server configuration. If the user closes the editor without saving, the change is not rolled back. I think the editor should rather record changes and apply them all only when the user saves. The current behaviour is confusing for the end user. So, unless someone can explain a good reason for this choice, I'll try to make it more consistent with other Eclipse editors.
I'd like to use feature branches (git-flow like) for features and bugfixes, unless the changes are trivial. Is it ok with you?
Am I correct to assume that whatever change should be tracked by a bugzilla entry? Is the "ENHANCEMENT" severity the field to be used to denote that the entry is not for a fix but rather a new feature/requirement implementation?