Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Scout/NewAndNoteworthy/3.9"

(New SDK Features)
(Docx4j Integration)
(41 intermediate revisions by 3 users not shown)
Line 1: Line 1:
This page shows what you need to know about the new Eclipse Scout 3.9 release shipped with Eclipse Kepler.
+
This page shows what you need to know about the new Eclipse Scout 3.9 release shipped with Eclipse Kepler.  
  
== General ==
+
== General ==
=== Scout Sources moved to GIT ===
+
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=384960 Bug 384960]
+
  
For Kepler, Scout has moved to GIT: [http://git.eclipse.org/c/scout/ http://git.eclipse.org/c/scout/].
+
=== Scout Sources moved to GIT ===
  
For more information see
+
{{Bug|384960}}
[http://wiki.eclipse.org/Scout/Contribution#Getting_the_Scout_Sources Getting_the_Scout_Sources].
+
  
=== Scout EPP Changes ===
+
For Kepler, Scout has moved to GIT: [http://git.eclipse.org/c/scout/ http://git.eclipse.org/c/scout/].
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=390431 Bug 390431]
+
  
Egit features added to EPP
+
For more information see [http://wiki.eclipse.org/Scout/Contribution#Getting_the_Scout_Sources Getting_the_Scout_Sources].
  
CVS features removed from EPP. If CVS is needed, it has to be installed manually.
+
=== Scout EPP Changes  ===
  
== New Runtime Features ==
+
{{Bug|390431}}
  
== New SDK Features ==
+
Egit features added to EPP
  
=== Default Super Classes are Customizable ===
+
CVS features removed from EPP. If CVS is needed, it has to be installed manually.  
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=395006 Bug 395006] and [https://bugs.eclipse.org/bugs/show_bug.cgi?id=397268 Bug 397268]
+
  
In Scout 3.8 when creating a new object using a wizard you already have the possibility to choose from a list of possible super classes. But the super class selected by default is always the same. So if you e.g. have defined a project specific template for forms called 'AbstractMyProjectForm' you always have to remember to change the selected super class when creating forms.
+
=== New testing features ===
  
With Scout 3.9 you now have the possibility to configure the super classes that should be used by default for each Scout project independently: Go to Window -> Preferences -> Scout -> Default Super Classes. There you can specify the default super class to use for each object type and Scout project.
+
{{Bug|376459}}
  
This configuration is also considered if you don't explicitly have the possibility to choose a super class in the wizards: E.g. when creating a new Form by default there are also 'Cancel' and 'OK' buttons created. If you now modify the default super class for OK buttons, this is automatically used by the new Form wizard as well.
+
Two features for testing have been added to the updatesite:
 +
* Eclipse Scout Runtime Testing
 +
* Eclipse Scout Runtime RAP Testing
 +
* Eclipse Scout SDK Testing
  
This mechanism also respects the new extensible Scout objects defined in 'org.eclipse.scout.rt.extension.client': If your project has this dependency, the Scout SDK prefers those objects over the standard ones (unless you have modified the defaults).
+
These features contains plugins that provide support (Utility classes, Test Runner...) in order to test scout applications.
  
The settings are stored in the project preferences so that you can share them with your team using e.g. a team provider like SVN, CVS or Git.
+
== New Runtime Features  ==
  
 +
=== Form Field Filter for FormData Import  ===
  
=== Variable Local RAP Target Location ===
+
{{Bug|392409}}
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=394751 Bug 394751]
+
  
 +
Besides a IPropertyFilter the FormData import (method importFormData() in AbstractForm) now also allows to specify a IFormFieldFilter. With this overload it is now not only possible to influence which properties that are imported, but also which form fields that should be filled. A default implementation is available that allows to exclude some fields from the import (org.eclipse.scout.rt.client.ui.form.fields.ExcludeFormFieldFilter).
  
=== More Flexible Project Structure ===
+
=== Multiple Swing Scout features in a single Eclipse application  ===
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=394125 Bug 394125]
+
  
 +
{{Bug|396252}}
  
=== Improvements for the NLS Field ===
+
The extension point org.eclipse.scout.rt.ui.swing.appextensions allows running multiple swing Scout features in a single Eclipse application.
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=380507 Bug 380507]
+
 
 +
Example: Create multiple applications extensions (e.g.):
 +
 
 +
<source lang="java">
 +
public class App1 extends AbstractSwingApplicationExtension {
 +
 +
  public App1() {
 +
    super("App1");
 +
  }
 +
 
