[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Virgo Tools and Server Editor

Hi GianMaria,

Markus already answered the first question so Iâll try to answer the remaining questions.

> 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?

We've got a Code Style we try to follow. You can find more in the Wiki: http://wiki.eclipse.org/Virgo/Committers/Coding
If the actual formatting in the repository does not match the rules we defined in the Eclipse settings mentioned in the Wiki I propose we
fix this mismatch as soon as possible in a separate commit.
Once the code in the repository is in line with the defined settings I think the auto format save action is a good thing.
Does this make sense to you?

> 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.

It would be great to see more consistency with other Eclipse editors. Please give it a try.

> I'd like to use feature branches (git-flow like) for features and bugfixes, unless the changes are trivial. Is it ok with you?

Fine with me.

> 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?

Yes and yes.

Itâs great to see the tooling getâs more attention again.