[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [virgo-dev] Wrong bugzilla entry and other questions

Hi GianMaria,
Regarding the update to Java 8 I can't see any need for a change in Virgo Tools so far. But if needs arise I will contact you asap.
I share your opinion for the Java 7 API level and that Virgo should provide a Java 7 profile. I'm currently at the point that Virgo compiles using Java 8 with source and target set to 1.8. I will check what is required to provide the Java 7 profile this week.
What could be improved on the Virgo Tooling is an integration with build tools like Gradle or Maven. I personally prefer Gradle but Maven is nowadays the most used build tool among the Java community. At work we develop bundles using the Eclipse PDE tooling together with your PDE2Virgo plugin and Virgo Tools. This works most of the time and is nice when you wish to be able to work in a fully IDE integrated manner. But we also maintain a Gradle build script for building our bundles on our CI server. We also looked at Bndtools but we find this to intrusive and the Manifest generation for Spring context XML files is also not working. I know such an integration would mean a huge amount of work so having your PDE2Virgo plugin integrated in the next release as you described it would be a very good starting point.
Gesendet: Mittwoch, 28. Oktober 2015 um 14:08 Uhr
Von: Giamma <gm.romanato@xxxxxxxxx>
An: "“virgo-dev@xxxxxxxxxxx”" <virgo-dev@xxxxxxxxxxx>
Betreff: [virgo-dev] Wrong bugzilla entry and other questions
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.
  1. 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.
  2. 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:
  1. 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
  2. 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
  3. 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.
_______________________________________________ virgo-dev mailing list virgo-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/virgo-dev