 +
  @Override
 +
  protected IClientSession createClientSession(UserAgent userAgent) {
 +
    IClientSessionRegistryService service = SERVICES.getService(IClientSessionRegistryService.class);
 +
    return service.newClientSession(ClientSession.class, userAgent);
 +
  }
 +
 
 +
  @Override
 +
  protected ISwingEnvironment createEnvironment() {
 +
    return new SwingEnvironment();
 +
  }
 +
}
 +
</source>
 +
 
 +
Register ExtensibleSwingApplication as application and the previously created applications extensions
 +
 
 +
<source lang="xml">
 +
<?xml version="1.0" encoding="UTF-8"?>
 +
<plugin>
 +
  <extension id="app" name="Application" point="org.eclipse.core.runtime.applications">
 +
    <application>
 +
      <run class="org.eclipse.scout.rt.ui.swing.ExtensibleSwingApplication"/>
 +
    </application>
 +
  </extension>
 +
...
 +
<extension
 +
      point="org.eclipse.scout.rt.ui.swing.appextensions">
 +
    <swingApplicationExtension
 +
          class="test.helloworld.ui.swing.App1"
 +
          ranking="1">
 +
    </swingApplicationExtension>
 +
</extension>
 +
...
 +
</source>
 +
 
 +
=== SWT: Visual Marker in editable cell  ===
 +
 
 +
{{Bug|395673}} A marker icon is now displayed in an editable cell in an SWT table (similar to the swing table).
 +
 
 +
The icon can be changed by setting the extension org.eclipse.scout.rt.ui.swt.scouticons for the cell_editable icon.
 +
 
 +
 
 +
=== JUnit test suite for Scout RT ===
 +
With {{Bug|402301}} and {{Bug|402304}} a JUnit testing suite was started in the Eclipse Git Repositories. The tests are executed as part of the Maven+Tycho build.
 +
 
 +
JUnit tests classes requiring an UI layer (because they use AWT or SWT classes), are identified with a special suffix <code>UiTest</code> instead of <code>Test</code>. This allows to ignore these tests (maven profile <code>skip-uitest</code>, active by default) to be able to build on backend-servers that do not provide an UI layer. In order to execute the <code>UiTest</code> you might consider the maven profile <code>include-uitest</code>.
 +
 
 +
Further reading about testing can be found here: {{ScoutLink|Concepts|Test|Eclipse Scout Testing}}
 +
 
 +
== New SDK Features  ==
 +
 
 +
=== Scout Explorer Changes  ===
 +
 
 +
[[Image:Org.eclipse.scout.3.9.newAndNote7.png|thumb|right|350px|Scout Explorer View]]
 +
 
 +
{{Bug|394132}}
 +
 
 +
The Scout Explorer View shows all Scout Bundles and provides folders below them to manage the typical objects for a bundle type.
 +
 
 +
The detection and layout of this bundle entries (the green, orange and blue nodes) have been redesigned for Scout 3.9:
 +
#The layout of the tree is completely based on the dependencies of your bundles. As the dependencies between bundles build up a graph, the Scout Explorer may show a single bundle at various places in the tree considering all paths in the actual dependency graph.
 +
#As a consequence, each bundle can contain several bundles of the same type (breaking the trinity ''client-shared-server'') for a more flexible layout.
 +
#The tree also shows Scout bundles that are in your target platform (binary) and are only referenced by your workspace bundles.
 +
#Fragments are shown as well
 +
#There is a context menu ''Add Scout Bundles...'' on the bundle nodes that allows you to create sub modules or new bundles within your existing project.
 +
#We added a Site Menu that allows you to influence which and how the Scout bundles should be displayed.
 +
#You can now group Scout bundles together in Scout Working Sets. This allows you to group the Scout Explorer as you like and the Working Sets can also be used e.g. in the Eclipse Search.
 +
 
 +
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[[Image:Org.eclipse.scout.3.9.newAndNote8.png|450px|Scout Explorer Options]]
 +
 
 +
=== Support for Scout Mobile UI  ===
 +
 
 +
{{Bug|394127}} and {{Bug|378151}}
 +
 
 +
Scout 3.9 comes with an enhanced web user interface (RAP) that is optimized for smartphone (mobile) and tablet devices.
 +
 
 +
By creating a new Scout Project using the Scout SDK you automatically get the mobile support when choosing to create a RAP user interface bundle. In the default setup you get four servlets prepared:
 +
 
 +
