Dear all,
sorry for this long email, but there are a number of topics where I would appreciate your help.
== Wrong Bugzilla Entry ==
Some time ago while working on the Server Editor to support multiple selection in the for artefact ordering panel [1] I found out that the Editor was applying changes to the configuration even if the user did not save, and I opened [2] to work on the problem.
Well, it turns out that I was wrong, in the sense that the wrong behaviour existed for the artefact order configuration only (which I already fixed in [1]), while the remaining of the editor is correctly applying changes only on save. Changes are made through commands, and only the command for the artefact order was wrongly implemented, while at first sight I thought it was a problem in the way commands where executed. So [2] should be somehow closed or alternatively, I could modify the title and use it to track the changes I am currently making to the editor to clean-up the code, improve input validators, and properly use NLS.
So what do you think is better? Close [2] (and if so using which state/resolution) or rename it? Sorry for the inconvenience.
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=478709
[2]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=478982
== Upstream projects ==
While testing the Virgo IDE on Ubuntu using GTK3 I found out that the spinners for the publishing time outs (top-right of the first editor page) are rendered too narrow and are therefore unusable in Linux/GTK3. While investigating the problem I realized that this is in reality a WTP defect [3]. Should I just ignore this or should I open a defect on the Virgo Tools and correlate it to the upstream WTP issue?
[3]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=473363
== A couple of questions about Virgo 3.7 ==
If I understood correctly, Daniel is working on adding Java 8 support to Virgo 3.7.
- Will Virgo 3.7 require some changes in the Virgo tools? If so, please le me know as soon as possible as I would like the tools to be available the same day the server will be available.
- Java 8 support is a great feature, but I think it's important that Virgo will be capable of running applications based on Java 7 API level. Virgo 3.6.4 can run with Java 6 or 7 but exports a Java 6 profile. I believe Virgo 3.7 should be capable of running with Java 7 or 8 but should export a Java 7 profile or at least provide this possibility if not the default configuration. Java EE 8 won't be released till the second half of 2016, and most commercial application servers will normally need some months to comply with Java EE 8. To remain a viable open source alternative to commercial servers Virgo should provide a Java 7 profile, otherwise companies that must support also commercial application servers might not be able to use Virgo any more.
== Possible new features for the Virgo Tools ==
Are there any feature or improvement you could suggest for the Virgo tools?
Here are two proposals, the first is more substantial, the second is just cosmetic.
= PDE support =
As already mentioned in this mailing list, a while back I wrote a simple plug-in that allows using PDE bundles and a PDE target platform to develop for Virgo.
I would like to integrate this functionality in the Virgo Tools. I think it could be integrated in this way:
- change the Wizard for creating a Virgo Server so that it offers the possibility to setup a PDE target platform. If that option is selected, the IDE would then read the repository configuration file of the selected Virgo Server and would create a PDE target platform containing the repository folders plus the Virgo plugins folder. In other words when using a vanilla Virgo distribution the target platform would contain directories plugins, repository/ext, repository/usr
- Add a new Wizard under the Virgo group for creating PDE projects that also feature the Virgo bundle nature and an extra nature and builder
- Add some actions here and there for tasks such as migrating projects, resetting the target platform after a repository configuration change
What do you think?
= Shortening project names in the Add/Remove dialog =
While working with OSGi bundles, it's a common practice to name the Eclipse project after the bundle symbolic name. This may result in long project names and I some times find annoying that the dialog used for adding/removing bundles to the server opens a bit too narrow and the right most part of a project name is not visible so that I always have to resize the dialog. Apparently I cannot change the dialog size because the dialog is provided by WTP. I then tried contributing a label decorator that would shrink project names the same way logging libraries shorten class names, for example "org.eclipse.virgo.ide.core" could become "o.e.v.ide.core". The label decorator is working as expected in the WTP dialog, but the WTP dialog code checks whether the project name and the label are equal and if not it appends the full project name to the label in brackets, e.g. "o.e.v.ide.core (org.eclipse.virgo.ide.core)". While this partially invalidates the change, I still find it easier to identify my bundles because the rightmost part of the symbolic name now appears in the dialog without requiring a resize. Would it be OK for you if I added such a feature, turned off by default, and a preference page to activate it? Alternatively I could try to contribute a patch to WTP to enlarge the dialog size. After all, that code seems almost 10 years old and these days screens are much wider.