#''web'' for normal personal computers or laptops
 +
#''mobile'' for smartphone devices
 +
#''tablet'' for tablet devices
 +
#root entrypoint for all browsers that will autodetect your device and dispatch to the best of the servlets above.
 +
 
 +
Furthermore you get a client.mobile bundle prepared that includes all modifications to your client that should apply to mobile and tablet devices only (e.g. if you want to hide or replace some features).
 +
 
 +
&nbsp;
 +
 
 +
=== Default Super Classes are Customizable  ===
 +
 
 +
[[Image:Org.eclipse.scout.3.9.newAndNote1.png|thumb|right|350px|Default Super Classes Preference Page]]
 +
 
 +
{{Bug|395006}} and {{Bug|397268}}
 +
 
 +
In Scout 3.8 when creating a new object using a wizard you already have the possibility to choose from a list of possible super classes. But the super class selected by default is always the same. So if you e.g. have defined a project specific template for forms called 'AbstractMyProjectForm' you always have to remember to change the selected super class when creating forms.
 +
 
 +
With Scout 3.9 you now have the possibility to configure the super classes that should be used by default for each Scout project independently: Go to Window -&gt; Preferences -&gt; Scout -&gt; Default Super Classes. There you can specify the default super class to use for each object type and Scout project.
 +
 
 +
This configuration is also considered if you don't explicitly have the possibility to choose a super class in the wizards: E.g. when creating a new Form by default there are also 'Cancel' and 'OK' buttons created. If you now modify the default super class for OK buttons, this is automatically used by the new Form wizard as well.
 +
 
 +
This mechanism also respects the new extensible Scout objects defined in 'org.eclipse.scout.rt.extension.client': If your project has this dependency, the Scout SDK prefers those objects over the standard ones (unless you have modified the defaults).
 +
 
 +
The settings are stored in the project preferences so that you can share them with your team using e.g. a team provider like SVN, CVS or Git.
 +
 
 +
&nbsp;
 +
 
 +
&nbsp;
 +
 
 +
&nbsp;
 +
 
 +
=== Variable Local RAP Target Location  ===
 +
 
 +
[[Image:Org.eclipse.scout.3.9.newAndNote3.png|thumb|right|300px|Specify the RAP Target Location]]
 +
 
 +
{{Bug|394751}}
 +
 
 +
[[Image:Org.eclipse.scout.3.9.newAndNote2.png|left|300px|Modify the value of the scout_rap_target variable]]
 +
 
 +
If you are using a local RAP target (instead of a P2 update site) you may want to share your target definition with other developers using a team provider like SVN, CVS or Git. But there may be differences in the local path pointing to the RAP target (because you have a different setup or operating system). Or you may not yet have a local RAP target at all. This makes it hard to use a target definition in a team.
 +
 
 +
In Scout 3.9 you now have a new Eclipse environment variable called 'scout_rap_target'. So instead of using the local path directly in the target definition you can use the ${scout_rap_target} variable as a palceholder and each developer can then point this variable to the path where to find the plugins locally. The value of the 'scout_rap_target' variable is stored in the workspace and can therefore be different for each instance.
 +
 
 +
The Scout SDK also detects if you are using (or importing) a target definition containing this variable. And if you have not yet defined a location for the variable will ask you to define one or create a new RAP target location.
 +
 
 +
&nbsp;
 +
 
 +
=== More Flexible Project Structure  ===
 +
 
 +
[[Image:Org.eclipse.scout.3.9.newAndNote5.png|thumb|right|300px|Configure the default packages]]
 +
 
 +
{{Bug|394125}} and {{Bug|405687}}
 +
 
 +
[[Image:Org.eclipse.scout.3.9.newAndNote4.png|thumb|left|450px]]
 +
 
 +
In Scout 3.9 the SDK does no longer rely on a specific package structure.
 +
 
 +
This affects the Scout Explorer which now searches for objects in a whole plugin instead of specific packages. As a consequence the folder 'Process Services' and 'Outline Services' have been merged to a general 'Services' node containing all services except lookup and the common ones. This gives you more flexibility in usage and design of your services.
 +
 
 +
Furthermore you have the possibility to specify the target package when creating new Scout objects using the Scout SDK Wizards. The packages where new objects are created by default can be configured using the preference page: Window -&gt; Preferences -&gt; Scout -&gt; Default Packages.
 +
 
 +
These settings are stored in the Scout project preferences and can therefore be shared using a team provider like SVN, CVS or Git.
 +
 
 +
For your existing projects, if you don't want to re-organize to the new package structure and don't want to get a mix of concepts there exists an option in Window -> Preferences -> Scout -> Use Legacy Target Package. If this option is enabled, the Scout elements created with the Scout SDK are placed in the same packages as with older Scout SDK Releases.
 +
 
 +
&nbsp;
 +
 
 +
&nbsp;
 +
 
 +
&nbsp;
 +
 
 +
&nbsp;
 +
 
 +
=== Improvements for the NLS Field ===
 +
 
 +
{{Bug|380507}}
 +
 
 +
We have changed the sorting and presentation of the NLS proposal field so that the list behaves more intuitive and that it is more clear why a match is included in the list. This includes separation of the matches depending on type and sorting according to relevance.
 +
 
 +
[[Image:Org.eclipse.scout.3.9.newAndNote6.png|700px|NLS Field Changes]]
 +
 
 +
=== Docx4j Integration  ===
 +
 
 +
{{bug|376461}} and {{bug|403087}}
 +
 
 +
The Scout SDK now also contains a checkbox to easily add/remove Docx4j (http://docx4java.org/) support to/from an Eclipse Scout application. The corresponding runtime and SDK bundles are available on the [http://marketplace.eclipse.org/content/docx4j-eclipse-scout Eclipse Marketplace] and will be automatically downloaded and installed when the checkbox is activated. Read more about [[Scout/Concepts/Docx4j|Docx4j for Eclipse Scout]] on the wiki.
 +
 
 +
The SDK bundles contain an importer and exporter for the NLS texts which can handle .xlsx files (Microsoft Excel 2007 or newer).
 +
 
 +
=== SDK Testing API ===
 +
 
 +
{{bug|407403}}
 +
 
 +
On the Scout Update Site (http://download.eclipse.org/scout/releases/3.9) a new Feature called "Eclipse Scout SDK Testing" is published.
 +
If you have developed your own Scout SDK enhancements, this feature helps you testing your SDK plugins. It contains various helpers for test-workspace setup and cleanup, to do various assertions or controlling common JDT tasks.
  
 
== Bugfixes ==
 
== Bugfixes ==
  
== Migration Guidelines ==
+
The following list shows all bugs which have been fixed for this release. The list also contains all new enhancements.
Some features and bugfixes sometimes require a change of the api. If this has been the case for the new release then you'll find behind the link below a guideline how to migrate your scout application to the newest release.
+
 
 +
*[https://bugs.eclipse.org/bugs/buglist.cgi?list_id=4143616&classification=Technology&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&product=Scout&target_milestone=3.9.0%20Kepler&target_milestone=3.9.0%20M2&target_milestone=3.9.0%20M3&target_milestone=3.9.0%20M4&target_milestone=3.9.0%20M5&target_milestone=3.9.0%20M6&target_milestone=3.9.0%20M7&target_milestone=3.9.0%20RC1&target_milestone=3.9.0%20RC2&target_milestone=3.9.0%20RC3&target_milestone=3.9.0%20RC4 Bug list for 3.9.0]
 +
 
 +
== Migration Guidelines ==
 +
 
 +
Some features and bugfixes sometimes require a change of the api. If this has been the case for the new release then you'll find behind the link below a guideline how to migrate your scout application to the newest release.  
  
 
{{ScoutLink|Migration|3.9| Migration Guidelines for 3.9}}
 
{{ScoutLink|Migration|3.9| Migration Guidelines for 3.9}}

Revision as of 05:29, 25 June 2013

This page shows what you need to know about the new Eclipse Scout 3.9 release shipped with Eclipse Kepler.

General

Scout Sources moved to GIT

bug 384960

For Kepler, Scout has moved to GIT: http://git.eclipse.org/c/scout/.

For more information see Getting_the_Scout_Sources.

Scout EPP Changes

bug 390431

Egit features added to EPP

CVS features removed from EPP. If CVS is needed, it has to be installed manually.

New testing features

bug 376459

Two features for testing have been added to the updatesite:

  • Eclipse Scout Runtime Testing
  • Eclipse Scout Runtime RAP Testing
  • Eclipse Scout SDK Testing

These features contains plugins that provide support (Utility classes, Test Runner...) in order to test scout applications.

New Runtime Features

Form Field Filter for FormData Import

bug 392409

Besides a IPropertyFilter the FormData import (method importFormData() in AbstractForm) now also allows to specify a IFormFieldFilter. With this overload it is now not only possible to influence which properties that are imported, but also which form fields that should be filled. A default implementation is available that allows to exclude some fields from the import (org.eclipse.scout.rt.client.ui.form.fields.ExcludeFormFieldFilter).

Multiple Swing Scout features in a single Eclipse application

bug 396252

The extension point org.eclipse.scout.rt.ui.swing.appextensions allows running multiple swing Scout features in a single Eclipse application.

Example: Create multiple applications extensions (e.g.):

public class App1 extends AbstractSwingApplicationExtension {
 
  public App1() {
    super("App1");
  }
 
  @Override
  protected IClientSession createClientSession(UserAgent userAgent) {
    IClientSessionRegistryService service = SERVICES.getService(IClientSessionRegistryService.class);
    return service.newClientSession(ClientSession.class, userAgent);
  }
 
  @Override
  protected ISwingEnvironment createEnvironment() {
    return new SwingEnvironment();
  }
}

Register ExtensibleSwingApplication as application and the previously created applications extensions

<?xml version="1.0" encoding="UTF-8"?>
 <plugin>
  <extension id="app" name="Application" point="org.eclipse.core.runtime.applications">
    <application>
      <run class="org.eclipse.scout.rt.ui.swing.ExtensibleSwingApplication"/>
    </application>
  </extension>
 ...
 <extension
       point="org.eclipse.scout.rt.ui.swing.appextensions">
    <swingApplicationExtension
          class="test.helloworld.ui.swing.App1"
          ranking="1">
    </swingApplicationExtension>
 </extension>
 ...

SWT: Visual Marker in editable cell

bug 395673 A marker icon is now displayed in an editable cell in an SWT table (similar to the swing table).

The icon can be changed by setting the extension org.eclipse.scout.rt.ui.swt.scouticons for the cell_editable icon.


JUnit test suite for Scout RT

With bug 402301 and bug 402304 a JUnit testing suite was started in the Eclipse Git Repositories. The tests are executed as part of the Maven+Tycho build.

JUnit tests classes requiring an UI layer (because they use AWT or SWT classes), are identified with a special suffix UiTest instead of Test. This allows to ignore these tests (maven profile skip-uitest, active by default) to be able to build on backend-servers that do not provide an UI layer. In order to execute the UiTest you might consider the maven profile include-uitest.

Further reading about testing can be found here: The Scout documentation has been moved to https://eclipsescout.github.io/.

New SDK Features

Scout Explorer Changes

Scout Explorer View

bug 394132

The Scout Explorer View shows all Scout Bundles and provides folders below them to manage the typical objects for a bundle type.

The detection and layout of this bundle entries (the green, orange and blue nodes) have been redesigned for Scout 3.9:

  1. The layout of the tree is completely based on the dependencies of your bundles. As the dependencies between bundles build up a graph, the Scout Explorer may show a single bundle at various places in the tree considering all paths in the actual dependency graph.
  2. As a consequence, each bundle can contain several bundles of the same type (breaking the trinity client-shared-server) for a more flexible layout.
  3. The tree also shows Scout bundles that are in your target platform (binary) and are only referenced by your workspace bundles.
  4. Fragments are shown as well
  5. There is a context menu Add Scout Bundles... on the bundle nodes that allows you to create sub modules or new bundles within your existing project.
  6. We added a Site Menu that allows you to influence which and how the Scout bundles should be displayed.
  7. You can now group Scout bundles together in Scout Working Sets. This allows you to group the Scout Explorer as you like and the Working Sets can also be used e.g. in the Eclipse Search.

           Scout Explorer Options

Support for Scout Mobile UI

bug 394127 and bug 378151

Scout 3.9 comes with an enhanced web user interface (RAP) that is optimized for smartphone (mobile) and tablet devices.

By creating a new Scout Project using the Scout SDK you automatically get the mobile support when choosing to create a RAP user interface bundle. In the default setup you get four servlets prepared:

  1. web for normal personal computers or laptops
  2. mobile for smartphone devices
  3. tablet for tablet devices
  4. root entrypoint for all browsers that will autodetect your device and dispatch to the best of the servlets above.

Furthermore you get a client.mobile bundle prepared that includes all modifications to your client that should apply to mobile and tablet devices only (e.g. if you want to hide or replace some features).

 

Default Super Classes are Customizable

Default Super Classes Preference Page

bug 395006 and bug 397268

In Scout 3.8 when creating a new object using a wizard you already have the possibility to choose from a list of possible super classes. But the super class selected by default is always the same. So if you e.g. have defined a project specific template for forms called 'AbstractMyProjectForm' you always have to remember to change the selected super class when creating forms.

With Scout 3.9 you now have the possibility to configure the super classes that should be used by default for each Scout project independently: Go to Window -> Preferences -> Scout -> Default Super Classes. There you can specify the default super class to use for each object type and Scout project.

This configuration is also considered if you don't explicitly have the possibility to choose a super class in the wizards: E.g. when creating a new Form by default there are also 'Cancel' and 'OK' buttons created. If you now modify the default super class for OK buttons, this is automatically used by the new Form wizard as well.

This mechanism also respects the new extensible Scout objects defined in 'org.eclipse.scout.rt.extension.client': If your project has this dependency, the Scout SDK prefers those objects over the standard ones (unless you have modified the defaults).

The settings are stored in the project preferences so that you can share them with your team using e.g. a team provider like SVN, CVS or Git.

 

 

 

Variable Local RAP Target Location

Specify the RAP Target Location

bug 394751

Modify the value of the scout_rap_target variable

If you are using a local RAP target (instead of a P2 update site) you may want to share your target definition with other developers using a team provider like SVN, CVS or Git. But there may be differences in the local path pointing to the RAP target (because you have a different setup or operating system). Or you may not yet have a local RAP target at all. This makes it hard to use a target definition in a team.

In Scout 3.9 you now have a new Eclipse environment variable called 'scout_rap_target'. So instead of using the local path directly in the target definition you can use the ${scout_rap_target} variable as a palceholder and each developer can then point this variable to the path where to find the plugins locally. The value of the 'scout_rap_target' variable is stored in the workspace and can therefore be different for each instance.

The Scout SDK also detects if you are using (or importing) a target definition containing this variable. And if you have not yet defined a location for the variable will ask you to define one or create a new RAP target location.

 

More Flexible Project Structure

Configure the default packages

bug 394125 and bug 405687

Org.eclipse.scout.3.9.newAndNote4.png

In Scout 3.9 the SDK does no longer rely on a specific package structure.

This affects the Scout Explorer which now searches for objects in a whole plugin instead of specific packages. As a consequence the folder 'Process Services' and 'Outline Services' have been merged to a general 'Services' node containing all services except lookup and the common ones. This gives you more flexibility in usage and design of your services.

Furthermore you have the possibility to specify the target package when creating new Scout objects using the Scout SDK Wizards. The packages where new objects are created by default can be configured using the preference page: Window -> Preferences -> Scout -> Default Packages.

These settings are stored in the Scout project preferences and can therefore be shared using a team provider like SVN, CVS or Git.

For your existing projects, if you don't want to re-organize to the new package structure and don't want to get a mix of concepts there exists an option in Window -> Preferences -> Scout -> Use Legacy Target Package. If this option is enabled, the Scout elements created with the Scout SDK are placed in the same packages as with older Scout SDK Releases.

 

 

 

 

Improvements for the NLS Field

bug 380507

We have changed the sorting and presentation of the NLS proposal field so that the list behaves more intuitive and that it is more clear why a match is included in the list. This includes separation of the matches depending on type and sorting according to relevance.

NLS Field Changes

Docx4j Integration

bug 376461 and bug 403087

The Scout SDK now also contains a checkbox to easily add/remove Docx4j (http://docx4java.org/) support to/from an Eclipse Scout application. The corresponding runtime and SDK bundles are available on the Eclipse Marketplace and will be automatically downloaded and installed when the checkbox is activated. Read more about Docx4j for Eclipse Scout on the wiki.

The SDK bundles contain an importer and exporter for the NLS texts which can handle .xlsx files (Microsoft Excel 2007 or newer).

SDK Testing API

bug 407403

On the Scout Update Site (http://download.eclipse.org/scout/releases/3.9) a new Feature called "Eclipse Scout SDK Testing" is published. If you have developed your own Scout SDK enhancements, this feature helps you testing your SDK plugins. It contains various helpers for test-workspace setup and cleanup, to do various assertions or controlling common JDT tasks.

Bugfixes

The following list shows all bugs which have been fixed for this release. The list also contains all new enhancements.

Migration Guidelines

Some features and bugfixes sometimes require a change of the api. If this has been the case for the new release then you'll find behind the link below a guideline how to migrate your scout application to the newest release.

The Scout documentation has been moved to https://eclipsescout.github.io/.

Back to the top