https://wiki.eclipse.org/api.php?action=feedcontributions&user=Sewe.cqse.eu&feedformat=atomEclipsepedia - User contributions [en]2024-03-29T07:51:53ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=Developing_Tycho&diff=437103Developing Tycho2019-12-11T11:42:33Z<p>Sewe.cqse.eu: In 2019-09, the EPP package for committers does contain m2e</p>
<hr />
<div>== Setup your environment ==<br />
<br />
=== Using the Eclipse Installer (Oomph) ===<br />
Step by step instructions:<br />
# Download the [https://wiki.eclipse.org/Eclipse_Installer Eclipse Installer]. <br />
# Start the installer using the ''eclipse-inst'' executable.<br />
# On the first page (product selection), click the preference button in the top-right corner and select the ''Advanced Mode''.<br />
# If you are behind a proxy, at this point you might want to double check your network settings by clicking in the "Network Proxy Settings" at the bottom.<br />
# Select ''Eclipse IDE for Eclipse Committers''. Click ''Next''.<br />
# Under ''Eclipse.org'', double-click on ''Tycho'' (single click is not enough!). Make sure that ''Tycho'' is shown in the table on the bottom. Click ''Next''.<br />
# You can edit the ''Installation Folder'', but you do not have to select the ''Target Platform'' here, this will be set later automatically. By choosing ''Show all variables'' at the bottom of the page, you are able to change other values as well but you do not have to. Click ''Next''.<br />
# Press ''Finished'' on the ''Confirmation'' page will start the installation process. <br />
# The installer will download the selected Eclipse version, starts Eclipse and will perform all the additional steps (cloning the git repos, etc...). When the downloaded Eclispe started, the progress bar in the status bar shows the progress of the overall setup.<br />
# Once the ''Executing startup tasks'' job is finished you should have all the Tycho and Tycho Extras projects imported into 2 working sets called ''Tycho'' and ''Tycho Extras''.<br />
# Some Projects might sill have errors. Select them (or all) and choose ''Maven''->''Update Project..'' from the context menu. De-select ''Clean projects'' in the shown dialog and press ''OK'' to update the projects. After that, no more error should be there. <br />
<br />
=== Manually setup (Deprecated)===<br />
Prefered and easier way is to follow the instructions above, but you could also setup your environment manually:<br />
# Get an [https://www.eclipse.org/downloads/ Eclipse IDE] with a recent version of the [http://www.eclipse.org/m2e/ Maven integration for Eclipse (m2eclipse)] and Eclipse PDE installed. m2eclipse is included in various Eclipse packages, e.g. the "Eclipse IDE for Eclipse Committers" package. To add m2eclipse to your existing Eclipse installation, install it from the [https://wiki.eclipse.org/Simultaneous_Release release train p2 repository] or from the [http://download.eclipse.org/technology/m2e/releases m2eclipse update site].<br />
# Install [http://maven.apache.org/download.html Maven] version 3.0 or later<br />
# If your Internet connection uses a proxy, make sure that you have the proxy configured in your [http://maven.apache.org/settings.html Maven settings.xml]<br />
# Get the [https://projects.eclipse.org/projects/technology.tycho/developer Tycho sources] from eclipse.org; there are different ways to do this:<br />
#* In EGit, open the ''Git Repositories'' view, select ''Clone a Git Repository'' and clone from the location https://git.eclipse.org/r/tycho/org.eclipse.tycho for Tycho and https://git.eclipse.org/r/tycho/org.eclipse.tycho.extras for Tycho Extras.<br />
#* In a shell, execute <tt>git clone https:</tt><tt>//git.eclipse.org/r/tycho/org.eclipse.tycho </tt> for Tycho and <tt>git clone https:</tt><tt>//git.eclipse.org/r/tycho/org.eclipse.tycho.extras</tt> for Tycho Extras.<br />
# In Eclipse, use ''File > Import > Existing Maven Projects'', select the root directory of the sources, and import all projects. If prompted by m2eclipse, install the proposed project configurators and restart Eclipse.<br />
# For Tycho only: Configure the target platform: Open the file <tt>tycho-bundles-target/tycho-bundles-target.target</tt> and click on ''Set as Target Platform'' in the upper right corner of the target definition editor.<br />
<br />
The result should be an Eclipse workspace without build errors. m2eclipse may take some time to download required libraries from Maven central.<br />
* If there are compile errors in the projects <tt>org.eclipse.tycho.surefire.junit</tt>, <tt>org.eclipse.tycho.surefire.junit4</tt>, <tt>org.eclipse.tycho.surefire.junit47</tt>, or <tt>org.eclipse.tycho.surefire.osgibooter</tt>, just select these projects and manually trigger an update via ''Maven > Update project...'' from the context menu.<br />
* If there are compile errors in the project <tt>tycho-p2-director-plugin</tt>, right-click on the project and go to ''Build Path > Configure Build Path...'' and change the JRE System Library to JavaSE-1.7. Then revert the changes that the PDE does to the file <tt>tycho-p2-director-plugin/.settings/org.eclipse.jdt.core.prefs</tt>. (Background: The project optionally uses classes from the Java 7 library, so it needs to compile with a Java 7 JDK.)<br />
<br />
== Building and Testing ==<br />
<br />
To build Tycho/Tycho Extras from source, executed '''<tt>mvn clean install</tt>''' in the source root. This also runs the unit tests.<br />
<br />
=== Tycho integration tests ===<br />
<br />
The Tycho integration tests are located in the project <tt>tycho-its</tt>. To run all Tycho integration tests, execute <tt>mvn clean install -f tycho-its/pom.xml</tt>. To run a single integration test, select the test class in Eclipse and run it as ''JUnit Test''.<br />
<br />
'''Background information on the Tycho integration tests'''<br />
<br />
The integration tests trigger sample builds that use Tycho. These builds expect that Tycho has been installed to the local Maven repository. This is why you need to build Tycho through a <tt>mvn install</tt> before you can run the integration tests.<br />
<br />
Alternatively, e.g. if you are only interested in modifying an integration test and do not want to patch Tycho itself, you can configure the integration tests to download the current Tycho snapshot produced by the [http://hudson.eclipse.org/tycho/view/CI Tycho CI builds]. To do this, you need to edit the Maven settings stored in <tt>tycho-its/settings.xml</tt> and add the tycho-snapshots repository as described in [[Getting Tycho]]. (Advanced note: The integration tests can also be pointed to a different settings.xml with the system property <tt>tycho.testSettings</tt>.)<br />
<br />
=== Tycho Extras integration tests ===<br />
<br />
Each Tycho Extras project does have its own integration tests located in the subdirectory <tt>it</tt> within the project (e.g. <tt>tycho-eclipserun-plugin/src/it</tt>). <br />
To run the tests use the maven profile <tt>its</tt>, run <tt>mvn integration-test -Pits</tt> either within the Tycho Extras source folder to run all Tycho Extras integration tests or within a Tycho Extras plugin directory to run only the integration tests of that project.<br />
<br />
'''Background information on the Tycho Extras integration tests'''<br />
<br />
Tycho Extras and Tycho are developed and released in parallel and will use the snapshot version of Tycho from the repository <tt>https://repo.eclipse.org/content/repositories/tycho-snapshots/</tt>. <br />
If you want to run the tests with a specific version of Tycho use the <tt>tycho-version</tt> system property, e.g. <tt>mvn integration-test -Pits -Dtycho-version=0.22.0</tt>.<br />
To use a different Tycho snapshot repository use the system property <tt>tycho-snapshots-url</tt>, e.g. <tt>mvn integration-test -Pits -Dtycho-snapshots-url=file:/path/to/repo</tt><br />
<br />
== Debugging ==<br />
<br />
In order to debug Tycho/Tycho Extras plugins inside Eclipse:<br />
# Get the Tycho/Tycho Extras sources in Eclipse<br />
# Create/get a project that highlights the bug<br />
# Run the project with <tt>mvnDebug clean install</tt><br />
# Go into your Eclipse, use ''Debug > Remote Java Application'', select port 8000<br />
<br />
== Advanced Topics ==<br />
<br />
=== Writing Tycho integration tests ===<br />
<br />
The hardest part for writing Tycho integration tests is the naming. While names are mostly important for readability, there were also cases where the ID "feature" was used multiple times and hence a test used the build result of a different integration test.<br />
<br />
Therefore, here are a few tips for writing good integration tests:<br />
* Test project name: Although many existing test have a bug number in the name, this is '''not''' the recommended naming scheme. Since integration test can take some time to execute, it may be a good idea to test related things in one test. <br>So name the test projects in a way that they can be found, and that related tests are sorted next to each other, e.g. in the form <tt>&lt;component&gt;.&lt;aspect&gt;</tt>.<br />
* Package: Should be <tt>org.eclipse.tycho.test.&lt;component&gt;</tt> (without the aspect so that we don't get an excessive number of packages)<br />
* Test project groupIds: Should be <tt>tycho-its-project.&lt;component&gt;.&lt;aspect&gt;</tt> plus a segment for the reactor in case of multi-reactor tests. The groupId is particularly important if the test project is installed to the local Maven repository. (Avoid install; use verify if possible.)<br />
* Test project artifactIds: Have to be the same as the ID of the feature/bundle; need to start with something unique, e.g. the first letters of each segment of the project name.<br />
<br />
=== Building Tycho against a locally built version of p2 ===<br />
<br />
Tycho makes heavy use of p2 functionality. Therefore it may be useful to try out patches to p2 without waiting for a new p2 release, or even just the next nightly build. With the following steps it is possible to build Tycho against a locally built version of p2.<br />
<br />
# Get the p2 sources (see [http://projects.eclipse.org/projects/rt.equinox.p2/developer p2 project information])<br />
# Make changes in the p2 sources<br />
# Build the changed p2 bundles individually with <tt>mvn clean install -Pbuild-individual-bundles</tt> (see [[Equinox/p2/Build]] for more information)<br />
# Build at least the Tycho module tycho-bundles-external with <tt>mvn clean install</tt> - you should see a warning that the locally built p2 bundles have been used.<br />
Then the locally built Tycho SNAPSHOT includes the patched p2 version.<br />
<br />
Note: Tycho always allows references to locally built artifacts, even if they are not part of the target platform. Therefore you may want to clear the list of locally built artifacts (in the local Maven repository in .meta/p2-local-metadata.properties) after you have finished your trials with the patched p2 version.<br />
<br />
=== Updating the Equinox and JDT dependencies of Tycho ===<br />
<br />
Tycho has Maven dependencies to Equinox and JDT, so these artifact need to be available in a Maven repository. Currently, the authors don't provide these artifacts in Maven central, so we deploy them ourselves (with the groupId <tt>org.eclipse.tycho</tt>). See <tt>tycho-releng/pom.xml</tt> for the technical details on how this is done.<br />
<br />
If we want to use a new version of these dependencies in a Tycho snapshot, we can also deploy snapshot versions of these dependencies alongside with the Tycho snapshots. This is how this is done:<br />
<br />
# Update the p2 repository in <tt>tycho-releng/pom.xml</tt><br />
# Update the versions in the parent POM so that they match the versions available in the p2 repository. Add the <tt>-SNAPSHOT</tt> suffix to the Maven version properties.<br />
# Commit and upload the change to Gerrit. The Gerrit build will fail with a dependency resolution error.<br />
# Trigger the job [https://ci.eclipse.org/tycho/job/tycho-deploy-dependencies/ tycho-deploy-dependencies] and make it build the proposed change<br />
# Re-trigger the voter job for the Gerrit change. The build should now pass.<br />
<br />
[[Category:Tycho]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.5&diff=434948Tycho/Release Notes/1.52019-10-30T10:40:48Z<p>Sewe.cqse.eu: Tycho 1.5.0 has been released already</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css><br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/1.4|&lt; Previous Version]] | [[Tycho/Release Notes/1.6|Next Version &gt;]]</div><br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&target_milestone=1.5.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.5.0]<br />
<br />
=== Pomless Build ===<br />
<br />
The pomless build has been improved to support some new features and improve existing ones:<br />
<br />
{{bug|490886}} - support for pomless update site builds<br />
<br />
{{bug|482487}} - support for pomless product builds<br />
<br />
{{bug|550285}} - support for pomless target-definition builds <br />
<br />
{{bug|507700}} - support .test as a suffix for plugins and make it configurable, you can now alternatively specify a property ''tycho.pomless.testbundle=true/false'' in build.properties file to override the default behavior.<br />
<br />
{{bug|478704}} - support for alternative parent-pom file locations: <br />
- It is possible to define a system-property tycho.pomless.parent (defaults to "..") that configures the global default for searching parent poms (similar to tycho.localArtifacts this can't be configured in pom directly because of the early phase this is required)<br />
- It is also possible to define tycho.pomless.parent inside build.properties of individual bundle/fragment that overrides the global default for only this module<br />
<br />
{{bug|492819}} - support for structured builds: It is now possible to use pomless for so called [http://blog.vogella.com/2015/12/15/pom-less-tycho-builds-for-structured-environments/ "structured-builds"] that means the folders are not just a flat representation of all projects but are structured by their type (e.g. bundles, test, feature), you can find an example [https://git.eclipse.org/c/tycho/org.eclipse.tycho.extras.git/tree/tycho-extras-its/src/test/resources/testpomless-structured here] so it is possible to have just one pom.xml in the root of you project structure.<br />
You can find a [https://github.com/vogellacompany/tycho-example/pull/10 pull-request here] that shows what changes could be made to leverage this feature compared to a project using Tycho 1.4 pomless extension to reduce the required poms.<br />
<br />
=== FreeBSD support ===<br />
<br />
{{bug|549689}} adds support for FreeBSD platform in RCP product definitions.<br />
<br />
=== Thread stack traces dump before forkedProcessTimeoutInSeconds timeout occurs ===<br />
<br />
The parameter [https://www.eclipse.org/tycho/sitedocs-extras/tycho-eclipserun-plugin/eclipse-run-mojo.html#forkedProcessTimeoutInSeconds forkedProcessTimeoutInSeconds] can be specified to kill the process which runs tests (also prior to Tycho 1.5.0). With the change for {{bug|542876}}, a few minutes before the process is killed due to this timeout, thread stack traces are dumped in the test log. I.e. when a timeout occurs (e.g. due to a deadlock) the logs would now contain some indication of which code causes the timeout.<br />
<br />
=== A Mojo to list dependencies ===<br />
<br />
{{bug|547269}} introduces a new <tt>org.eclipse.tycho.extras:tycho-dependency-tools-plugin:list-dependencies</tt> mojo that can list the bundles resulting of dependency resolution for Tycho projects.<br />
<br />
This differs from <tt>dependency:list</tt> in that the later one lists the classpath which may include nested jars instead of required bundle.<br />
<br />
The default output file is <tt>target/dependenct-list.txt</tt>, lists of absolute paths to required bundles and is suitable to use with the <tt>org.eclipse.pde.api.tools.apiAnalysis</tt> application.<br />
<br />
=== ECJ update ===<br />
<br />
ECJ has been updated to version 3.19.0. This version adds support for Java 12 bytecode and features.<br />
<br />
=== JGit update ===<br />
<br />
JGit has been updated to version 5.5.0. Full release notes [https://projects.eclipse.org/projects/technology.jgit/releases/5.5.0/ here].<br />
<br />
=== Equinox update ===<br />
<br />
Equinox and p2 has been updated to their 2019-09 versions.<br />
<br />
=== Support for maven.compiler.failOnWarning ===<br />
<br />
{{bug|547470}} introduces support for <tt>maven.compiler.failOnWarning</tt> user property to tycho-compiler-plugin with same behavior as [https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#failOnWarning maven-compiler-plugin].<br />
<br />
=== Support for surefire enableAssertions ===<br />
<br />
{{bug|526008}} introduces support for <tt>enableAssertions</tt> user property to tycho-surefire. Default value for it is <tt>false</tt> while maven-surefire has it as <tt>true</tt>.<br />
<br />
=== Update plexus container used ===<br />
<br />
{{bug|551292}} updated Maven to use org.eclipse.sisu.plexus as it's plexus container instead of plexus-container-default. '''NOTE: TYCHO MIN MAVEN REQUIREMENT HAS BEEN BUMPED TO VERSION 3.1.0.<br />
'''<br />
<br />
=== Support for Eclipse-PlatformFilter ===<br />
<br />
{{bug|487341}} multi-environment build fails using platform filters is now fixed and allows the filtering of a bundle for a particular environment<br />
<br />
<br />
[[Category:Tycho|Release Notes/1.5]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.4&diff=434947Tycho/Release Notes/1.42019-10-30T10:39:41Z<p>Sewe.cqse.eu: </p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css><br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/1.3|&lt; Previous Version]] | Next Version &gt;</div><br />
<br />
<br />
<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&target_milestone=1.4.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.4.0]<br />
<br />
=== Objectweb ASM update ===<br />
<br />
ObjectWeb ASM has been updated to version 7.0 from 5.0.3 which provides Java 11 compatibility in artifactcomparator. '''Note:''' Due to upstream no longer producing org.ow2.asm:asm-debug-all Tycho now requires org.ow2.asm:asm-tree and org.ow2.asm:asm-util. {{bug|543850}}<br />
<br />
=== Resolving Java 11 removed modules ===<br />
<br />
Java 11 removed a number of modules which broke compilation/tests/resolving deps when the bundle has lower BREE as they were resolved from the BREE profile. Now Tycho will check if runtime Java is 11+ and if it differs from bundle's EE - in this case it will resolve deps with current runtime's EE. '''Note:''' Some additional bundles may need to be added to the target platform to replace the removed JDK modules. {{bug|541403}}<br />
<br />
=== Performance improvement using Git timestamp provider ===<br />
<br />
If you have configured Tycho to create [[Tycho/Reproducible Version Qualifiers|reproducable version qualifiers]], then Tycho will calculate the qualifier from the underlying git history. This can take quite a while on git repositories with a big history. In Tycho 1.4 the history retrieval has been optimized, and we have seen the execution time drop down from several seconds to less than a second on a big repository. This calculation is done for each module in an aggregator. If you build big aggregators with many modules, then you may gain some minutes of build time just by upgrading Tycho. {{bug|544005}}<br />
<br />
=== ECJ update ===<br />
ECJ has been updated to version 3.17.0 from 3.15.1. This version brings support for Java 11 bytecode and features.<br />
<br />
<br />
[[Category:Tycho|Release Notes/1.4]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.5&diff=433655Tycho/Release Notes/1.52019-08-07T15:05:13Z<p>Sewe.cqse.eu: Wrong version Bugzilla query (1.4.0 rather than 1.5.0)</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css><br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/1.4|&lt; Previous Version]] | Next Version &gt;</div><br />
<br />
<br />
<br />
<br />
== SNAPSHOT builds ==<br />
<br />
<br />
<br />
Tycho 1.5.0-SNAPSHOT is currently in development. To try out the most recent snapshot build, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>1.5.0-SNAPSHOT</tt>.<br />
<br />
<pre><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</pre><br />
<br />
=== SNAPSHOT site docs ===<br />
<br />
Refer to the [https://ci.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/index.html latest SNAPSHOT site docs for Tycho] and [https://ci.eclipse.org/tycho/job/tycho.extras-sitedocs/ws/target/staging/index.html Tycho Extras].<br />
<br />
<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&target_milestone=1.5.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.5.0-SNAPSHOT]<br />
<br />
=== FreeBSD support ===<br />
<br />
{{bug|549689}} adds support for FreeBSD platform in RCP product definitions.<br />
<br />
=== Thread stack traces dump before forkedProcessTimeoutInSeconds timeout occurs ===<br />
<br />
The parameter [https://www.eclipse.org/tycho/sitedocs-extras/tycho-eclipserun-plugin/eclipse-run-mojo.html#forkedProcessTimeoutInSeconds forkedProcessTimeoutInSeconds] can be specified to kill the process which runs tests (also prior to Tycho 1.5.0). With the change for {{bug|542876}}, a few minutes before the process is killed due to this timeout, thread stack traces are dumped in the test log. I.e. when a timeout occurs (e.g. due to a deadlock) the logs would now contain some indication of which code causes the timeout.<br />
<br />
=== A Mojo to list dependencies ===<br />
<br />
{{bug|547269}} introduces a new <tt>org.eclipse.tycho.extras:tycho-dependency-tools-plugin:list-dependencies</tt> mojo that can list the bundles resulting of dependency resolution for Tycho projects.<br />
<br />
This differs from <tt>dependency:list</tt> in that the later one lists the classpath which may include nested jars instead of required bundle.<br />
<br />
The default output file is <tt>target/dependenct-list.txt</tt>, lists of absolute paths to required bundles and is suitable to use with the <tt>org.eclipse.pde.api.tools.apiAnalysis</tt> application.<br />
<br />
=== Noteworthy item ===<br />
<br />
Description, link to bug {{bug|123456}}, if necessary link to dedicated documentation, if useful include examples.<br />
<br />
<br />
<br />
[[Category:Tycho|Release Notes/1.4]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.4&diff=433654Tycho/Release Notes/1.42019-08-07T15:03:05Z<p>Sewe.cqse.eu: Tycho 1.4 has been released already. 1.5 is in development</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css><br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/1.3|&lt; Previous Version]] | Next Version &gt;</div><br />
<br />
<br />
<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&target_milestone=1.4.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.4.0-SNAPSHOT]<br />
<br />
=== Objectweb ASM update ===<br />
<br />
ObjectWeb ASM has been updated to version 7.0 from 5.0.3 which provides Java 11 compatibility in artifactcomparator. '''Note:''' Due to upstream no longer producing org.ow2.asm:asm-debug-all Tycho now requires org.ow2.asm:asm-tree and org.ow2.asm:asm-util. {{bug|543850}}<br />
<br />
=== Resolving Java 11 removed modules ===<br />
<br />
Java 11 removed a number of modules which broke compilation/tests/resolving deps when the bundle has lower BREE as they were resolved from the BREE profile. Now Tycho will check if runtime Java is 11+ and if it differs from bundle's EE - in this case it will resolve deps with current runtime's EE. '''Note:''' Some additional bundles may need to be added to the target platform to replace the removed JDK modules. {{bug|541403}}<br />
<br />
=== Performance improvement using Git timestamp provider ===<br />
<br />
If you have configured Tycho to create [[Tycho/Reproducible Version Qualifiers|reproducable version qualifiers]], then Tycho will calculate the qualifier from the underlying git history. This can take quite a while on git repositories with a big history. In Tycho 1.4 the history retrieval has been optimized, and we have seen the execution time drop down from several seconds to less than a second on a big repository. This calculation is done for each module in an aggregator. If you build big aggregators with many modules, then you may gain some minutes of build time just by upgrading Tycho. {{bug|544005}}<br />
<br />
=== ECJ update ===<br />
ECJ has been updated to version 3.17.0 from 3.15.1. This version brings support for Java 11 bytecode and features.<br />
<br />
<br />
[[Category:Tycho|Release Notes/1.4]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_2018/Darmstadt&diff=426064Eclipse DemoCamps 2018/Darmstadt2018-06-20T15:03:09Z<p>Sewe.cqse.eu: </p>
<hr />
<div>Engage in the Eclipse and Java community this Summer at the [[Eclipse_DemoCamps_2018|Eclipse DemoCamp]] in Darmstadt. If you are interested in Open Source, Eclipse Projects, Java and more, this is the event to attend!<br />
<br />
During the break and after the talks enjoy the networking, free beer, food and the opportunity to meet the speakers and project leads.<br />
<br />
Note: This event will be held in English!<br />
<br />
=== Location ===<br />
<br />
The demo camp will take place at the Deutsche Telekom office in T-Online-Allee 1, 64295 Darmstadt.<br />
<br />
=== Date and Time ===<br />
<br />
The DemoCamp will take place on Wednesday, June 20th at 18:00.<br />
<br />
=== Sponsors ===<br />
<br />
This DemoCamp is sponsored by [https://www.qivicon.com Qivicon]<br />
<br />
[[File:Qivicon_logo.png]]<br />
<br />
=== Agenda ===<br />
<br />
*17:30 - 18:00 Arrival<br />
*18:00 - 18:10 Welcome / Opening<br />
*18:10 - 18:30 Approaching Light Speed - News from the Eclipse Photon Platform - Karsten Thoms, itemis<br />
*18:30 - 19:10 Spring Tools 4 and the Language Server Protocol Explained - Martin Lippert, Pivotal<br />
*19:10 - 19:30 Hands-on: Digital Twins with Eclipse Ditto - Daniel Fesenmeyer, Bosch SI<br />
*19:30 - 19:50 Break, Snacks<br />
*19:50 - 20:10 From JEE to Jakarta EE: On the way to Cloud Native Java - Ralph Müller, Eclipse Foundation<br />
*20:10 - 20:30 MicroProfile: Innovationsschmiede für Jakarta EE - Thilo Frotscher<br />
*20:30 - 20:50 Understanding the Smart Home - Kai Kreuzer, Deutsche Telekom<br />
*20:50 - 21:00 Closing and Wrap-up<br />
*21:00 - 22:00 Networking with pretzels and beer!<br />
<br />
=== Registration / Who Is Attending ===<br />
<br />
The event is free and open to anyone interested, but for the planning, we require you to register.<br />
Please note that you will be asked to prove your identity (ID card or driver license) for being allowed into the building!<br />
<br />
If you plan on attending please add your name and company to the list below. If you have any trouble with the wiki, just send an email to [mailto:kai.kreuzer@telekom.de Kai Kreuzer].<br />
<br />
# [http://www.xing.com/profile/Kai_Kreuzer Kai Kreuzer], [https://www.qivicon.com Deutsche Telekom AG]<br />
# [https://www.xing.com/profile/Jochen_Hiller2 Jochen Hiller], [https://www.qivicon.com Deutsche Telekom AG]<br />
# [https://www.xing.com/profile/Simon_Kaufmann18 Simon Kaufmann], [https://www.qivicon.com Deutsche Telekom AG]<br />
# [https://www.xing.com/profile/Stefan_Triller2 Stefan Triller], [http://www.telekom.de/ Deutsche Telekom AG]<br />
# [https://www.xing.com/profile/Joern_Hameister2 Jörn Hameister], [http://www.telekom.de/ Deutsche Telekom AG] & [http://www.jug-da.de/ JUG Darmstadt]<br />
# Falk Sippach, [https://www.oio.de/ Orientation in Objects GmbH] & [http://www.jug-da.de/ JUG Darmstadt]<br />
# Jan Westerkamp, Sensor Aktor GmbH & [http://www.jug-da.de/ JUG Darmstadt]<br />
# [https://www.xing.com/profile/Kai_Steuernagel Kai Steuernagel], [http://www.telekom.de/ Deutsche Telekom AG]<br />
# Martin Lippert, Pivotal<br />
# Susan Iwai, Eclipse Foundation<br />
# Oliver Kuhn, SUBITO<br />
# [https://www.xing.com/profile/David_Law David Law], [https://www.apconsult.de/ ap consult GmbH]<br />
# [https://www.xing.com/profile/Rolf_Masfelder Rolf Masfelder], [http://www.nector-itservices.de/ NECTOR IT-Services]<br />
# Andreas Sewe, [https://www.cqse.eu/ CQSE GmbH]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Java_9_Readiness&diff=417171Java 9 Readiness2017-05-24T07:28:46Z<p>Sewe.cqse.eu: </p>
<hr />
<div>This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each [[Simultaneous Release|release train]] project. The page also indicates which projects will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.<br />
<br />
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.<br />
<br />
Java 9 uses *.jmod to package libraries as modules. The Java 8 version of JDT can't handle modules and so can't recognize a Java 9 JRE/JDK. Unfortunately licensing issues prevent JDT distributing Java 9 support until Java 9 GA. Consequently use of Java 9 prior to GA is not as trivial as one might expect.<br />
<br />
There are several things you can do to check the readiness for Java 9.<br />
<br />
=== Configure Eclipse for Java 9 ===<br />
<br />
====Download Java 9====<br />
You need to download and install a Java 9 VM, e.g. from https://jdk9.java.net/. <br />
<br />
====Configure Eclipse to run on Java 9 VM====<br />
Unless you have Java 9 on your system path, you need to specify the use of your Java VM. If you already do this, simply replace it with a Java 9 VM. Otherwise it can easily be done by adding something like:<br />
<pre>-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe</pre><br />
following the ''--launcher.appendVmargs'' line to the eclipse.ini.<br />
<br />
====Configure Eclipse for Java 9 modules====<br />
Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to eclipse.ini:<br />
'''--add-modules=ALL-SYSTEM'''<br />
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default ({{bug|493761}}).<br />
Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules.<br />
* Only works in JDK 8, but not in JDK 9: Run <code>jdeps <i>fully.qualified.classname</i></code><br />
* In Eclipse with Java 9 Support (BETA) for Oxygen (see below), you can open the type in a JavaSE-9 JRE and perform Show In > Package Explorer. Inside the "JRE System Library" node, the Package Explorer will show the module in which that type resides.<br />
<br />
====eclipse.ini summary====<br />
Your eclipse.ini should contain something like:<br />
<pre>--launcher.appendVmargs<br />
-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe<br />
-vmargs<br />
-Dosgi.requiredJavaVersion=1.8<br />
--add-modules=ALL-SYSTEM</pre><br />
<br />
==== Install Eclipse Java 9 Support (BETA) ====<br />
This is useful if you have to debug problems, e.g. when it fails to run your project.<br />
<br />
This is essential if you want to run JUnit tests in the Eclipse IDE using Java 9.<br />
<br />
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. If you are not using an EPP with a pre-installed '''Marketplace Client''', you must install it first (from the '''General Purpose Tools''' category of the '''http://download.eclipse.org/releases/oxygen''' P2 repo).<br />
<br />
Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.<br />
<br />
==== Specify a Java 9 JRE ====<br />
Use Window->Preferences->Java->Install JREs to make your Java 9 VM available within Eclipse.<br />
<br />
You may want to associate Java 9 with some Execution Environments to force a rebuild using Java 9.<br />
<br />
=== Run your tests with Java 9 ===<br />
<br />
You can do this locally or soon on Hudson. A Java 9 VM will hopefully be available on Hudson soon ({{bug|513618}}). <br />
To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to [[#Install Eclipse Java 9 Support (BETA)|install]] the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.<br />
<br />
For JUnit (standalone) tests, you should specify a Java 9 execution environment on the JRE launch configuration tab.<br />
<br />
For JUnit Plugin tests, you should specify a Java 9 execution environment on the Main launch configuration tab and<br />
as noted above, you must add "--add-modules=java.se.ee" to the VM arguments on the Arguments tab..<br />
<br />
=== Check whether your project or required libraries use internals of the Java VM ===<br />
<br />
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called <code>jdeps(.exe)</code>. There are two ways you can check your code / repository:<br />
* There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)<br />
* The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.<br />
<br />
NOTE:<br />
<br />
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.<br />
<br />
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.<br />
<br />
=== Reflection hacks ===<br />
<br />
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.<br />
<br />
=== Java 9 Readiness ===<br />
<br />
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Project<br />
! scope="col"| Contact<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Adds Java 9 Support<br />
|-<br />
! Eclipse Project (Platform, JDT, PDE)<br />
| Dani Megert<br />
| Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis ({{bug|508734}}).<br />
| Yes, new code to support Java 9 development, compilation, and debugging will be delivered.<br />
|-<br />
! Web Tools Platform (WTP)<br />
| Carl Anderson<br />
| Not yet tested<br />
| Yes, new code to support Java 9 facets will be delivered<br />
|-<br />
! EclEmma<br />
| Evgeny Mandrikov<br />
| Yes<br />
| Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.<br />
|-<br />
! Code Recommenders<br />
| Andreas Sewe<br />
| Yes @ M7 (<s>{{bug|513634}}</s>)<br />
| Yes (will work with Java 9 source)<br />
|-<br />
! Automated Error Reporting<br />
| Andreas Sewe<br />
| Yes<br />
| n/a<br />
|-<br />
! Object Constraint Language (OCL)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Declarative QVT (QVTd)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Eclipse for Testers<br />
| Marvin Mueller<br />
| No / Yes if using "--permit-illegal-access"<br />
| Not planned yet.<br />
|-<br />
|}<br />
Known state of Orbit Bundles.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Bundle<br />
! scope="col"| Version<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Supports Java 9<br />
|-<br />
! com.google.guava<br />
| 15.0.0<br />
| Yes. All uses of <code>sun.misc.Unsafe</code> have a safe fallback.<br />
| n/a<br />
|-<br />
! org.objectweb.asm<br />
| 5.2.0<br />
| Yes<br />
| No. The ClassReader throws an IAE for greater than Opcodes.V1_8.<br />
Workaround: in JaCoCo - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L101<br />
This is safe, because Java 9 does not introduce any new instructions.<br />
Version can be restored after bytecode generation/modification - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L112<br />
|-<br />
! org.apache.felix.gogo.runtime<br />
| 0.10.0<br />
| {{bug|514939}}<br />
| n/a<br />
|-<br />
|-<br />
! .<br />
| .<br />
| .<br />
|}</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Java_9_Readiness&diff=415779Java 9 Readiness2017-04-07T14:14:37Z<p>Sewe.cqse.eu: </p>
<hr />
<div>This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each [[Simultaneous Release|release train]] project. The page also indicates which projects will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.<br />
<br />
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.<br />
<br />
Java 9 uses *.jmod to package libraries as modules. The Java 8 version of JDT can't handle modules and so can't recognize a Java 9 JRE/JDK. Unfortunately licensing issues prevent JDT distributing Java 9 support until Java 9 GA. Consequently use of Java 9 prior to GA is not as trivial as one might expect.<br />
<br />
There are several things you can do to check the readiness for Java 9.<br />
<br />
=== Configure Eclipse for Java 9 ===<br />
<br />
====Download Java 9====<br />
You need to download and install a Java 9 VM, e.g. from https://jdk9.java.net/. <br />
<br />
====Configure Eclipse to run on Java 9 VM====<br />
Unless you have Java 9 on your system path, you need to specify the use of your Java VM. If you already do this, simply replace it with a Java 9 VM. Otherwise it can easily be done by adding something like:<br />
<pre>-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe</pre><br />
following the ''--launcher.appendVmargs'' line to the eclipse.ini.<br />
<br />
====Configure Eclipse for Java 9 modules====<br />
Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to eclipse.ini:<br />
'''--add-modules=ALL-SYSTEM'''<br />
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default ({{bug|493761}}).<br />
Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules.<br />
* Only works in JDK 8, but not in JDK 9: Run <code>jdeps <i>fully.qualified.classname</i></code><br />
* In Eclipse with Java 9 Support (BETA) for Oxygen (see below), you can open the type in a JavaSE-9 JRE and perform Show In > Package Explorer. Inside the "JRE System Library" node, the Package Explorer will show the module in which that type resides.<br />
<br />
====eclipse.ini summary====<br />
Your eclipse.ini should contain something like:<br />
<pre>--launcher.appendVmargs<br />
-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe<br />
-vmargs<br />
-Dosgi.requiredJavaVersion=1.8<br />
--add-modules=ALL-SYSTEM</pre><br />
<br />
==== Install Eclipse Java 9 Support (BETA) ====<br />
This is useful if you have to debug problems, e.g. when it fails to run your project.<br />
<br />
This is essential if you want to run JUnit tests in the Eclipse IDE using Java 9.<br />
<br />
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. If you are not using an EPP with a pre-installed '''Marketplace Client''', you must install it first (from the '''General Purpose Tools''' category of the '''http://download.eclipse.org/releases/oxygen''' P2 repo).<br />
<br />
Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.<br />
<br />
==== Specify a Java 9 JRE ====<br />
Use Window->Preferences->Java->Install JREs to make your Java 9 VM available within Eclipse.<br />
<br />
You may want to associate Java 9 with some Execution Environments to force a rebuild using Java 9.<br />
<br />
=== Run your tests with Java 9 ===<br />
<br />
You can do this locally or soon on Hudson. A Java 9 VM will hopefully be available on Hudson soon ({{bug|513618}}). <br />
To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to [[#Install Eclipse Java 9 Support (BETA)|install]] the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.<br />
<br />
For JUnit (standalone) tests, you should specify a Java 9 execution environment on the JRE launch configuration tab.<br />
<br />
For JUnit Plugin tests, you should specify a Java 9 execution environment on the Main launch configuration tab and<br />
as noted above, you must add "--add-modules=java.se.ee" to the VM arguments on the Arguments tab..<br />
<br />
=== Check whether your project or required libraries use internals of the Java VM ===<br />
<br />
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called <code>jdeps(.exe)</code>. There are two ways you can check your code / repository:<br />
* There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)<br />
* The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.<br />
<br />
NOTE:<br />
<br />
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.<br />
<br />
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.<br />
<br />
=== Reflection hacks ===<br />
<br />
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.<br />
<br />
=== Java 9 Readiness ===<br />
<br />
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Project<br />
! scope="col"| Contact<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Adds Java 9 Support<br />
|-<br />
! Eclipse Project (Platform, JDT, PDE)<br />
| Dani Megert<br />
| Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis ({{bug|508734}}).<br />
| Yes, new code to support Java 9 development, compilation, and debugging will be delivered.<br />
|-<br />
! Web Tools Platform (WTP)<br />
| Carl Anderson<br />
| Not yet tested<br />
| Yes, new code to support Java 9 facets will be delivered<br />
|-<br />
! EclEmma<br />
| Evgeny Mandrikov<br />
| Yes<br />
| Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.<br />
|-<br />
! Code Recommenders<br />
| Andreas Sewe<br />
| Yes @ M7 (<s>{{bug|513634}}</s>)<br />
| Not planned yet (and blocked by {{bug|514393}}).<br />
|-<br />
! Automated Error Reporting<br />
| Andreas Sewe<br />
| Yes<br />
| n/a<br />
|-<br />
! Object Constraint Language (OCL)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Declarative QVT (QVTd)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Eclipse for Testers<br />
| Marvin Mueller<br />
| No / Yes if using "--permit-illegal-access"<br />
| Not planned yet.<br />
|-<br />
|}<br />
Known state of Orbit Bundles.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Bundle<br />
! scope="col"| Version<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Supports Java 9<br />
|-<br />
! com.google.guava<br />
| 15.0.0<br />
| Yes. All uses of <code>sun.misc.Unsafe</code> have a safe fallback.<br />
| n/a<br />
|-<br />
! org.objectweb.asm<br />
| 5.2.0<br />
| Yes<br />
| No. The ClassReader throws an IAE for greater than Opcodes.V1_8.<br />
Workaround: in JaCoCo - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L101<br />
This is safe, because Java 9 does not introduce any new instructions.<br />
Version can be restored after bytecode generation/modification - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L112<br />
|-<br />
! org.apache.felix.gogo.runtime<br />
| 0.10.0<br />
| {{bug|514939}}<br />
| n/a<br />
|-<br />
|-<br />
! .<br />
| .<br />
| .<br />
|}</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Java_9_Readiness&diff=415778Java 9 Readiness2017-04-07T13:09:24Z<p>Sewe.cqse.eu: </p>
<hr />
<div>This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each [[Simultaneous Release|release train]] project. The page also indicates which projects will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.<br />
<br />
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.<br />
<br />
Java 9 uses *.jmod to package libraries as modules. The Java 8 version of JDT can't handle modules and so can't recognize a Java 9 JRE/JDK. Unfortunately licensing issues prevent JDT distributing Java 9 support until Java 9 GA. Consequently use of Java 9 prior to GA is not as trivial as one might expect.<br />
<br />
There are several things you can do to check the readiness for Java 9.<br />
<br />
=== Configure Eclipse for Java 9 ===<br />
<br />
====Download Java 9====<br />
You need to download and install a Java 9 VM, e.g. from https://jdk9.java.net/. <br />
<br />
====Configure Eclipse to run on Java 9 VM====<br />
Unless you have Java 9 on your system path, you need to specify the use of your Java VM. If you already do this, simply replace it with a Java 9 VM. Otherwise it can easily be done by adding something like:<br />
<pre>-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe</pre><br />
following the ''--launcher.appendVmargs'' line to the eclipse.ini.<br />
<br />
====Configure Eclipse for Java 9 modules====<br />
Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to eclipse.ini:<br />
'''--add-modules=ALL-SYSTEM'''<br />
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default ({{bug|493761}}).<br />
Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules.<br />
* Only works in JDK 8, but not in JDK 9: Run <code>jdeps <i>fully.qualified.classname</i></code><br />
* In Eclipse with Java 9 Support (BETA) for Oxygen (see below), you can open the type in a JavaSE-9 JRE and perform Show In > Package Explorer. Inside the "JRE System Library" node, the Package Explorer will show the module in which that type resides.<br />
<br />
====eclipse.ini summary====<br />
Your eclipse.ini should contain something like:<br />
<pre>--launcher.appendVmargs<br />
-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe<br />
-vmargs<br />
-Dosgi.requiredJavaVersion=1.8<br />
--add-modules=ALL-SYSTEM</pre><br />
<br />
==== Install Eclipse Java 9 Support (BETA) ====<br />
This is useful if you have to debug problems, e.g. when it fails to run your project.<br />
<br />
This is essential if you want to run JUnit tests in the Eclipse IDE using Java 9.<br />
<br />
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. If you are not using an EPP with a pre-installed '''Marketplace Client''', you must install it first (from the '''General Purpose Tools''' category of the '''http://download.eclipse.org/releases/oxygen''' P2 repo).<br />
<br />
Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.<br />
<br />
==== Specify a Java 9 JRE ====<br />
Use Window->Preferences->Java->Install JREs to make your Java 9 VM available within Eclipse.<br />
<br />
You may want to associate Java 9 with some Execution Environments to force a rebuild using Java 9.<br />
<br />
=== Run your tests with Java 9 ===<br />
<br />
You can do this locally or soon on Hudson. A Java 9 VM will hopefully be available on Hudson soon ({{bug|513618}}). <br />
To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to [[#Install Eclipse Java 9 Support (BETA)|install]] the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.<br />
<br />
For JUnit (standalone) tests, you should specify a Java 9 execution environment on the JRE launch configuration tab.<br />
<br />
For JUnit Plugin tests, you should specify a Java 9 execution environment on the Main launch configuration tab and<br />
as noted above, you must add "--add-modules=java.se.ee" to the VM arguments on the Arguments tab..<br />
<br />
=== Check whether your project or required libraries use internals of the Java VM ===<br />
<br />
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called <code>jdeps(.exe)</code>. There are two ways you can check your code / repository:<br />
* There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)<br />
* The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.<br />
<br />
NOTE:<br />
<br />
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.<br />
<br />
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.<br />
<br />
=== Reflection hacks ===<br />
<br />
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.<br />
<br />
=== Java 9 Readiness ===<br />
<br />
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Project<br />
! scope="col"| Contact<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Adds Java 9 Support<br />
|-<br />
! Eclipse Project (Platform, JDT, PDE)<br />
| Dani Megert<br />
| Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis ({{bug|508734}}).<br />
| Yes, new code to support Java 9 development, compilation, and debugging will be delivered.<br />
|-<br />
! Web Tools Platform (WTP)<br />
| Carl Anderson<br />
| Not yet tested<br />
| Yes, new code to support Java 9 facets will be delivered<br />
|-<br />
! EclEmma<br />
| Evgeny Mandrikov<br />
| Yes<br />
| Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.<br />
|-<br />
! Code Recommenders<br />
| Andreas Sewe<br />
| Yes @ M7 (<s>{{bug|513634}}</s>)<br />
| Not planned yet (and blocked by {{bug|514393}}).<br />
|-<br />
! Automated Error Reporting<br />
| Andreas Sewe<br />
| Yes<br />
| n/a<br />
|-<br />
! Object Constraint Language (OCL)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Declarative QVT (QVTd)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Eclipse for Testers<br />
| Marvin Mueller<br />
| No / Yes if using "--permit-illegal-access"<br />
| Not planned yet.<br />
|-<br />
|}<br />
Known state of Orbit Bundles.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Bundle<br />
! scope="col"| Version<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Supports Java 9<br />
|-<br />
! com.google.guava<br />
| 15.0.0<br />
| Yes. All uses of <code>sun.misc.Unsafe</code> have a safe fallback.<br />
| n/a<br />
|-<br />
! org.objectweb.asm<br />
| 5.2.0<br />
| Yes<br />
| No. The ClassReader throws an IAE for greater than Opcodes.V1_8.<br />
Workaround: in JaCoCo - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L101<br />
This is safe, because Java 9 does not introduce any new instructions.<br />
Version can be restored after bytecode generation/modification - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L112<br />
|-<br />
! .<br />
| .<br />
| .<br />
|}</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Java_9_Readiness&diff=415472Java 9 Readiness2017-03-29T12:14:10Z<p>Sewe.cqse.eu: </p>
<hr />
<div>This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each [[Simultaneous Release|release train]] project. The page also indicates which projects will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.<br />
<br />
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.<br />
<br />
Java 9 uses *.jmod to package libraries as modules. The Java 8 version of JDT can't handle modules and so can't recognize a Java 9 JRE/JDK. Unfortunately licensing issues prevent JDT distributing Java 9 support until Java 9 GA. Consequently use of Java 9 prior to GA is not as trivial as one might expect.<br />
<br />
There are several things you can do to check the readiness for Java 9.<br />
<br />
=== Configure Eclipse for Java 9 ===<br />
<br />
====Download Java 9====<br />
You need to download and install a Java 9 VM, e.g. from https://jdk9.java.net/. <br />
<br />
====Configure Eclipse to run on Java 9 VM====<br />
Unless you have Java 9 on your system path, you need to specify the use of your Java VM. If you already do this, simply replace it with a Java 9 VM. Otherwise it can easily be done by adding something like:<br />
<pre>-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe</pre><br />
following the ''--launcher.appendVmargs'' line to the eclipse.ini.<br />
<br />
====Configure Eclipse for Java 9 modules====<br />
Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to eclipse.ini:<br />
'''--add-modules=ALL-SYSTEM'''<br />
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default ({{bug|493761}}).<br />
Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules.<br />
* Only works in JDK 8, but not in JDK 9: Run <code>jdeps <i>fully.qualified.classname</i></code><br />
* In Eclipse with Java 9 Support (BETA) for Oxygen (see below), you can open the type in a JavaSE-9 JRE and perform Show In > Package Explorer. Inside the "JRE System Library" node, the Package Explorer will show the module in which that type resides.<br />
<br />
====eclipse.ini summary====<br />
Your eclipse.ini should contain something like:<br />
<pre>--launcher.appendVmargs<br />
-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe<br />
-vmargs<br />
-Dosgi.requiredJavaVersion=1.8<br />
--add-modules=ALL-SYSTEM</pre><br />
<br />
==== Install Eclipse Java 9 Support (BETA) ====<br />
This is useful if you have to debug problems, e.g. when it fails to run your project.<br />
<br />
This is essential if you want to run JUnit tests in the Eclipse IDE using Java 9.<br />
<br />
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. If you are not using an EPP with a pre-installed '''Marketplace Client''', you must install it first (from the '''General Purpose Tools''' category of the '''http://download.eclipse.org/releases/oxygen''' P2 repo).<br />
<br />
Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.<br />
<br />
==== Specify a Java 9 JRE ====<br />
Use Window->Preferences->Java->Install JREs to make your Java 9 VM available within Eclipse.<br />
<br />
You may want to associate Java 9 with some Execution Environments to force a rebuild using Java 9.<br />
<br />
=== Run your tests with Java 9 ===<br />
<br />
You can do this locally or soon on Hudson. A Java 9 VM will hopefully be available on Hudson soon ({{bug|513618}}). <br />
To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to [[#Install Eclipse Java 9 Support (BETA)|install]] the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.<br />
<br />
For JUnit (standalone) tests, you should specify a Java 9 execution environment on the JRE launch configuration tab.<br />
<br />
For JUnit Plugin tests, you should specify a Java 9 execution environment on the Main launch configuration tab and<br />
as noted above, you must add "--add-modules=java.se.ee" to the VM arguments on the Arguments tab..<br />
<br />
=== Check whether your project or required libraries use internals of the Java VM ===<br />
<br />
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called <code>jdeps(.exe)</code>. There are two ways you can check your code / repository:<br />
* There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)<br />
* The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.<br />
<br />
NOTE:<br />
<br />
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.<br />
<br />
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.<br />
<br />
=== Reflection hacks ===<br />
<br />
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.<br />
<br />
=== Java 9 Readiness ===<br />
<br />
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Project<br />
! scope="col"| Contact<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Adds Java 9 Support<br />
|-<br />
! Eclipse Project (Platform, JDT, PDE)<br />
| Dani Megert<br />
| Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis ({{bug|508734}}).<br />
| Yes, new code to support Java 9 development, compilation, and debugging will be delivered.<br />
|-<br />
! Web Tools Platform (WTP)<br />
| Carl Anderson<br />
| Not yet tested<br />
| Yes, new code to support Java 9 facets will be delivered<br />
|-<br />
! EclEmma<br />
| Evgeny Mandrikov<br />
| Yes<br />
| Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.<br />
|-<br />
! Code Recommenders<br />
| Andreas Sewe<br />
| Yes @ M7 ({{bug|513634}})<br />
| Not planned yet (and blocked by {{bug|514393}} and {{bug|514394}}).<br />
|-<br />
! Automated Error Reporting<br />
| Andreas Sewe<br />
| Yes<br />
| n/a<br />
|-<br />
! Object Constraint Language (OCL)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Declarative QVT (QVTd)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! .<br />
| .<br />
| .<br />
| .<br />
|}<br />
Known state of Orbit Bundles.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Bundle<br />
! scope="col"| Version<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Supports Java 9<br />
|-<br />
! org.objectweb.asm<br />
| 5.2.0<br />
| Yes.<br />
| No. The ClassReader throws an IAE for greater than Opcodes.V1_8.<br />
Workaround: in JaCoCo - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L101<br />
This is safe, because Java 9 does not introduce any new instructions.<br />
Version can be restored after bytecode generation/modification - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L112<br />
|-<br />
! .<br />
| .<br />
| .<br />
|}</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Java_9_Readiness&diff=415241Java 9 Readiness2017-03-21T07:59:39Z<p>Sewe.cqse.eu: </p>
<hr />
<div>This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each [[Simultaneous Release|release train]] project. The page also indicates which projects will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.<br />
<br />
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.<br />
<br />
Java 9 uses *.jmod to package libraries as modules. The Java 8 version of JDT can't handle modules and so can't recognize a Java 9 JRE/JDK. Unfortunately licensing issues prevent JDT distributing Java 9 support until Java 9 GA. Consequently use of Java 9 prior to GA is not as trivial as one might expect.<br />
<br />
There are several things you can do to check the readiness for Java 9.<br />
<br />
=== Configure Eclipse for Java 9 ===<br />
<br />
====Download Java 9====<br />
You need to download and install a Java 9 VM, e.g. from https://jdk9.java.net/. <br />
<br />
====Configure Eclipse to run on Java 9 VM====<br />
Unless you have Java 9 on your system path, you need to specify the use of your Java VM. If you already do this, simply replace it with a Java 9 VM. Otherwise it can easily be done by adding something like:<br />
<pre>-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe</pre><br />
following the ''--launcher.appendVmargs'' line to the eclipse.ini.<br />
<br />
====Configure Eclipse for Java 9 modules====<br />
Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to eclipse.ini:<br />
'''--add-modules=ALL-SYSTEM'''<br />
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default ({{bug|493761}}).<br />
Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules.<br />
* Only works in JDK 8, but not in JDK 9: Run <code>jdeps <i>fully.qualified.classname</i></code><br />
* In Eclipse with Java 9 Support (BETA) for Oxygen (see below), you can open the type in a JavaSE-9 JRE and perform Show In > Package Explorer. Inside the "JRE System Library" node, the Package Explorer will show the module in which that type resides.<br />
<br />
====eclipse.ini summary====<br />
Your eclipse.ini should contain something like:<br />
<pre>--launcher.appendVmargs<br />
-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe<br />
-vmargs<br />
-Dosgi.requiredJavaVersion=1.8<br />
--add-modules=ALL-SYSTEM</pre><br />
<br />
==== Install Eclipse Java 9 Support (BETA) ====<br />
This is useful if you have to debug problems, e.g. when it fails to run your project.<br />
<br />
This is essential if you want to run JUnit tests in the Eclipse IDE using Java 9.<br />
<br />
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. If you are not using an EPP with a pre-installed '''Marketplace Client''', you must install it first (from the '''General Purpose Tools''' category of the '''http://download.eclipse.org/releases/oxygen''' P2 repo).<br />
<br />
Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.<br />
<br />
==== Specify a Java 9 JRE ====<br />
Use Window->Preferences->Java->Install JREs to make your Java 9 VM available within Eclipse.<br />
<br />
You may want to associate Java 9 with some Execution Environments to force a rebuild using Java 9.<br />
<br />
=== Run your tests with Java 9 ===<br />
<br />
You can do this locally or soon on Hudson. A Java 9 VM will hopefully be available on Hudson soon ({{bug|513618}}). <br />
To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to [[#Install Eclipse Java 9 Support (BETA)|install]] the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.<br />
<br />
For JUnit (standalone) tests, you should specify a Java 9 execution environment on the JRE launch configuration tab.<br />
<br />
For JUnit Plugin tests, you should specify a Java 9 execution environment on the Main launch configuration tab and<br />
as noted above, you must add "--add-modules=java.se.ee" to the VM arguments on the Arguments tab..<br />
<br />
=== Check whether your project or required libraries use internals of the Java VM ===<br />
<br />
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called <code>jdeps(.exe)</code>. There are two ways you can check your code / repository:<br />
* There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)<br />
* The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.<br />
<br />
NOTE:<br />
<br />
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.<br />
<br />
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.<br />
<br />
=== Reflection hacks ===<br />
<br />
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.<br />
<br />
=== Java 9 Readiness ===<br />
<br />
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Project<br />
! scope="col"| Contact<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Adds Java 9 Support<br />
|-<br />
! Eclipse Project (Platform, JDT, PDE)<br />
| Dani Megert<br />
| Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis ({{bug|508734}}).<br />
| Yes, new code to support Java 9 development, compilation, and debugging will be delivered.<br />
|-<br />
! Web Tools Platform (WTP)<br />
| Carl Anderson<br />
| Not yet tested<br />
| Yes, new code to support Java 9 facets will be delivered<br />
|-<br />
! EclEmma<br />
| Evgeny Mandrikov<br />
| Yes<br />
| Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.<br />
|-<br />
! Code Recommenders<br />
| Andreas Sewe<br />
| Yes @ M7 ({{bug|513634}})<br />
| Not planned yet.<br />
|-<br />
! Automated Error Reporting<br />
| Andreas Sewe<br />
| Yes<br />
| n/a (The [http://openjdk.java.net/jeps/259 JEP 259] Stack Walking API looked promising but doesn't work for logged <code>Throwable</code>s.)<br />
|-<br />
! Object Constraint Language (OCL)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Declarative QVT (QVTd)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! .<br />
| .<br />
| .<br />
| .<br />
|}<br />
Known state of Orbit Bundles.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Bundle<br />
! scope="col"| Version<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Supports Java 9<br />
|-<br />
! org.objectweb.asm<br />
| 5.2.0<br />
| Yes.<br />
| No. The ClassReader throws an IAE for greater than Opcodes.V1_8.<br />
Workaround: in JaCoCo - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L101<br />
This is safe, because Java 9 does not introduce any new instructions.<br />
Version can be restored after bytecode generation/modification - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L112<br />
|-<br />
! .<br />
| .<br />
| .<br />
|}</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Java_9_Readiness&diff=415240Java 9 Readiness2017-03-21T07:59:13Z<p>Sewe.cqse.eu: </p>
<hr />
<div>This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each [[Simultaneous Release|release train]] project. The page also indicates which projects will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.<br />
<br />
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.<br />
<br />
Java 9 uses *.jmod to package libraries as modules. The Java 8 version of JDT can't handle modules and so can't recognize a Java 9 JRE/JDK. Unfortunately licensing issues prevent JDT distributing Java 9 support until Java 9 GA. Consequently use of Java 9 prior to GA is not as trivial as one might expect.<br />
<br />
There are several things you can do to check the readiness for Java 9.<br />
<br />
=== Configure Eclipse for Java 9 ===<br />
<br />
====Download Java 9====<br />
You need to download and install a Java 9 VM, e.g. from https://jdk9.java.net/. <br />
<br />
====Configure Eclipse to run on Java 9 VM====<br />
Unless you have Java 9 on your system path, you need to specify the use of your Java VM. If you already do this, simply replace it with a Java 9 VM. Otherwise it can easily be done by adding something like:<br />
<pre>-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe</pre><br />
following the ''--launcher.appendVmargs'' line to the eclipse.ini.<br />
<br />
====Configure Eclipse for Java 9 modules====<br />
Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to eclipse.ini:<br />
'''--add-modules=ALL-SYSTEM'''<br />
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default ({{bug|493761}}).<br />
Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules.<br />
* Only works in JDK 8, but not in JDK 9: Run <code>jdeps <i>fully.qualified.classname</i></code><br />
* In Eclipse with Java 9 Support (BETA) for Oxygen (see below), you can open the type in a JavaSE-9 JRE and perform Show In > Package Explorer. Inside the "JRE System Library" node, the Package Explorer will show the module in which that type resides.<br />
<br />
====eclipse.ini summary====<br />
Your eclipse.ini should contain something like:<br />
<pre>--launcher.appendVmargs<br />
-vm<br />
C:\Program Files\Java\jdk-9\bin\javaw.exe<br />
-vmargs<br />
-Dosgi.requiredJavaVersion=1.8<br />
--add-modules=ALL-SYSTEM</pre><br />
<br />
==== Install Eclipse Java 9 Support (BETA) ====<br />
This is useful if you have to debug problems, e.g. when it fails to run your project.<br />
<br />
This is essential if you want to run JUnit tests in the Eclipse IDE using Java 9.<br />
<br />
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. If you are not using an EPP with a pre-installed '''Marketplace Client''', you must install it first (from the '''General Purpose Tools''' category of the '''http://download.eclipse.org/releases/oxygen''' P2 repo).<br />
<br />
Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.<br />
<br />
==== Specify a Java 9 JRE ====<br />
Use Window->Preferences->Java->Install JREs to make your Java 9 VM available within Eclipse.<br />
<br />
You may want to associate Java 9 with some Execution Environments to force a rebuild using Java 9.<br />
<br />
=== Run your tests with Java 9 ===<br />
<br />
You can do this locally or soon on Hudson. A Java 9 VM will hopefully be available on Hudson soon ({{bug|513618}}). <br />
To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to [[#Install Eclipse Java 9 Support (BETA)|install]] the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.<br />
<br />
For JUnit (standalone) tests, you should specify a Java 9 execution environment on the JRE launch configuration tab.<br />
<br />
For JUnit Plugin tests, you should specify a Java 9 execution environment on the Main launch configuration tab and<br />
as noted above, you must add "--add-modules=java.se.ee" to the VM arguments on the Arguments tab..<br />
<br />
=== Check whether your project or required libraries use internals of the Java VM ===<br />
<br />
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called <code>jdeps(.exe)</code>. There are two ways you can check your code / repository:<br />
* There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)<br />
* The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.<br />
<br />
NOTE:<br />
<br />
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.<br />
<br />
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.<br />
<br />
=== Reflection hacks ===<br />
<br />
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.<br />
<br />
=== Java 9 Readiness ===<br />
<br />
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Project<br />
! scope="col"| Contact<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Adds Java 9 Support<br />
|-<br />
! Eclipse Project (Platform, JDT, PDE)<br />
| Dani Megert<br />
| Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis ({{bug|508734}}).<br />
| Yes, new code to support Java 9 development, compilation, and debugging will be delivered.<br />
|-<br />
! Web Tools Platform (WTP)<br />
| Carl Anderson<br />
| Not yet tested<br />
| Yes, new code to support Java 9 facets will be delivered<br />
|-<br />
! EclEmma<br />
| Evgeny Mandrikov<br />
| Yes<br />
| Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.<br />
|-<br />
! Code Recommenders<br />
| Andreas Sewe<br />
| Yes @ M& ({{bug|513634}})<br />
| Not planned yet.<br />
|-<br />
! Automated Error Reporting<br />
| Andreas Sewe<br />
| Yes<br />
| n/a (The [http://openjdk.java.net/jeps/259 JEP 259] Stack Walking API looked promising but doesn't work for logged <code>Throwable</code>s.)<br />
|-<br />
! Object Constraint Language (OCL)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! Declarative QVT (QVTd)<br />
| Ed Willink<br />
| Yes @ M7.<br />
| n/a<br />
|-<br />
! .<br />
| .<br />
| .<br />
| .<br />
|}<br />
Known state of Orbit Bundles.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Bundle<br />
! scope="col"| Version<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Supports Java 9<br />
|-<br />
! org.objectweb.asm<br />
| 5.2.0<br />
| Yes.<br />
| No. The ClassReader throws an IAE for greater than Opcodes.V1_8.<br />
Workaround: in JaCoCo - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L101<br />
This is safe, because Java 9 does not introduce any new instructions.<br />
Version can be restored after bytecode generation/modification - see https://github.com/jacoco/jacoco/blob/v0.7.9/org.jacoco.core/src/org/jacoco/core/internal/Java9Support.java#L112<br />
|-<br />
! .<br />
| .<br />
| .<br />
|}</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Java_9_Readiness&diff=415040Java 9 Readiness2017-03-14T11:56:17Z<p>Sewe.cqse.eu: </p>
<hr />
<div>Test. This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each [[Simultaneous Release|release train]] project. The page also lists the projects that will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.<br />
<br />
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.<br />
<br />
There are several things you can do to check the readiness for Java 9.<br />
<br />
=== Run and test your project with Java 9 ===<br />
<br />
To do this you need to download a Java 9 VM, e.g. from https://jdk9.java.net/. Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to the eclipse.ini:<br />
'''--add-modules=java.se.ee'''<br />
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default ({{bug|493761}}).<br />
Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules. You can do this if you run Eclipse with Java 9 Support (BETA) for Oxygen (see below) and then just open the type and perform Show In > Package Explorer. The Package Explorer will show the module in which that type resides.<br />
<br />
=== Run your tests with Java 9 ===<br />
<br />
You can do this locally or on Hudson. A Java 9 VM is installed on Hudson ({{bug|469515}}). <br />
To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to [[#Running Eclipse with Java 9 Support (BETA)|install]] the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.<br />
<br />
=== Check whether your project or required libraries use internals of the Java VM ===<br />
<br />
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called <code>jdeps(.exe)</code>. There are two ways you can check your code / repository:<br />
* There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)<br />
* The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.<br />
<br />
NOTE:<br />
<br />
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.<br />
<br />
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.<br />
<br />
=== Reflection hacks ===<br />
<br />
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.<br />
<br />
=== Running Eclipse with Java 9 Support (BETA) ===<br />
<br />
This is useful if you have to debug problems, e.g. when it fails to run your project.<br />
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.<br />
<br />
=== Java 9 Readiness ===<br />
<br />
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Project<br />
! scope="col"| Contact<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Adds Java 9 Support<br />
|-<br />
! Eclipse Project (Platform, JDT, PDE)<br />
| Dani Megert<br />
| Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis ({{bug|508734}}).<br />
| Yes, new code to support Java 9 development, compilation, and debugging will be delivered.<br />
|-<br />
! Web Tools Platform (WTP)<br />
| Carl Anderson<br />
| Not yet tested<br />
| Yes, new code to support Java 9 facets will be delivered<br />
|-<br />
! EclEmma<br />
| Evgeny Mandrikov<br />
| Yes<br />
| Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.<br />
|-<br />
! Code Recommenders<br />
| Andreas Sewe<br />
| Planned but still buggy, mostly due to use of reflection in Gson 2.7 ({{bug|513634}})<br />
| Not planned yet.<br />
|-<br />
! Automated Error Reporting<br />
| Andreas Sewe<br />
| Yes<br />
| n/a (The [http://openjdk.java.net/jeps/259 JEP 259] Stack Walking API looked promising but doesn't work for logged <code>Throwable</code>s.)<br />
|-<br />
! .<br />
| .<br />
| .<br />
| .<br />
|}</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Java_9_Readiness&diff=415039Java 9 Readiness2017-03-14T10:39:31Z<p>Sewe.cqse.eu: </p>
<hr />
<div>Test. This wiki page explains how projects can check whether they are ready for Java 9 and documents the state for each [[Simultaneous Release|release train]] project. The page also lists the projects that will provide new support for Java 9, e.g. Eclipse JDT. Those projects are expected to contribute to what we will offer once Java 9 goes GA. Note that at this point, the Planning Council did not yet decide how to do that.<br />
<br />
The biggest feature in Java 9 is the Java Platform Module System, a.k.a. Jigsaw. With this, access to internal code of the Java runtime will no longer work. The Planning Council requests every release train project to check whether they use internal code from the Java runtime, or whether they use a library (most likely from Orbit), that does so.<br />
<br />
There are several things you can do to check the readiness for Java 9.<br />
<br />
=== Run and test your project with Java 9 ===<br />
<br />
To do this you need to download a Java 9 VM, e.g. from https://jdk9.java.net/. Since the Eclipse SDK uses types that aren't in the java.base module, you need to add the following vmargs to the eclipse.ini:<br />
'''--add-modules=java.se.ee'''<br />
This step will no longer be necessary with 4.7 M7 and newer, as the launcher will add this by default ({{bug|493761}}).<br />
Your project might fail to run because you use types that are neither in java.base or java.se.ee, e.g. types from javafx.base. In that case you have to figure out which module(s) you need to add with --add-modules. You can do this if you run Eclipse with Java 9 Support (BETA) for Oxygen (see below) and then just open the type and perform Show In > Package Explorer. The Package Explorer will show the module in which that type resides.<br />
<br />
=== Run your tests with Java 9 ===<br />
<br />
You can do this locally or on Hudson. A Java 9 VM is installed on Hudson ({{bug|469515}}). <br />
To launch tests or self-hosted applications locally from your IDE with a Java 9 JRE, you need to [[#Running Eclipse with Java 9 Support (BETA)|install]] the Java 9 BETA support to configure an Installed JRE that points at a Java 9 JRE or JDK.<br />
<br />
=== Check whether your project or required libraries use internals of the Java VM ===<br />
<br />
Since Java 8 there is a tool that allows you to check whether you use internals of the Java VM. It is called <code>jdeps(.exe)</code>. There are two ways you can check your code / repository:<br />
* There is an Apache Maven JDeps Plugin (https://maven.apache.org/plugins/maven-jdeps-plugin/)<br />
* The Eclipse Platform project has created a script (https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/plain/production/reports/jdepsReport.sh) that calls jdeps during the build and generates a report. I suggest to use that approach. Please contact Sravan Lakkimsetti if you have any problems with this script.<br />
<br />
NOTE:<br />
<br />
1) We made an initial scan of the Oxygen (4.7) M5 release train repository and most of the violations are in third-party code. You have to work with the providers of the libraries to get this fixed or find an alternative approach.<br />
<br />
2) https://wiki.openjdk.java.net/display/JDK8/Java+Dependency+Analysis+Tool lists alternatives that can be used instead of the internal code. You can see in this list that there's not a replacement for every issue, e.g. sun.misc.Unsafe has no replacement and continues to work, at least for now.<br />
<br />
=== Reflection hacks ===<br />
<br />
Unfortunately jdeps does not detect access to internals made via reflection. You have to check your code for such cases and fix them.<br />
<br />
=== Running Eclipse with Java 9 Support (BETA) ===<br />
<br />
This is useful if you have to debug problems, e.g. when it fails to run your project.<br />
We recommend to install the support via https://marketplace.eclipse.org/content/java-9-support-beta-oxygen/ because it is crucial that the Eclipse install, the Java 9 VM and the patch match. Another way to install it is to use Ed's Oomph based installer described here: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg14178.html.<br />
<br />
=== Java 9 Readiness ===<br />
<br />
If a release train project is not listed here, it means it has not been checked yet, and you have to assume it won't run on Java 9. If something does not work, it should be covered by a bug report.<br />
<br />
{| class="wikitable"<br />
|-<br />
! scope="col"| Project<br />
! scope="col"| Contact<br />
! scope="col"| Runs on Java 9<br />
! scope="col"| Adds Java 9 Support<br />
|-<br />
! Eclipse Project (Platform, JDT, PDE)<br />
| Dani Megert<br />
| Yes, but the module java.se.ee needs to be added and we have an open issue with some Platform UI tests due to org.objenesis ({{bug|508734}}).<br />
| Yes, new code to support Java 9 development, compilation, and debugging will be delivered.<br />
|-<br />
! Web Tools Platform (WTP)<br />
| Carl Anderson<br />
| Not yet tested<br />
| Yes, new code to support Java 9 facets will be delivered<br />
|-<br />
! EclEmma<br />
| Evgeny Mandrikov<br />
| Yes<br />
| Yes, ability to measure code coverage by tests that are executed on Java 9 will be delivered.<br />
|-<br />
! Code Recommenders<br />
| Andreas Sewe<br />
| Planned but still buggy, mostly due to use of reflection in Gson 2.7 ({{bug|513634}})<br />
| Not planned yet.<br />
|-<br />
! .<br />
| .<br />
| .<br />
| .<br />
|}</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/1.0.0&diff=413334Tycho/Release Notes/1.0.02017-01-11T15:07:15Z<p>Sewe.cqse.eu: Fix Bugzilla link</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css> <br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/0.26|&lt; Previous Version]] | Next Version &gt;</div> <br />
<br />
== SNAPSHOT builds ==<br />
<br />
Tycho 0.27.0 is currently in development. To try out the most recent snapshot build of 0.27.0, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>0.27.0-SNAPSHOT</tt>.<br />
<br />
<pre><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</pre><br />
<br />
=== SNAPSHOT site docs ===<br />
<br />
Refer to the [https://hudson.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/index.html latest SNAPSHOT site docs for Tycho] and [https://hudson.eclipse.org/tycho/job/tycho.extras-sitedocs/ws/target/staging/index.html Tycho Extras].<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&resolution=FIXED&target_milestone=1.0.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 1.0.0]<br />
<br />
<br />
=== p2 ===<br />
<br />
* packaging type <tt>eclipse-repository</tt> will now add MD5 checksums to artifact metadata of the p2 repository created (<strike>[https://bugs.eclipse.org/bugs/show_bug.cgi?id=357513 bug 357513]</strike>)<br />
<br />
=== Mirroring using URL prefix ===<br />
* It's now possible to mirror multiple repositories using one mirror definition. Example: [https://wiki.eclipse.org/Tycho/Target_Platform/Authentication_and_Mirrors#Mirroring_multiple_Repositories Mirroring multiple Repositories] (<strike>[https://bugs.eclipse.org/bugs/show_bug.cgi?id=501809 bug 501809]</strike>).<br />
<br />
=== Breaking changes ===<br />
<br />
* tycho-compiler-plugin's [https://www.eclipse.org/tycho/sitedocs/tycho-compiler-plugin/compile-mojo.html#useProjectSettings <tt>useProjectSettings</tt>] default value is now <tt>true</tt> so that <tt>.settings/org.eclipse.jdt.core.prefs</tt> are used by default if existing.<br />
<br />
[[Category:Tycho|Release Notes/0.27]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes&diff=408535Tycho/Release Notes2016-08-08T07:56:51Z<p>Sewe.cqse.eu: Fixed links to 0.26.0</p>
<hr />
<div>The latest milestone release of Tycho is [[Tycho/Release Notes/0.25|0.25.0]]. There are no releases as defined by the [http://www.eclipse.org/projects/dev_process/development_process_2011.php Eclipse Development Process] yet.<br />
<br />
Tycho [[Tycho/Release Notes/0.26|0.26.0]] is currently under development.<br />
<br />
==== List of milestone releases ====<br />
<br />
* [[Tycho/Release Notes/0.11|0.11.x]] (2011-04-07, 2011-04-22)<br />
* [[Tycho/Release Notes/0.12|0.12.0]] (2011-05-02)<br />
* [[Tycho/Release Notes/0.13|0.13.0]] (2011-09-22)<br />
* [[Tycho/Release Notes/0.14|0.14.x]] (2012-02-14, 2012-02-28)<br />
* [[Tycho/Release Notes/0.15|0.15.0]] (2012-06-01)<br />
* [[Tycho/Release Notes/0.16|0.16.0]] (2012-10-19)<br />
* [[Tycho/Release Notes/0.17|0.17.0]] (2013-03-22)<br />
* [[Tycho/Release Notes/0.18|0.18.0]] (2013-05-29)<br />
* [[Tycho/Release Notes/0.19|0.19.0]] (2013-10-28)<br />
* [[Tycho/Release Notes/0.20|0.20.0]] (2014-03-14)<br />
* [[Tycho/Release Notes/0.21|0.21.0]] (2014-07-23)<br />
* [[Tycho/Release Notes/0.22|0.22.0]] (2014-11-24)<br />
* [[Tycho/Release Notes/0.23|0.23.0 and 0.23.1]]<br />
* [[Tycho/Release Notes/0.24|0.24.0]]<br />
* [[Tycho/Release Notes/0.25|0.25.0]] (2016-04-15)<br />
<br />
[[Category:Tycho|Release Notes]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/0.26&diff=408239Tycho/Release Notes/0.262016-08-01T14:23:22Z<p>Sewe.cqse.eu: Document incompatible change to tycho-eclipserun-plugin:run mojo (Bug 498180)</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css> <br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/0.25|&lt; Previous Version]] | Next Version &gt;</div> <br />
<br />
== SNAPSHOT builds ==<br />
<br />
Tycho 0.26.0 is currently in development. To try out the most recent snapshot build of 0.26.0, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>0.26.0-SNAPSHOT</tt>.<br />
<br />
<pre><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</pre><br />
<br />
=== SNAPSHOT site docs ===<br />
<br />
Refer to the [https://hudson.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/index.html latest SNAPSHOT site docs for Tycho] and [https://hudson.eclipse.org/tycho/job/tycho.extras-sitedocs/ws/target/staging/index.html Tycho Extras].<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&resolution=FIXED&target_milestone=0.26.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 0.26.0]<br />
<br />
<br />
=== TestNG support ===<br />
The Tycho Surefire Plug-in does now support running tests with the [http://testng.org TestNG] framework. In order to use TestNG you have to:<br />
<br />
==== Provide TestNG as OSGi Bundle ====<br />
Because TestNG is not an OSGi Bundle, you have to provide the TestNG classes and it's dependencies (currently only com.beust.jcommander) as OSGi bundles by either include the jars into your test plugin and export the TestNG java packages so that the Tycho Surefire Plugin can see them or create a separate Eclipse Plug-in ("Plug-in from Existing JAR Archives" Wizard) that contains the jars. Make sure the TestNG java packages are exported. Add this newly created Plug-in as a dependency to all your Test Plug-ins /Fragments.<br />
<br />
==== Configure Tycho Surefire Plug-in====<br />
The TestNG framework provider has to be enabled by setting the <providerHint> configuration value to "testng". Within TestNG tests it is common to use java assertions, so you might also have to enable assertions. Example configuration:<br />
<br />
<build><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>tycho-surefire-plugin</artifactId><br />
<version>${tycho.version}</version><br />
<configuration><br />
<providerHint>testng</providerHint><br />
<argLine>-ea</argLine><br />
</configuration><br />
</plugin><br />
</build><br />
<br />
==== Using Test Suites ====<br />
If you want to use test suites you could configure the suite files you want to execute by specifing the suite xml files within the configuration:<br />
<br />
<build><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>tycho-surefire-plugin</artifactId><br />
<version>${tycho.version}</version><br />
<configuration><br />
<providerHint>testng</providerHint><br />
<argLine>-ea</argLine><br />
<suiteXmlFiles><br />
<suiteXmlFile>mysuite1.xml</suiteXmlFile><br />
<suiteXmlFile>mysuite2.xml</suiteXmlFile><br />
</suiteXmlFiles><br />
</configuration><br />
</plugin><br />
</build><br />
<br />
==== Using Groups ====<br />
If you want to use groups within your TestNG tests, you have to configure one additional thing. Because of the way TestNG and the Surefire TestNG Plug-in do select the test groups that should be executed, the Plug-in that exports the <tt>org.testng</tt> packages must be able to load a class from the Surefire TestNG Plug-in. With the OSGi Classloader this is only possible if you dynamically import that package in the plugin you export the TestNG packages. Within the MANIFEST.MF file of that Plug-in add <br />
<br />
DynamicImport-Package: org.apache.maven.surefire.testng.utils<br />
<br />
To execute specific groups you could add the group names within the plugin configuration<br />
<br />
<build><br />
<plugin><br />
<groupId>org.eclipse.tycho</groupId><br />
<artifactId>tycho-surefire-plugin</artifactId><br />
<version>${tycho.version}</version><br />
<configuration><br />
<providerHint>testng</providerHint><br />
<argLine>-ea</argLine><br />
<groups>myGroup1,myGroup2</groups><br />
</configuration><br />
</plugin><br />
</build><br />
<br />
=== New option to check consistency of .target files ===<br />
<br />
The [https://www.eclipse.org/tycho/sitedocs-extras/target-platform-validation-plugin/plugin-info.html target-platform-validation-plugin] now features a new option flag <tt>checkProvisioning</tt> which will evaluate whether the content of the .target file can be provisioned all together. It checks for dependencies availability, non-conflicting versions of included installation units, and all kinds of errors usually reported by p2 director.<br />
[[Category:Tycho|Release Notes/0.26]]<br />
<br />
=== Execution environment for Forked EclipseRun Run ===<br />
<br />
* <font color="red">(INCOMPATIBLE CHANGE)</font> The <tt>&lt;executionEnvironment&gt;</tt> parameter of the [https://www.eclipse.org/tycho/sitedocs-extras/tycho-eclipserun-plugin/eclipse-run-mojo.html tycho-eclipserun-plugin:run mojo] is used not only to resolve the forked run's dependencies but also to select the execution environment to run it with. Previously the execution enviroment from the configured [http://maven.apache.org/guides/mini/guide-using-toolchains.html toolchain] (if any) was used, with a fallback on the execution environment that ran the build. Using the <tt>&lt;executionEnvironment&gt;</tt> parameter to select the execution environment allows one to, e.g., use a newer execution environment for the forked run than is used for the main build (<strike>[https://bugs.eclipse.org/bugs/show_bug.cgi?id=498180 bug 498180]</strike>).</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Development_Resources/HOWTO/Review_Process&diff=401167Development Resources/HOWTO/Review Process2016-02-03T16:11:50Z<p>Sewe.cqse.eu: Clarified condition for inclusion in the reviews and announcements RSS feed (started vs. scheduled). See https://bugs.eclipse.org/bugs/show_bug.cgi?id=485446 for background.</p>
<hr />
<div># Schedule the review by sending email to emo@eclipse.org<br />
#* Reviews are scheduled to start on a Wednesday and end one week later (occurring over five generally-accepted business days)<br />
# At least one week in advance of the review, you (project or proposal lead) sends the documentation to emo@eclipse.org for posting.<br />
#* The EMO posts the documentation via the website (through the wonders of database-driven web pages, the documentation is automatically linked from the review notice/the proposal).<br />
#* Note that, for reviews that result in changes in the IP status of a project ([[Development_Resources/HOWTO/Review_Information_for_Project_Leads#Release_Reviews |Release]], [[Development_Resources/HOWTO/Review_Information_for_Project_Leads#Graduation_Reviews |Graduation]], and most [[Development_Resources/HOWTO/Review_Information_for_Project_Leads#Restructuring_Reviews |Restructuring]] Reviews), you are required to submit your project's [[Development Resources/IP Log | IP Log]] for review. EMO will not schedule your review until your IP Log has been approved by the EMO IP Team.<br />
# The EMO announces the reviews:<br />
#* via the [http://www.eclipse.org/projects/whatsnew.php eclipse.org/projects what's new web page] (as soon as the review is scheduled)<br />
#* via the [http://www.eclipse.org/projects/reviews-rss.php reviews and announcements RSS feed] (as soon as the review period starts)<br />
#* via email to the committers and membership-at-large mailing lists (at least one week in advance of the scheduled review conference call)<br />
#A review is declared complete when the review period has expired<br />
#* The EMO will review discussion in the designated communication channel<br />
#* The review is considered successful when it has been determined that issues raised by the community have adequately addressed.<br />
<br />
''This page is moderated by the EMO''<br />
[[Category:Development_Resources]]<br />
[[Category:How to Contribute]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Tycho/Release_Notes/0.24&diff=388731Tycho/Release Notes/0.242015-07-16T11:20:29Z<p>Sewe.cqse.eu: Add workaround to Bug 472802</p>
<hr />
<div><css><br />
#main-page-content{ position:relative; }<br />
#versionNav{ position:absolute; top: 0px; right: 0px; border-color: transparent; background: transparent; }<br />
</css> <br />
<div id="versionNav" class="alert alert-small alert-warning">[[Tycho/Release Notes/0.23|&lt; Previous Version]] | Next Version &gt;</div> <br />
<br />
== SNAPSHOT builds ==<br />
<br />
To try out the most recent snapshot build of 0.24.0, simply add the following snippet to your (parent) pom.xml or settings.xml, and set the property for the Tycho version (e.g. <tt>tycho-version</tt>) to <tt>0.24.0-SNAPSHOT</tt>.<br />
<br />
<pre><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</pre><br />
<br />
=== SNAPSHOT site docs ===<br />
<br />
Refer to the [https://hudson.eclipse.org/tycho/job/tycho-sitedocs/ws/target/staging/index.html latest SNAPSHOT site docs for Tycho] and [https://hudson.eclipse.org/tycho/job/tycho.extras-sitedocs/ws/target/staging/index.html Tycho Extras].<br />
<br />
== New and Noteworthy ==<br />
<br />
[https://bugs.eclipse.org/bugs/buglist.cgi?classification=Technology&product=Tycho&query_format=advanced&resolution=FIXED&target_milestone=0.24.0&order=bug_id&query_based_on= Complete list of bug fixes and enhancements in 0.24.0]<br />
<br />
=== POM-less Tycho builds ===<br />
<br />
* A [http://takari.io/2015/03/19/core-extensions.html maven core build extension] has been added to support (almost) pom-less builds of eclipse plugins and features ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=462531 bug 462531]). <br/> To enable it,<br />
** Requires [http://maven.apache.org/download.cgi maven 3.3+]<br />
** Add a <tt>.mvn/extensions.xml</tt> descriptor to the root of your build:<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<extensions><br />
<extension><br />
<groupId>org.eclipse.tycho.extras</groupId><br />
<artifactId>tycho-pomless</artifactId><br />
<version>0.24.0-SNAPSHOT</version><br />
</extension><br />
</extensions><br />
</pre><br />
** If testing a SNAPSHOT of Tycho, add the SNAPSHOT build repository to your <tt>~/.m2/settings.xml</tt>:<br />
<pre><br />
<settings><br />
...<br />
<profiles><br />
<profile><br />
<id>tycho-snapshots</id><br />
<pluginRepositories><br />
<pluginRepository><br />
<id>tycho-snapshots</id><br />
<url>https://repo.eclipse.org/content/repositories/tycho-snapshots/</url><br />
</pluginRepository><br />
</pluginRepositories><br />
</profile><br />
</profiles><br />
<activeProfiles><br />
<activeProfile>tycho-snapshots</activeProfile><br />
</activeProfiles><br />
...<br />
</settings><br />
</pre><br />
** The parent pom for features and plugins must reside in the parent directory<br />
** features and plugins do not require <tt>pom.xml</tt> anymore. If no <tt>pom.xml</tt> is provided, the maven project model is derived as follows:<br />
*** <tt>groupId</tt>: inherited from parent<br />
*** <tt>arifactId</tt>: Bundle-SymbolicName from <tt>META-INF/MANIFEST.MF</tt> or feature id from <tt>feature.xml</tt><br />
*** <tt>version</tt>: <tt>Bundle-Version</tt> from <tt>META-INF/MANIFEST.MF</tt> or feature version from <tt>feature.xml</tt> (with <tt>.qualifier</tt> suffix replaced by <tt>-SNAPSHOT</tt>)<br />
*** <tt>packaging</tt>:<br />
**** <tt>eclipse-plugin</tt> if <tt>META-INF/MANIFEST.MF</tt> found<br />
**** <tt>eclipse-feature</tt> if <tt>feature.xml</tt> found<br />
**** <tt>eclipse-test-plugin</tt> if <tt>Bundle-SymbolicName</tt> ending with <tt>.tests</tt> found in <tt>META-INF/MANIFEST.MF</tt> <br />
** At minimum a parent (and aggregator) pom is still required which configures Tycho, the modules to build, the p2 repositories used etc. as this cannot be derived from <tt>feature.xml</tt> or <tt>MANIFEST.MF</tt><br />
** you can still use <tt>pom.xml</tt> for plugins and features in case you want to configure more than the above defaults<br />
** See the [http://git.eclipse.org/c/tycho/org.eclipse.tycho.extras.git/tree/tycho-extras-its/src/test/resources/testpomless sample build] used by the integration tests<br />
<br />
=== compare-version-with-baselines mojo ===<br />
<br />
<tt>org.eclipse.tycho.extras:tycho-p2-extras-plugin</tt> plugin features a new <tt>compare-version-with-baselines</tt> mojo that allows to verify that the version of the just-build artifacts doesn't break some basic rules of OSGi versioning. It will make the build of your artifact fail if:<br />
* artifact has lower version than what exists in baseline<br />
* artifact has same major.minor.micro version than what exists in baseline<br />
* artifact has same fully qualified (major.minor.micro.qualifier version) than what exists in baseline, but with different binary content.<br />
<br />
This is used in order to guarantee necessary version bumps have been applied, and this is compliant with the [[../../Reproducible Version Qualifiers]] strategy.<br />
<br />
See [http://git.eclipse.org/c/tycho/org.eclipse.tycho.extras.git/tree/tycho-p2-extras-plugin/src/it/baseline/pom.xml#n33 IT tests] for an example of usage.<br />
<br />
[[Category:Tycho|Release Notes/0.24]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Mars_2015/Niedersachsen&diff=385707Eclipse DemoCamps Mars 2015/Niedersachsen2015-06-02T16:55:28Z<p>Sewe.cqse.eu: Updated title of my talk on code search</p>
<hr />
<div>[[File:marsbanner_bs.jpg]]<br />
<br />
=== Registration ===<br />
<br />
The ticket registration is now open at [http://eclipse-democamp-mars-bs.eventbrite.com Eventbrite]<br />
<br />
=== Location ===<br />
<br />
Haus der Wissenschaft <br><br />
Pockelsstr. 11<br><br />
38106 Braunschweig<br><br />
Tel. 0531/391-4114<br><br />
Fax 0531/391-4108<br><br />
raum@hausderwissenschaft.org<br><br />
[http://www.hausderwissenschaft.org www.hausderwissenschaft.org]<br><br />
<br />
=== Date and Time ===<br />
<br />
4th June - 6pm | 19:00 Uhr<br />
<br />
=== Organizers ===<br />
<br />
Jonathan Beddig, [http://www.bredex.de BREDEX GmbH] <br />
Stefan Reichert, [http://www.zühlke.com/de Zühlke]<br />
<br />
=== Sponsors ===<br />
<br />
[[Image:Bredex.png]][http://www.bredex.de BREDEX GmbH] <br />
<br><br />
[[Image:Zuehlke Logo rgb 100 2.png]] [http://www.zuehlke.com Zühlke Engineering]<br><br />
<br />
=== Agenda ===<br />
<br><br />
19:00 - get together<br><br />
19:20 - Begrüßung durch Jonathan Beddig und Stefan Reichert<br><br />
<br><br />
'''20 Minutes Talks & Demos''' (please leave 5 minutes in between the talks)<br><br />
19:30 - How to share & install your Eclipse Setup easily<br><br />
19:55 - Xtext integration for IntelliJ and web apps<br><br />
20:00 - Jubila API<br><br />
<br><br />
- Pause - <br><br />
<br><br />
21:00 - Eidola, a Blackbox UI-Testing approach<br><br />
21:25 - You search all your life (as a software developer): Introducing Codetrails Ctrlflow<br><br />
<br><br />
- Networking & open end -<br><br />
<br><br />
<br />
=== Presenters ===<br />
<br />
If you would like to present at this event, please add your name below.<br />
<br />
* Andreas Sewe, [http://www.codetrails.com/ Codetrails GmbH] (You search all your life (as a software developer): Introducing Codetrails Ctrlflow)<br />
* Olaf Gunkel and Matthias Schmidt, [http://seblog.cs.uni-kassel.de/ University of Kassel] (UI Testing DSL)<br />
* Sebastian Struckmann, [http://www.bredex.de BREDEX GmbH] (Jubula Client API for writing tests in Java)<br />
* Miro Sp&ouml;nemann, [http://www.itemis.de/ itemis AG] (Xtext integration for IntelliJ and web apps)<br />
* Frederic Ebelshäuser, [http://www.yatta.de/ Yatta Solutions GmbH] (How to share & install your Eclipse Setup easily)</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Development_Resources/HOWTO/Release_Reviews&diff=384295Development Resources/HOWTO/Release Reviews2015-05-20T15:59:57Z<p>Sewe.cqse.eu: Fixed link to project download scanner (see Bug 467731)</p>
<hr />
<div>{{Warning|See <br />
"[http://www.eclipse.org/projects/dev_process/development_process.php#6_3_3_Release_Review 6.3.3 Release Review]" and "[http://www.eclipse.org/projects/dev_process/development_process.php#6_3_Reviews 6.3 Reviews]" in the Eclipse Development Process.}}<br />
''The purposes of a Release Review are: to summarize the accomplishments of the release, to verify that the IP Policy has been followed and all approvals have been received, to highlight any remaining quality and/or architectural issues, and to verify that the project is continuing to operate according to the Principles and Purposes of Eclipse.''<br />
<br />
=Overview=<br />
<br />
Please see [[Development Resources/HOWTO/Release Cycle|the release cycle]], which includes a nice (simple) overview of the [[Development Resources/HOWTO/Release Cycle#Release_Review|release review process]].<br />
<br />
[[Image:ReleaseReview.png|center]]<br />
<br />
Helpful Documentation from the [http://www.eclipse.org/projects/dev_process/development_process.php Eclipse Development Process]<br />
* [http://www.eclipse.org/projects/dev_process/development_process.php#6_3_3_Release_Review About Release Reviews] <br />
* [http://www.eclipse.org/projects/dev_process/release-review.php Guidelines for Release Reviews]<br />
<br />
==Reviews are Not Required for Service Releases==<br />
Note that a release review is '''not''' required for a service--or "bug fix only"--release. If your release contains no new features, APIs, or significant changes in functionality, you may release it without engaging in a community review. You should still create the release record in the [[Project Management Infrastructure/Release Metadata|PMI]] to notify your community. Service releases are indicated by an increment in the third segment of the version number (e.g. 2.3.'''2''').<br />
<br />
Note also that projects are not required to submit IP logs for review by the IP Team for service releases. Projects are required to ensure that they have the appropriate coverage for all intellectual property (e.g. CQs and contribution records) at all times.<br />
<br />
==Intellectual Property==<br />
Before you can consider a Release Review, all of the relevant CQs must be approved by the Eclipse Legal team. We cannot schedule a Review before the Legal team has completed their work. If you are waiting for CQs, please review where your CQs are, and when they are scheduled to be reviewed, in the [https://dev.eclipse.org/ipzilla/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=IP%20Team%20Work%20Queue&sharer_id=854 IP team work queue].<br />
<br />
After you have verified that all relevant CQs are approved, the following items must be completed '''at least one week before the scheduled review date''':<br />
# PMC Approval ''(Can occur in parallel with, prior to, and after, the IP clearance)'';<br />
# [[Development Resources/IP Log | IP Log]] Approval '''This is essential, and no release review can proceed without it!'''; and<br />
# Review document.<br />
<br />
===IP Log Approval===<br />
Because IP Log approval is essential and can take varying amounts of time (depending on the work queue of the IP Team), projects '''must''' have an approved IP Log before their review date is confirmed. After you have submitted the IP Log to Eclipse Legal for approval, the review is added to the schedule with the notation ''Waiting for IP Log.'' After EMO is notified that the IP Log is approved, that notation is replaced with the date of the review.<br />
<br />
Please use the automated IP Log Tool to update and and submit your IP Log. You can use the [[Development Resources/Automatic IP Log|IP Log Generator]] for this (the [[Development Resources/Automatic IP Log#Submitting the IP Log to Eclipse Legal|Submitting the IP Log to Eclipse Legal]] section explains how to submit the IP Log). The URL for using the tool for your project uses your '''project ID''', in this format: ''<nowiki>http://www.eclipse.org/projects/ip_log.php?projectid=</nowiki>'''project ID'''.<br />
<br />
Before submitting your IP Log, we recommend that you review the contents of your project's download directory to ensure that you have the necessary CQs in place. The [https://www.eclipse.org/projects/tools/downloads.php Project Downloads Review] tool can help you in with this review.<br />
<br />
While you are waiting for IP Log approval, we suggest that you obtain PMC approval for the review and begin work on your documentation.<br />
<br />
== PMC Approval ==<br />
Please forward an email showing that you have the approval of your PMC for the review and corresponding review documentation. The easiest way to do this is to request approval on your PMC mailing list (which requires subscription) and forward the response to EMO.<br />
<br />
Note that you do not have to wait for the IP Log to be approved by the IP Team. You can seek PMC review/approval of your review documentation while the IP Log separate from the IP log approval process.<br />
<br />
== Project Plan ==<br />
Your [[Development Resources/Project Plan|project plan]] must be current and available for public consumption.<br />
<br />
== Review Documentation ==<br />
<br />
The content requirements for review documentation are detailed below. The preferred means of providing review documentation is to enter it directly into the record associated with your release in the [[Project Management Infrastructure/Release Metadata|project metadata]].<br />
<br />
=== Alternative Formats===<br />
<br />
In the past, a presentation file (PPT or ODP) rendered in PDF from was the preferred format for review documentation (we used to host actual review calls for which the presentation format was appropriate). Presentation files are still acceptable (and are quite common). Other open formats, including HTML, a wiki page, or a document file rendered in PDF format, are also acceptable.<br />
<br />
Please submit your document via email to the [mailto:emo@eclipse.org EMO]. Include the review document as either a link or an attachment.<br />
<br />
Many people underestimate the time and effort needed to create the document, so be sure to allow enough time for this task. The "official" due date for the document is one week before the scheduled start of the review period. However, the document need to be reviewed by the EMO before posting. If you wait until the due date to submit the first draft and the EMO requests changes, then you'll probably miss your deadline and your review will be postponed.<br />
<br />
=Checklist=<br />
This looks scarier than it is. Be brave.<br />
<br />
*Project website up-to-date:<br />
** Project incubation status (if applicable) correctly noted<br />
** Doing the right sorts of things to facilitate [[Community Development for Eclipse Projects|community development]]<br />
** Project has a [[Architecture Council/Contributor Guide Recommendation|Contribution Guide]]<br />
* [[Project Management Infrastructure/Project Metadata|Project Metadata is up-to-date]]<br />
** [[Project Management Infrastructure/Release Metadata|Release metadata]] is correct and up-to-date<br />
** Includes well-written project description (see [http://www.bigsoft.co.uk/blog/index.php/2010/10/18/the-whats-and-whys-to-creating-project-descriptions The Whats and Whys to creating project descriptions]).<br />
*Project plan is up-to-date and in the [[Development Resources/Project Plan|standard format]]<br />
*Code and builds are in order:<br />
**All project code available in eclipse.org VCS<br />
**All project source code repositories include a [[Architecture Council/Contributor Guide Recommendation#Source_Code_Repositories|CONTRIBUTING]] file<br />
**At least one milestone build available<br />
**Builds hosted on download.eclipse.org<br />
**archived builds hosted on archive.eclipse.org<br />
**[[Naming Conventions]] followed:<br />
*** Bundle and package names e.g. <code>org.eclipse.<subproject>.<component>[.*]</code><br />
**[[Version Numbering]] rules followed<br />
** Bundle manifests contains a "Bundle-Vendor" entry set to "Eclipse <project name>"<br />
** Every bundles contains an about.html file as required by [http://www.eclipse.org/legal/guidetolegaldoc.php A Guide to the Legal Documentation for Eclipse-Based Content].<br />
** Features names and descriptions are captured, are spelled correctly, use proper grammar, and contain content that is actually useful for the intended audience<br />
**(If in incubation phase) [[Development Resources/HOWTO/Conforming Incubation Branding|Incubation branding]] on distributed artefacts<br />
**Well-defined retention policy for distributed artefacts (e.g. p2 repositories)<br />
*Review security-related bugs that may affect your project and prepare mitigation strategy<br />
** [https://bugs.eclipse.org/bugs/buglist.cgi?keywords=security;query_format=advanced;keywords_type=allwords Disclosed security issues]<br />
** [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;field0-0-0=bug_group;bug_status=RESOLVED;type0-0-0=equals;value0-0-0=Security_Advisories Undisclosed security issues] (issues not yet disclosed to the general public)<br />
* Every download includes the necessary legal documentation (including a copy of the project licenses) as required by [http://www.eclipse.org/legal/guidetolegaldoc.php A Guide to the Legal Documentation for Eclipse-Based Content].<br />
*Intellectual Property (IP) Logs in order<br />
** Approved [[Development Resources/Contribution Questionnaire|Contribution Questionnaire]] (CQ) for project's initial contribution;<br />
** Approved CQs for all third-party libraries used directly by project code (regardless of whether or not the library is directly distributed by the project)<br />
**: Use the [https://www.eclipse.org/projects/tools/downloads.php Project Downloads Review] tool to confirm that the necessary CQs are in place;<br />
* Distribution channels cleaned up (e.g. project [[IT Infrastructure_Doc#Downloads|downloads]])<br />
** Have older releases been moved to the archive server?<br />
** Have older nightly and integration builds been removed?<br />
* IP Logs submitted for review by the Eclipse IP Team at least one week in advance of the review period<br />
** Review [http://eclipse.org/projects/tools/ip_contribution_review.php contributions] for inclusion in your IP Log<br />
** Are there any [https://www.eclipse.org/projects/tools/downloads.php third-party libraries in your downloads] that need a CQ?<br />
*PMC approval obtained (generally obtained through project mailing list)<br />
*Review Documentation (described below in greater detail)<br />
** Correct [http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Information_for_Project_Leads#Copyright_Notice copyright notice] and [http://wiki.eclipse.org/Development_Resources/HOWTO/Review_Information_for_Project_Leads#EPL_Notice EPL notice];<br />
** URLs for the project plan in the format [Development Resources/Project Plan standard format], and the IP Log<br />
** Logistic information: Dates, Communication Channel (e.g. project mailing list)<br />
*PMC-approved review Documentation submitted to EMO in advance of the start of the review period (one week preferred)<br />
If you have any questions, please ask [mailto:emo@eclipse.org EMO].<br />
<br />
Note that the lead time required to process IP Logs and review documentation may change based on current load. We typically ask, for example, that IP Logs be submitted a full month in advance for projects participating in the annual simultaneous release.<br />
<br />
=What are the Requirements?=<br />
The Release Review is conducted before each major release to verify that the key goals of the release have been accomplished and to verify that all intellectual property rights issues have been resolved. For Eclipse projects with typical six week milestones, a plausible time for a release review is one to two weeks into the final six week period, i.e., four or five weeks before the release is scheduled to go live.<br />
<br />
=What Does a Release Review Cover?=<br />
The Release Review is the final review of the project, process, release and most importantly, the IP issues, against the characteristics that help ensure [[Eclipse Quality]].<br />
<br />
A Release Review is a fairly comprehensive process. We anticipate that gathering the material for the review and preparing the documentation is a non-trivial effort, but we believe that the introspection offered by this exercise is useful for the project and that the results are very useful for the community.<br />
<br />
The items to be covered in the Review include the following. If the document is a slide deck (there's a [http://wiki.eclipse.org/images/4/4a/ReleaseReview20081211.zip template] available), it will probably average one or two slides on each of these issues. A text document (provided in an open format such as HTML) should have one or two paragraphs, or a handful of bullets on each issue. Note the use of the word &quot;summarize&quot; throughout this agenda; judgment must be used to determine how much to include in each of these bullet items.<br />
<br />
==Features==<br />
Summarize the major features of this release as well as any other features that have generated significant discussion amongst the community during the development cycle. Compare the features against the Roadmap to understand the project's conformance or divergence.<br />
<br />
'''Reason:''' The community will use this release and the ecosystem will build products on top of this release, and both need to know what features were included or excluded.<br />
<br />
References to existing [[Architecture Council/New and Noteworthy|New &amp; Noteworthy]] documentation is a useful addition to this summary.<br />
<br />
==Non-Code Aspects==<br />
Summarize the state of the non-code aspects of the release including: user documentation, localization/externalization, examples, tutorials, articles, and so on. Have the existing artifacts been updated? Are there new artifacts? Have the obsolete ones been retired or at least marked as pertaining only to older material?<br />
<br />
'''Reason:''' The non-code aspects are essential for the wide-spread adoption of the release (Reference [http://www.eclipse.org/projects/dev_process/development_process.php#2_2_Eclipse_Ecosystem Eclipse Ecosystem]).<br />
<br />
==APIs==<br />
Certify that the APIs in this release are [[Eclipse Quality]]. The project lead will ''personally'' certify that the requirements for quality have been met and/or discuss any deficiences.<br />
<br />
'''Reason:''' Eclipse members build commercial tools on top of the extensible frameworks and thus the quality of the APIs isextremely important.<br />
<br />
==Architectural Issues==<br />
Summarize the architectural quality of the release. Discuss the ''intrinsic nature of being extensible'' embodied by this project. Discuss issues such as unresolved overlap with other projects, unpaid &quot;merge debt&quot; from incorporating various components, and so on.<br />
<br />
'''Reason:''' Eclipse members build commercial tools on top of the extensible frameworks and thus the quality of the architecture is important.<br />
<br />
==Security Issues==<br />
Prior to your release, check Bugzilla for the list of [https://bugs.eclipse.org/bugs/buglist.cgi?keywords=security;query_format=advanced;keywords_type=allwords resolved vulnerabilities] and [https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;field0-0-0=bug_group;type0-0-0=equals;value0-0-0=Security_Advisories currently committer-private vulnerabilities] (there may be overlap between the two) to determine if any affect your project's code. Also check Bugzilla for bugs that may not have been marked for security (e.g. perform a simple search for words like "vulnerability" and "security" in the bug summary.<br />
<br />
In this section of the document, describe the work that you've done to remediate any issues that may arise as a result of these vulnerabilities.<br />
<br />
==Tool Usability==<br />
Summarize the usability of the tools. Usability in this sense is about using the tools to solve development problems, not the more academic sense of UI evaluation/testing.<br />
<br />
'''Reason:''' Without usable tools, the project will not attract the user community necessary to enable the ecosystem (Reference [http://www.eclipse.org/projects/dev_process/development_process_2010.php#2_3_Three_Communities Three Communities]).<br />
<br />
==End-of-Life==<br />
Summarize the features (APIs and any significant user features) from previous releases that are being end-of-life'd in this release. End of life includes both deprecation and actual removal.<br />
<br />
'''Reason:''' The community builds products that rely on features and so they need to know when these features are changing (Reference [http://www.eclipse.org/projects/dev_process/development_process_2010.php#2_3_Three_Communities Three Communities]).<br />
<br />
==Bugzilla==<br />
Summarize the bugzilla situation. How many bug records (defects and enhancements) have been opened/closed/deferred/new, etc? How many P1, P2, ..., bug records are outstanding? <br />
<br />
'''Reason:''' Summaries of the bugzilla records offer a glimpse into the project productivity. They also offer an estimate of the outstanding risk. And the summary is used to alert the community to known issues (Reference [http://www.eclipse.org/projects/dev_process/development_process.php#2_2_Eclipse_Ecosystem]).<br />
<br />
==Standards==<br />
Summarize the standards compliance of this release. If the features are based on defined, pending, or ad-hoc standards, what is the state of those standards and what is the state of the support for those standards in this release.<br />
<br />
'''Reason:''' Eclipse is about building frameworks and tools based on standards, so we need to make sure that we are conforming to the appropriate standards (Reference [http://www.eclipse.org/projects/dev_process/development_process.php#2_2_Eclipse_Ecosystem]).<br />
<br />
==UI Usability==<br />
Summarize the user interface usability and the conformance to the [[User_Interface_Guidelines]]. Include section 508 compliance, language pack conformance (does the code support multiple languages), etc. Explain any deviations from the user interface guidelines and standards.<br />
<br />
'''Reason:''' The user community is larger than just mouse-wielding, English-speaking, computer jockeys. We need to support that larger community (Reference [[User_Interface_Guidelines]]).<br />
<br />
==Schedule==<br />
Discuss the initial schedule and any changes to the schedule over the course of the release, i.e., what the project team achieved. Discuss whether milestones were met or slipped.<br />
<br />
'''Reason:''' The community relies on consistent schedules from Eclipse so that projects and products can plan for the correct dependencies.<br />
<br />
==Communities==<br />
Summarize the project's development of its three communities. Consider the interactions on bugzilla, the mailing lists, the newsgroups, public conference calls, blogs, public-relations activities, code camps, conference tutorials, coordinating with other Eclipse projects and other open source projects (Apache, ObjectWeb, etc), ...<br />
<br />
'''Reason:''' It is important for Eclipse projects to build a community around the project, not just deliver code for a project. This review item is about the success of building a community (Reference [http://www.eclipse.org/projects/dev_process/development_process.php#2_3_Three_Communities Three Communities]).<br />
<br />
==IP Issues==<br />
As per the [http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf Eclipse IP Policy], these steps must be done:<br />
<br />
# The project leadership verifies that:<br />
#* ... that the about files and use licenses are in place as per the [http://www.eclipse.org/legal/guidetolegaldoc.php Guidelines to Legal Documentation]<br />
#* ... all contributions (code, documentation, images, etc) has been committed by individuals who are either Members of the Foundation, or have signed the appropriate Committer Agreement. In either case, these are individuals who have signed, and are abiding by, the Eclipse IP Policy.<br />
#* ... that all significant contributions have been reviewed by the Foundation's legal staff. Include references to the IPZilla numbers of all clearances.<br />
#* ... that all non-Committer code contributions, including third-party libraries, have been documented in the release and reviewed by the Foundation's legal staff. Include references to the IPZilla numbers of all clearances.<br />
#* ... that all Contribution Questionnaires have been completed<br />
#* ... the &quot;copyright&quot; field of each feature is set to the copyright owner (the Eclipse Foundation is <em>rarely</em> the copyright owner).<br />
#* ... that any third-party logos or trademarks included in the distribution (icons, help file logos, etc) have been licensed under the EPL.<br />
#* ... that any fonts or similar third-party images included in the distribution (e.g. in PDF or EPS files) have been licensed under the EPL.<br />
# The PMC provides a [http://www.eclipse.org/projects/dev_process/project-log.php Project Log] that enumerates:<br />
## every piece of third party software including information on the license<br />
## every major contribution<br />
## the name of every contributor including non-committer contributions via bug fixes with bug #'s<br />
## the About files which contain any non-standard terms (e.g., a reference to a license other than the EPL, etc)<br />
# The EMO will validate for (a) and (b) that Contribution Questionnaires have been properly submitted and EMO approvals have been completed.<br />
# A frozen copy of the reviewed-and-approved-by-Eclipse-legal Project Log is part of the Release Review documentation. It can be included in the documentation or as a separate document. (Reference [http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf])<br />
<br />
The provider name for contributed features/bundles should always start with "Eclipse ..." followed by project name. It is up to each PMC to decide how best to describe their project in a meaningful, balanced fashion (either as one top level one or as multiple pieces). Avoid special symbols (e.g. ':' or "-") unless they are part of the project name. Avoid acronyms (unless in common use in software industry, such as XML, or PHP). Capitalization should follow "headline-sytyle capitalization": The only words that are not capitalized are articles (except as the first word), coordinating conjunctions (for example, and, but, and or), prepositions (except as the first or last word), and the to in an infinitive.) For discussion, see [https://bugs.eclipse.org/bugs/show_bug.cgi?id=252813 Bug 252813].<br />
<br />
==IP Issues Speak-Up-Now==<br />
The EMO explicitly asks during the Release Review if any Member would like to assert that this release infringes their IP rights. If so, the EMO and the project will follow the Eclipse IP Policy in discussions with that Member. <br />
<br />
<i><b><font color="#0080C0">Reason:</font></b></i> One of the important benefits that the Eclipse Foundation provides for its members is the consistent application of the [http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf Eclipse IP Policy] which helps ensure (but does not guarantee) that the framework and tools are useable in commercial products.<br />
<br />
(Reference [http://www.eclipse.org/org/documents/Eclipse_IP_Policy.pdf])<br />
<br />
==Project Plan==<br />
Per Board resolution of December 11, 2008, to pass a Continuation Review, Graduation Review or Release Review a project must have a current project plan, in the format specified by the EMO, available to the community.<br />
<br />
If there is a Project Plan (full or even a draft) for the next release, the final issue to cover in the Release Review is the unveiling of the new plan.<br />
<br />
=Preparing the Documentation=<br />
[[Development_Resources/FAQs/About_Docuware|About Documentation]]<br />
<br />
The documentation must cover the issues from (2) above. <br />
<br />
Example documentation from previous Release Reviews can be found in the [http://www.eclipse.org/projects/previous-release-reviews.php archives]. A [http://wiki.eclipse.org/images/4/4a/ReleaseReview20081211.zip template] (Open Office Presentation format) is also available.<br />
<br />
=The Review Process=<br />
Once the review content has been created, the operational side of a Release Review is described here: [[Development_Resources/HOWTO/Review_Process]]<br />
<br />
=After a Successful Review=<br />
After the successful advisory vote and the approval of the Release Review by the EMO:<br />
# the EMO will send an email to the project development list affirming the positive result<br />
# then, when the final release files are ready, the project may post them to the download server and let the powerful replication system distribute the bits throughout the known universe<br />
<br />
==Other Results==<br />
Other possible results of the Release Review include:<br />
* Postpone -&nbsp;issues have arisen that must be solved before the release proceeds <br />
* Pass w/ Notes - the release has some issues that need to be addressed, but they can be addressed with release notes and/or documentation <br />
* Pass w/ Issues - the release has some issues, but they can be addressed in a future release as agreed to in the review <br />
* Fail - there are significant problems with the release and/or the project. <br />
<br />
<hr/><br />
This page is moderated by the EMO.<br />
[[Category:Eclipse Development Process]]<br />
[[Category:Development_Resources]]<br />
[[Category:How to Contribute]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Mars_2015/Niedersachsen&diff=383315Eclipse DemoCamps Mars 2015/Niedersachsen2015-05-06T13:52:38Z<p>Sewe.cqse.eu: Added myself as prospective presenter</p>
<hr />
<div>[[File:marsbanner_bs.jpg]]<br />
<br />
=== Registration ===<br />
<br />
The ticket registration will be open soon.<br />
<br />
=== Location ===<br />
<br />
Coming soon<br />
<br />
=== Date and Time ===<br />
<br />
4th June - 6pm | 18:00 Uhr<br />
<br />
=== Organizers ===<br />
<br />
Jonathan Beddig, [http://www.bredex.de BREDEX GmbH] <br />
Stefan Reichert, [http://www.zühlke.com/de Zühlke]<br />
<br />
=== Sponsors ===<br />
<br />
[[Image:Bredex.png]][http://www.bredex.de BREDEX GmbH] <br />
<br><br />
[[Image:Zuehlke Logo rgb 100 2.png]] [http://www.zuehlke.com Zühlke Engineering]<br><br />
<br />
=== Agenda in Progress ===<br />
<br />
18:00 - get together<br />
<br />
18:20 - Begrüßung durch Jonathan Beddig und Stefan Reichert<br />
<br />
18:30 - <br />
<br />
- Networking & open end -<br />
<br />
=== Presenters ===<br />
<br />
If you would like to present at this event, please add your name below.<br />
<br />
* Andreas Sewe, [http://www.codetrails.com/ Codetrails GmbH] (about Codesearch)</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Luna_2014/Frankfurt&diff=360117Eclipse DemoCamps Luna 2014/Frankfurt2014-04-16T14:38:49Z<p>Sewe.cqse.eu: Added demo/talk proposal for Eclipse Code Recommenders</p>
<hr />
<div>[[Image:Eclipse_DemoCamp_New.jpg]] [[Eclipse_DemoCamps_Luna_2014 | What is an Eclipse DemoCamp?]] <br />
<br />
=== Location ===<br />
<br />
Yatta Office Frankfurt <br /><br />
Mainzer Landstr. 50 <br /><br />
60325 Frankfurt a. M. <br /><br />
<br /><br />
LatLong: 50.1109392, 8.6639151<br />
<br />
=== Date and Time ===<br />
<br />
Thursday, July 10th, 2014, opening 17:00<br />
<br />
=== Sponsors ===<br />
<br />
This Eclipse DemoCamp is sponsored by [http://www.yatta.de/ Yatta Solutions GmbH] and [http://www.compeople.de/ compeople AG]<br />
<br />
[[Image:Yatta Logo 160.png|Yatta Solutions GmbH]]<br />
<br />
[[Image:compeople_Claim-sml.jpg|170x88px]]<br />
<br />
<br />
=== Mediapartners ===<br />
<br />
Software & Support Media GmbH is supporting the Eclipse DemoCamp [http://www.yatta.de/ Software & Support Media GmbH]<br />
<br />
[[Image:Eclipsemagazin.JPG|Software & Support Media GmbH ]]<br />
<br />
=== Organizer ===<br />
<br />
If you have any questions regarding the democamp, don't hesitate contacting [http://www.xing.com/profile/Manuel_Bork Manuel Bork], e.g. via [mailto:bork@yatta.de email].<br />
<br />
=== Agenda ===<br />
<br />
TBD<br />
<br />
=== Presenters / Call for Demos ===<br />
<br />
If you would like to give a demo, please add your name and topic below or write an email to Manuel.<br />
<br />
* Martin Lippert<br />
* Andreas Sewe, [http://www.codetrails.de Codetrails]: "Crowd-Sourcing, Code-Snippets, and more: What Eclipse Code Recommenders has been to up for Luna"<br />
<br />
=== Who Is Attending ===<br />
<br />
If you plan on attending please add your name and company to the list below. You need to have an Eclipse Bugzilla account to do so. Signing up is really easy and not only gives you the chance to attend Eclipse DemoCamps, but also gives you the sweet fuzzy feeling of being able to file Eclipse bugs! Come on, give it a try - [https://bugs.eclipse.org/bugs/ we know you can do it]! Alternatively, use our [http://democamp.yatta.de/ website] to register.<br />
<br />
Note: Though its up to the speakers, please be aware that the event language in general will be German. Most talks will be in German.<br />
<br />
#[http://www.xing.com/profile/Johannes_Jacop Johannes Jacop], [http://www.yatta.de Yatta Solutions] <br />
#[http://www.xing.com/profile/Christian_Schneider219 Dr. Christian Schneider], [http://www.yatta.de Yatta Solutions] <br />
#[http://www.xing.com/profile/Manuel_Bork Manuel Bork], [http://www.yatta.de Yatta Solutions]<br />
# Christian Campo, [http://www.compeople.de Compeople AG]<br />
#Andreas Sewe, [http://www.codetrails.de Codetrails]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Luna_2014/Braunschweig&diff=359347Eclipse DemoCamps Luna 2014/Braunschweig2014-04-08T07:15:20Z<p>Sewe.cqse.eu: Added demo/talk proposal for Eclipse Code Recommenders</p>
<hr />
<div>[[Image:Eclipse DemoCamp New.jpg]]<br />
<br />
=== Location ===<br />
<br />
Braunschweig, Öffentliche Versicherung, Theodor-Heuss-Straße<br />
<br />
=== Date and Time ===<br />
<br />
17th June<br />
<br />
=== Organizer ===<br />
<br />
Alexandra Schladebeck, [http://www.bredex.de BREDEX GmbH] <br />
Stefan Reichert, [http://www.zühlke.com/de Zühlke]<br />
<br />
=== Sponsors ===<br />
[[Image:Bredex.png]][http://www.bredex.de BREDEX GmbH] <br />
<br><br />
[[Image:Zuehlke Logo rgb 100 2.png]] [http://www.zuehlke.com Zühlke Engineering]<br />
<br />
If you would like to be a sponsor of this event, please contact Alexandra Schladebeck via eclipsestammtisch@bredex.de.<br />
<br />
=== Agenda ===<br />
<br />
TBD<br />
<br />
=== Presenters ===<br />
<br />
If you would like to present at this event, please add your name below. <br />
<br />
* "Crowd-Sourcing, Code-Snippets, and more: What Eclipse Code Recommenders has been to up for Luna" [mailto:andreas.sewe@codetrails.com Andreas Sewe], [http://www.codetrails.com/ Codetrails]<br />
<br />
<br />
=== Who Is Attending ===</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2014_Ideas&diff=356137Google Summer of Code 2014 Ideas2014-02-13T08:01:18Z<p>Sewe.cqse.eu: Linked to Bug 428066</p>
<hr />
<div>[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20&query_format=advanced&keywords_type=allwords&list_id=4495706&bug_status=NEW Existing bugs marked "helpwanted"] are a good source of project ideas.<br />
<br />
{{Warning|Feel free to contribute the discussion on an Eclipse bug. Keep the discussion on bugs technical. The bugs are not a good place to talk about Google Summer of Code participation. Use the soc-dev mailing list for that.}}<br />
<br />
= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Snippet Sharing Infrastructure ==<br />
<br />
Eclipse Code Recommenders comes with a code-snippet search called [http://www.eclipse.org/recommenders/incubators/#snipmatch Snipmatch] (developed during previous Google Summer of Codes). Snipmatch allows users to search for and insert code snippets right in their Java editor; all it takes is Ctrl+Enter and a full-text search springs to life.<br />
<br />
Under the hood, Snipmatch searches a single snippet repository which is currently backed by [https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.snipmatch.snippets.git/ a Git repo], to which users can upload new snippets using EGit. Doing so is not supported by Snipmatch's UI yet. Moreover, only a single snippet repository is supported, which makes it impossible to use multiple sources for your snippets.<br />
<br />
The goal of this project is to create the necessary infrastructure to manage multiple snippet repositories, possibly with different backing implementations (Git repo, filesystem, Eclipse's built-in templates). Moreover, this project should develop a uniform UI for sharing snippets with other developers.<br />
<br />
'''Additional Resources:''' [https://bugs.eclipse.org/bugs/show_bug.cgi?id=427905 Bug 427905]<br />
<br />
'''Possible Mentors:''' Andreas Sewe, Marcel Bruch (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Students:''' Olav Lenz<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Livedoc XXL ==<br />
<br />
With version 2.0, Eclipse Code Recommenders made the jump from the Eclipse IDE into the Web: With [http://www.eclipse.org/recommenders/incubators/#snipmatch Livedoc] (developed during the Google Summer of Code 2013) it became possible to enrich your good ol' Javadoc with intelligent recommendations on how to use an API.<br />
<br />
Livedoc, a stand-alone command-line application makes it very easy to generate enriched Javadoc for your JARs. At the moment, however, it works one JAR at a time.<br />
<br />
The goal of this project thus is to create to enhance Livedoc such that it becomes possible to create a large, interconnected web of documentation for different APIs (and in different versions) that can be<br />
deployed to download.eclipse.org as a showcase for Eclipse Code Recommenders and Livedoc. Who knows, it may even become the default Javadoc for other Eclipse projects.<br />
<br />
'''Additional Resources:''' [https://bugs.eclipse.org/bugs/show_bug.cgi?id=428066 Bug 428066]<br />
<br />
'''Possible Mentors:''' Andreas Sewe (contact me on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Students:''' ''please add yourself''<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Xtext-based Editor for the JFace Template Language ==<br />
<br />
[http://www.eclipse.org/recommenders/incubators/#snipmatch Snipmatch] is an incubator project of Eclipse Code Recommenders that makes it easy to search for and insert code snippets into your Java code. It also makes it possible to create new snippets and share these with other developers.<br />
<br />
These snippets are written in the JFace template language, a very powerful language which unfortunately not everyone is familiar with. Thus, first-class editor support is needed. This is where [http://www.eclipse.org/Xtext/ Xtext] comes in.<br />
<br />
The goal of this project is to create a full-fledged editor for the JFace template language usable by Snipmatch (and possibly other projects). It should offer syntax highlighting, code completion, and (last but certainly not least) user-friendly error reporting. One possible stretch goals is the ability to automatically create JFace templates from any piece of selected Java code.<br />
<br />
'''Possible Mentors:''' Andreas Sewe, Johannes Dorn (contact me on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Students:''' ''please add yourself'' ('''please note:''' knowledge of formal grammars and compiler front-ends is ''very'' beneficial)<br />
<br />
== [http://www.locationtech.org/projects/technology.geotrellis GeoTrellis]: Multi-band Raster support ==<br />
<br />
GeoTrellis is a project recently submitted to become part of LocationTech. It is a framework for fast, parallel processing of raster data in the geospatial domain. GeoTrellis provides a number of operations to manipulate raster data, including cropping/warping, Map Algebra operations, and rendering operations, as well as vector to raster operations such as Kernel Density and vectorization of raster data.<br />
<br />
Multi-band rasters are a group of rasters that have the same spatial extent and resolution. Examples might include rasters of different spectral bands or a time series of rasters. The ability to deal with a group of rasters like this is common in GIS software, for example GRASS GIS and R (RasterStack, RasterBrick) have this capability.<br />
<br />
GeoTrellis currently lacks the infrastructure to handle such a collection of rasters as a single entity. The goal of this project is 4-fold:<br />
<br />
# Investigate options for ARG multi-band files (may just be multiple ARG files)<br />
# set up GeoTrellis to treat a group of rasters as a single entity<br />
# provide a framework for developing operations on these raster groups<br />
# implement some number of these operations.<br />
<br />
One example of an operation is combining red, green, and blue spectral rasters to output a full-color PNG image. Another example is performing a calculation on a vector of values for each cell. If you imagine the rasters as 'stacked' on each other, the vector would be formed from the stack of values for each cell.<br />
<br />
'''Possible Mentors:''' Rob Emanuele, Eric.J.Christeson (contact us on our [https://groups.google.com/forum/#!forum/geotrellis-user mailing list])<br />
<br />
'''Interested Students:''' ''please add yourself''</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2014_Ideas&diff=356110Google Summer of Code 2014 Ideas2014-02-12T15:04:53Z<p>Sewe.cqse.eu: Added Xtext-based Editor for the JFace Template Language idea</p>
<hr />
<div>[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20&query_format=advanced&keywords_type=allwords&list_id=4495706&bug_status=NEW Existing bugs marked "helpwanted"] are a good source of project ideas.<br />
<br />
{{Warning|Feel free to contribute the discussion on an Eclipse bug. Keep the discussion on bugs technical. The bugs are not a good place to talk about Google Summer of Code participation. Use the soc-dev mailing list for that.}}<br />
<br />
= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Snippet Sharing Infrastructure ==<br />
<br />
Eclipse Code Recommenders comes with a code-snippet search called [http://www.eclipse.org/recommenders/incubators/#snipmatch Snipmatch] (developed during previous Google Summer of Codes). Snipmatch allows users to search for and insert code snippets right in their Java editor; all it takes is Ctrl+Enter and a full-text search springs to life.<br />
<br />
Under the hood, Snipmatch searches a single snippet repository which is currently backed by [https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.snipmatch.snippets.git/ a Git repo], to which users can upload new snippets using EGit. Doing so is not supported by Snipmatch's UI yet. Moreover, only a single snippet repository is supported, which makes it impossible to use multiple sources for your snippets.<br />
<br />
The goal of this project is to create the necessary infrastructure to manage multiple snippet repositories, possibly with different backing implementations (Git repo, filesystem, Eclipse's built-in templates). Moreover, this project should develop a uniform UI for sharing snippets with other developers.<br />
<br />
'''Additional Resources:''' [https://bugs.eclipse.org/bugs/show_bug.cgi?id=427905 Bug 427905]<br />
<br />
'''Possible Mentors:''' Andreas Sewe, Marcel Bruch (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Students:''' Olav Lenz<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Livedoc XXL ==<br />
<br />
With version 2.0, Eclipse Code Recommenders made the jump from the Eclipse IDE into the Web: With [http://www.eclipse.org/recommenders/incubators/#snipmatch Livedoc] (developed during the Google Summer of Code 2013) it became possible to enrich your good ol' Javadoc with intelligent recommendations on how to use an API.<br />
<br />
Livedoc, a stand-alone command-line application makes it very easy to generate enriched Javadoc for your JARs. At the moment, however, it works one JAR at a time.<br />
<br />
The goal of this project thus is to create to enhance Livedoc such that it becomes possible to create a large, interconnected web of documentation for different APIs (and in different versions) that can be<br />
deployed to download.eclipse.org as a showcase for Eclipse Code Recommenders and Livedoc. Who knows, it may even become the default Javadoc for other Eclipse projects.<br />
<br />
'''Possible Mentors:''' Andreas Sewe (contact me on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Students:''' ''please add yourself''<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Xtext-based Editor for the JFace Template Language ==<br />
<br />
[http://www.eclipse.org/recommenders/incubators/#snipmatch Snipmatch] is an incubator project of Eclipse Code Recommenders that makes it easy to search for and insert code snippets into your Java code. It also makes it possible to create new snippets and share these with other developers.<br />
<br />
These snippets are written in the JFace template language, a very powerful language which unfortunately not everyone is familiar with. Thus, first-class editor support is needed. This is where [http://www.eclipse.org/Xtext/ Xtext] comes in.<br />
<br />
The goal of this project is to create a full-fledged editor for the JFace template language usable by Snipmatch (and possibly other projects). It should offer syntax highlighting, code completion, and (last but certainly not least) user-friendly error reporting. One possible stretch goals is the ability to automatically create JFace templates from any piece of selected Java code.<br />
<br />
'''Possible Mentors:''' Andreas Sewe, Johannes Dorn (contact me on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Students:''' ''please add yourself'' ('''please note:''' knowledge of formal grammars and compiler front-ends is ''very'' beneficial)</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2014_Ideas&diff=356109Google Summer of Code 2014 Ideas2014-02-12T14:51:47Z<p>Sewe.cqse.eu: Added Livedoc XXL idea</p>
<hr />
<div>[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20&query_format=advanced&keywords_type=allwords&list_id=4495706&bug_status=NEW Existing bugs marked "helpwanted"] are a good source of project ideas.<br />
<br />
{{Warning|Feel free to contribute the discussion on an Eclipse bug. Keep the discussion on bugs technical. The bugs are not a good place to talk about Google Summer of Code participation. Use the soc-dev mailing list for that.}}<br />
<br />
= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Snippet Sharing Infrastructure ==<br />
<br />
Eclipse Code Recommenders comes with a code-snippet search called [http://www.eclipse.org/recommenders/incubators/#snipmatch Snipmatch] (developed during previous Google Summer of Codes). Snipmatch allows users to search for and insert code snippets right in their Java editor; all it takes is Ctrl+Enter and a full-text search springs to life.<br />
<br />
Under the hood, Snipmatch searches a single snippet repository which is currently backed by [https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.snipmatch.snippets.git/ a Git repo], to which users can upload new snippets using EGit. Doing so is not supported by Snipmatch's UI yet. Moreover, only a single snippet repository is supported, which makes it impossible to use multiple sources for your snippets.<br />
<br />
The goal of this project is to create the necessary infrastructure to manage multiple snippet repositories, possibly with different backing implementations (Git repo, filesystem, Eclipse's built-in templates). Moreover, this project should develop a uniform UI for sharing snippets with other developers.<br />
<br />
'''Additional Resources:''' [https://bugs.eclipse.org/bugs/show_bug.cgi?id=427905 Bug 427905]<br />
<br />
'''Possible Mentors:''' Andreas Sewe, Marcel Bruch (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Student:''' Olav Lenz<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Livedoc XXL ==<br />
<br />
With version 2.0, Eclipse Code Recommenders made the jump from the Eclipse IDE into the Web: With [http://www.eclipse.org/recommenders/incubators/#snipmatch Livedoc] (developed during the Google Summer of Code 2013) it became possible to enrich your good ol' Javadoc with intelligent recommendations on how to use an API.<br />
<br />
Livedoc, a stand-alone command-line application makes it very easy to generate enriched Javadoc for your JARs. At the moment, however, it works one JAR at a time.<br />
<br />
The goal of this project thus is to create to enhance Livedoc such that it becomes possible to create a large, interconnected web of documentation for different APIs (and in different versions) that can be<br />
deployed to download.eclipse.org as a showcase for Eclipse Code Recommenders and Livedoc. Who knows, it may even become the defaultJavadoc for other Eclipse projects.<br />
<br />
'''Possible Mentors:''' Andreas Sewe (contact me on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2014_Ideas&diff=355992Google Summer of Code 2014 Ideas2014-02-11T14:10:33Z<p>Sewe.cqse.eu: Linked to Bug 427905</p>
<hr />
<div>[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20&query_format=advanced&keywords_type=allwords&list_id=4495706&bug_status=NEW Existing bugs marked "helpwanted"] are a good source of project ideas.<br />
<br />
{{Warning|Feel free to contribute the discussion on an Eclipse bug. Keep the discussion on bugs technical. The bugs are not a good place to talk about Google Summer of Code participation. Use the soc-dev mailing list for that.}}<br />
<br />
= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Snippet Sharing Infrastructure ==<br />
<br />
Eclipse Code Recommenders comes with a code-snippet search called [http://www.eclipse.org/recommenders/incubators/#snipmatch Snipmatch] (developed during previous Google Summer of Codes). Snipmatch allows users to search for and insert code snippets right in their Java editor; all it takes is Ctrl+Enter and a full-text search springs to life.<br />
<br />
Under the hood, Snipmatch searches a single snippet repository which is currently backed by [https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.snipmatch.snippets.git/ a Git repo], to which users can upload new snippets using EGit. Doing so is not supported by Snipmatch's UI yet. Moreover, only a single snippet repository is supported, which makes it impossible to use multiple sources for your snippets.<br />
<br />
The goal of this project is to create the necessary infrastructure to manage multiple snippet repositories, possibly with different backing implementations (Git repo, filesystem, Eclipse's built-in templates). Moreover, this project should develop a uniform UI for sharing snippets with other developers.<br />
<br />
'''Additional Resources:''' [https://bugs.eclipse.org/bugs/show_bug.cgi?id=427905 Bug 427905]<br />
<br />
'''Possible Mentors:''' Andreas Sewe, Marcel Bruch (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Student:''' Olav Lenz</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2014_Ideas&diff=355984Google Summer of Code 2014 Ideas2014-02-11T13:59:22Z<p>Sewe.cqse.eu: Added Snippet Sharing Infrastructure idea</p>
<hr />
<div>[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20&query_format=advanced&keywords_type=allwords&list_id=4495706&bug_status=NEW Existing bugs marked "helpwanted"] are a good source of project ideas.<br />
<br />
{{Warning|Feel free to contribute the discussion on an Eclipse bug. Keep the discussion on bugs technical. The bugs are not a good place to talk about Google Summer of Code participation. Use the soc-dev mailing list for that.}}<br />
<br />
= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Snippet Sharing Infrastructure ==<br />
<br />
Eclipse Code Recommenders comes with a code-snippet search called [http://www.eclipse.org/recommenders/incubators/#snipmatch Snipmatch] (developed during previous Google Summer of Codes). Snipmatch allows users to search for and insert code snippets right in their Java editor; all it takes is Ctrl+Enter and a full-text search springs to life.<br />
<br />
Under the hood, Snipmatch searches a single snippet repository which is currently backed by [https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.snipmatch.snippets.git/ a Git repo], to which users can upload new snippets using EGit. Doing so is not supported by Snipmatch's UI yet. Moreover, only a single snippet repository is supported, which makes it impossible to use multiple sources for your snippets.<br />
<br />
The goal of this project is to create the necessary infrastructure to manage multiple snippet repositories, possibly with different backing implementations (Git repo, filesystem, Eclipse's built-in templates). Moreover, this project should develop a uniform UI for sharing snippets with other developers.<br />
<br />
'''Possible Mentors:''' Andreas Sewe, Marcel Bruch (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
'''Interested Student:''' Olav Lenz</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Recommenders/BuildingFromSource&diff=354114Recommenders/BuildingFromSource2014-01-06T11:00:54Z<p>Sewe.cqse.eu: Replaced content with "See [https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/about/ here] for a description how to build Code Recommenders from source.
Category:Recommenders"</p>
<hr />
<div>See [https://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/about/ here] for a description how to build Code Recommenders from source.<br />
<br />
[[Category:Recommenders]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Recommenders/Documentation&diff=354112Recommenders/Documentation2014-01-06T09:54:10Z<p>Sewe.cqse.eu: </p>
<hr />
<div>A [http://www.eclipse.org/recommenders/getting-started/ Getting Started guide], a [http://www.eclipse.org/recommenders/manual/ Manual], and an [http://www.eclipse.org/recommenders/faq/ FAQ] can all be found on the [http://www.eclipse.org/recommenders/ Code Recommenders homepage].<br />
<br />
[[Category:Recommenders]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Hudson&diff=354017Hudson2013-12-23T16:53:26Z<p>Sewe.cqse.eu: Added a note on "role" groups as approvers for the Promoted Builds plugin</p>
<hr />
<div>= About Hudson =<br />
<br />
Hudson is a continuous integration (CI) tool. The [http://eclipse.org/hudson/ Hudson project] is hosted at Eclipse.org, and is in use on Eclipse servers for Eclipse projects as part of the [[CBI|Common Build Infrastrure (CBI)]]. This page is about the hosted service at Eclipse.org. For more information on the project itself, or to download Hudson, please see the [http://eclipse.org/hudson/ Hudson project] page.<br />
<br />
The Eclipse Hudson server, hosted at https://hudson.eclipse.org/ allows for the execution of Continuous Integration Builds, Nightly Builds, Integration Builds, Release Builds, and Testing (unit and UI). Hudson is maintained by the Eclipse Webmasters.<br />
<br />
<br />
= General Information =<br />
<br />
The Hudson CI server is available in two different offerings (each explained below):<br />
<br />
*Hudson Shared instance: https://hudson.eclipse.org/ <br />
*Hudson Instance Per Project (HIPP): https://hudson.eclipse.org/(your_project)<br />
* DEPRECATED: Hudson Sandbox instance: https://hudson.eclipse.org/sandbox/<br />
The Hudson Sandbox is deprecated, and will be eventually shut down.<br />
<br />
<br />
== Hudson configuration and tools ==<br />
<br />
Both Shared and HIPP Hudson setups use SLES 11 x86_64 machines for Linux slaves. Windows 7 and Mac OS X slaves are available for UI testing on the Shared instance. These servers are behind a firewall so any outbound http(s) connections are proxied. <br />
<br />
The following global variables are set(identically across installs): <br />
<br />
*JVM_OPTS: proxy data (see "Accessing the Internet" below) <br />
*ANT_ARGS: proxy data <br />
*ANT_OPTS: proxy data<br />
<br />
Each node also has a .m2/settings.xml file with the proxy data. <br />
<br />
<br />
== HIPP ==<br />
HIPP instances are recommended for those projects who prefer flexibility and convenience with their CI system, perhaps at the expense of security and webmaster support. A single Linux master is provided, and the instance is run under the security context of your project. Optionally, a project's Hudson instance can be configured to write into a project's downloads area and can be given write access to the code repository for automatic tagging of builds. Webmasters will install most plugins you request, including the Gerrit plugin, but will offer little support. In time, projects will be offered self-serve restarts and re-imaging of their instances.<br />
<br />
=== Requesting a HIPP instance ===<br />
Please file [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Hudson a bug] against Eclipse Foundation > Community > Hudson to request your project's own instance. Please ensure your project lead can +1 the request. Please specify if you would like to use the Gerrit Trigger plugin, and if you wish to grant write access to your download and code repositories.<br />
<br />
'''PLEASE NOTE:''' there may be security issues related to using the Gerrit plugin.<br />
<br />
'''PLEASE NOTE:''' there may be security issues related to allowing the CI system to write directly to your code repos and downloads area.<br />
<br />
'''PLEASE NOTE:''' if you request plugins other than those available on the Shared instance, webmaster may not be able to help troubleshoot any issues that you may encounter with your instance.<br />
<br />
== Shared Instance ==<br />
The Shared instance is recommended for general purpose builds and tests, and for all UI tests. Shared Hudson has several build slaves, a limited yet stable tool set, and full webmaster support. Shared Hudson cannot write into your downloads area or tag releases in your Git repo. Furthermore, the Gerrit trigger plugin is not permitted to run here.<br />
<br />
<br />
=== Choosing the right slave ===<br />
* '''hudson-slave1, hudson-slave2, hudson-slave4 and hudson-slave6''' - these are the main build nodes for Hudson jobs. You can specify them by name or by using the 'build2' label. <br />
* '''hudson-slave5''' - this is an ia64 slave.<br />
* '''hudson-slave7, hudson-slave8''' - these are ppc64 slaves located at OSUOSL.<br />
* '''fastlane''' - this slave is intended for usage during a release train crunch when re-spins may require more capacity than hudson-slave1&amp;2 can provide. By default jobs should not run here. <br />
* '''hudson-perf1-tests''' - this slave is used for running performance tests ONLY.<br />
* '''mac-tests and windows7tests''' - these 2 slaves are meant for running UI tests for their respective OS versions. By default jobs should not run on either slave.<br />
<br />
See also: [[Hudson server performance metrics]]<br />
<br />
=== Server Storage ===<br />
<br />
[[Image:Build infra layout.png|thumb|Build and Hudson storage layout]] Three tiers of storage are available for storing Workspaces, build artifacts, nightly and release builds. For optimal build performance and service availability, it is important that you use each storage device according to its intended purpose. <br />
<br />
The image on the right illustrates the three storage tiers and their intended purpose. <br />
<br />
== Tools(and locations) ==<br />
<br />
*Maven 2.2.1 (installed automatically) <br />
*Maven 3.0 alpha 5 (installed automatically) <br />
*Maven 3.0-alpha-5-local (/shared/common/apache-maven-3.0-alpha-5) <br />
*Maven 3.0-alpha-6-local (/shared/common/apache-maven-3.0-alpha-6) <br />
*Maven 3.0-Beta-1 (/shared/common/apache-maven-3.0-beta-1)<br />
<br />
*Sun Java 5 SR 22 64bit (/shared/common/jdk-1.5.0-22.x86_64) <br />
*Sun Java 5 R 16 32bit (/shared/common/jdk-1.5.0_16) <br />
*Sun Java 5 R 22 64bit (/shared/common/jdk-1.5.0-22.x86_64) <br />
*Sun Java 6 R 21 32bit (/shared/common/sun-jdk1.6.0_21_i586) <br />
*Sun Java 6 R 21 64bit (/shared/common/sun-jdk1.6.0_21_x64)<br />
<br />
*Apache-ant-1.8.1 (/shared/common/apache-ant-1.8.1) <br />
*Apache-ant-1.7.1 (/shared/common/apache-ant-1.7.1) <br />
*Apache-ant-1.7.0 (/shared/common/apache-ant-1.7.0) <br />
*Apache-ant-1.6.5 (/shared/common/apache-ant-1.6.5)<br />
<br />
*Headless Buckminster 3.6 (/shared/common/buckminster-3.6) <br />
*Buckminster 3.6 Integration (installed automatically)<br />
<br />
== Accessing the Internet using Proxy ==<br />
<br />
Each Hudson instance has unrestricted access to the Internet by using proxy.eclipse.org. The shell environment variables below are set for the Hudson build user. If your build process overrides, or bypasses these variables, you must instruct your tools to use the proxy service to access external sites. <br />
<br />
ftp_proxy=http://proxy.eclipse.org:9898<br />
http_proxy=http://proxy.eclipse.org:9898<br />
https_proxy=http://proxy.eclipse.org:9898<br />
no_proxy='localhost, 127.0.0.1, 172.30.206.0, eclipse.org'<br />
<br />
JAVA_ARGS="-Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -Dhttp.nonProxyHosts=*.eclipse.org -Dhttps.nonProxyHosts=*.eclipse.org -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -Dftp.nonProxyHosts=*.eclipse.org"<br />
<br />
JVM_OPTS="-Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -DhttpnonProxyHosts=*.eclipse.org -DhttpsnonProxyHosts=*.eclipse.org -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -DftpnonProxyHosts=*.eclipse.org"<br />
<br />
ANT_ARGS="-Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -DhttpnonProxyHosts=*.eclipse.org -DhttpsnonProxyHosts=*.eclipse.org -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -DftpnonProxyHosts=*.eclipse.org"<br />
<br />
ANT_OPTS="-Dhttp.proxyHost=proxy.eclipse.org -Dhttp.proxyPort=9898 -Dhttps.proxyHost=proxy.eclipse.org -Dhttps.proxyPort=9898 -DhttpnonProxyHosts=*.eclipse.org -DhttpsnonProxyHosts=*.eclipse.org -Dftp.proxyHost=proxy.eclipse.org -Dftp.proxyPort=9898 -DftpnonProxyHosts=*.eclipse.org"<br />
<br />
== Why use a Proxy? ==<br />
<br />
The purpose of the Proxy for Hudson is not for security -- we use firewalls for that. The proxy is used for three specific reasons: <br />
<br />
#The Eclipse Hudson environment is expected to grow to a large number of slaves for builds and for tests. If each of those slaves requires a routable IP address, the Foundaton will be required to acquire (at cost) additional IP blocks, which further complicates routing and firewall setups. <br />
#A proxy will allow us to track and monitor external dependencies that are downloaded at build time, for IP purposes. <br />
#A proxy will enable us to implement caching at the proxy level, should the CI mechanism begin to download the entire world and consume too much bandwidth.<br />
<br />
== Configuring a proxy for the p2 director ==<br />
The p2 director does not respect the "http.proxyHost" etc. options passed in on command line. But, since the p2 director is an Eclipse application, one way to configure the proxy settings is to set the configuration file '''configuration/.settings/org.eclipse.core.net.prefs''' in the director installation as below. [Note: this are roughly accurate as of 03/15/2013. They may change from time to time, over the years, so if they don't seem to work, contact the webmasters to ask if they have changed or differ for different machines.] Notice this example has "systemProxiesEnabled" set to true. This is because on Hudson, from time to time, the webmasters may change the proxy configuration for each slave differently, so if you can take advantage of the system-set proxies, you will be better off. If not, the provided values will apply if you set "systemProxiesEnabled" to false. Also note that the "socks proxy" should not be set in Eclipse, unless you know for sure you have a true socks proxy, or else all traffic will be routed through that, so if its not a true socks-level proxy none of the others will work. The proxy for Hudson is not a socks proxy, just HTTP, HTTPS, and FTP protocols. Also note, a full "Eclipse Platform", where native providers are provided, such as on Windows, will automatically detect and fill-in the system proxies. But, this auto-detection won't work if you have a "bare" p2-director app or something like the platform's "basebuilder"; in which case you must provide them with a script such as the following. See {{bug|401964}} for some discussion of these issues, among many other network and infrastructure issues. <br />
# add proxy configuration<br />
cat > "${directorInstallDirectory}/director/configuration/.settings/org.eclipse.core.net.prefs" <<EOF<br />
eclipse.preferences.version=1<br />
org.eclipse.core.net.hasMigrated=true<br />
proxiesEnabled=true<br />
systemProxiesEnabled=true<br />
nonProxiedHosts=172.30.206.*<br />
proxyData/HTTP/hasAuth=false<br />
proxyData/HTTP/host=proxy.eclipse.org<br />
proxyData/HTTP/port=9898<br />
proxyData/HTTPS/hasAuth=false<br />
proxyData/HTTPS/host=proxy.eclipse.org<br />
proxyData/HTTPS/port=9898<br />
EOF<br />
The easiest way to obtain this file is to configure an Eclipse installation on your own computer (in Eclipse, go to '''Window > Preferences > General > Network Connections'''), and then copy the configuration that Eclipse wrote in '''<eclipse>/configuration/.settings/org.eclipse.core.net.prefs'''.<br />
<br />
== Configuring for a proxy on Windows OS ==<br />
<br />
On the Windows operating system, proxy settings (and exceptions to using the proxy) can be set in "Internet Options". These are "detected" by Eclipse and set in "native" values of proxy preferences, but, apparently, from searching eclipse bugs for "proxies", some functions in Eclipse use these preferences and others do not. In any case, you might HAVE to set the Windows Internet Options proxy exceptions and in some cases it might make things easier. (For one case of details/history, see bug {{bug|372880}}.<br />
<br />
== Additional Troubleshooting Tips ==<br />
<br />
=== Buckminster CVS materializing: proxy error: Forbidden ===<br />
<br />
From Martin Taal, via [http://www.eclipse.org/forums/index.php?t=tree&goto=628738#page_top Forums]: <br />
<br />
Buckminster cvs materializing, uses a proxy, how is this configured? <br />
<br />
To finish this thread. Michael Wenz pointed me to a change made in the cdo build (to solve this issue), a snippet from his email to me: <br />
<br />
But I saw that the CDO build is green again and they still do an Ant call from Hudson that again triggers Buckminster. Previously that build failed with the same exception as ours did or do. <br />
<br />
Not sure what these guys changed, but I saw that they added something in their build.xml that seems to fix this. I found 2 snippets that appear to be in connection with this: ... &lt;condition property="no.proxy" value="${env.no_proxy}, dev.eclipse.org" else="dev.eclipse.org"&gt; &lt;isset property="env.no_proxy" /&gt; &lt;/condition&gt; ... <br />
<br />
... <!-- Launch the eclipse application --> &lt;java fork="true" jar="${@{app}.launcher}" dir="${@{app}.deploy.dir}" failonerror="true"&gt; &lt;env key="no_proxy" value="${no.proxy}" /&gt; &lt;properties /&gt; <!-- Uncomment to debug <jvmarg value=" -agentlib:jdwp=transport=dt_socket,address=8000,server=y,sus pend=y "/> --> &lt;args /&gt; &lt;/java&gt; ... <br />
<br />
== Hudson for Committers ==<br />
<br />
*[[Common Build Infrastructure/Getting Started/Build In Hudson|Build in Hudson]] - Information on requesting jobs, running jobs, setting up builds. <br />
*[[Building an RCP application with hudson (Buckminster)|RCP apps with Buckminster on Hudson]] <br />
*[[Teneo/Teneo Build Setup|Building an Eclipse project (Teneo) with Buckminster and Hudson]] <br />
*[[Common Build Infrastructure/Getting Started#In_Hudson|Athena Common Builder on Hudson]] <br />
*[[Hudson/Maven|Maven on Hudson]] <br />
*[[Hudson/HowTo|How to....]]<br />
<br />
== Hudson for Committer Project-level Administration ==<br />
<br />
Normally "project level" administration is defined for a Hudson job. This allows for only one or a few committers to have "full access" to the job, to do builds, change the configuration, or even delete the job. To give access to everyone, say to "read" the builds, you can add the user "anonymous" and mark the "read" check box. Typically, it is desired to have some "in between" access to all the committers of a project, for example, to maybe any committer can kick off a build, but only the project-level administrator can change the configuration. If this is desired, there is a "role" groups that can be used instead of listing all committers by name. The "role" name is formed by perpending "ROLE_" to the upper case version of the Linux group that defines the committers. For example, EPP committers are authorized using the Linux group ''technology.packaging'', so their Hudson group would be ROLE_TECHNOLOGY.PACKAGING. So, as an example, the project level authorization might look like the following, from the Hudson "configure project" page: <br> <br />
<br />
[[Image:Projectlevel.png|Example Project Level Security settings]]<br />
<br />
If using the Promoted Builds plugin with a Promotion Criterion of "Only when manually approved", you can also use "role" groups (using the aforementioned "ROLE_" syntax). In fact, you *should* at least restrict the approvers to the group of project committers, as otherwise any anonymous can run a promotion job ([https://bugs.eclipse.org/bugs/show_bug.cgi?id=424619 Bug 424619]).<br />
<br />
== Hudson for Administrators ==<br />
<br />
*[[Common Build Infrastructure/Managing Hudson|Manage Hudson]] <br />
*[[Hudson/Admin/UpgradeHudson|Upgrade Hudson]] <br />
*[[Hudson/Admin/Installed Plugins|Installed Plugins]]<br />
<br />
=== Duties of Administrators ===<br />
<br />
#Hudson upgrades and restarts <br />
#New Hudson accounts <br />
#Add plugins <br />
#Set policy for Hudson usage <br />
#Watch changes to this wiki page <br />
#Monitor the Hudson Inbox.<br />
<br />
=== Who are the Administrators ===<br />
<br />
* Eclipse Webmasters - webmaster@eclipse.org<br />
* David Williams<br />
<br />
You can contact the Hudson admins by opening [https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Hudson a bug]<br />
<br />
== Hudson for Distributed Builds ==<br />
<br />
*Testing on Multiple Platforms <br />
*What is the Test-Slave Node? <br />
*How do I use the Test Slave Node to run Tests?<br />
<br />
[[Category:Releng]] [[Category:Hudson]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_November_2013/Karlsruhe&diff=351894Eclipse DemoCamps November 2013/Karlsruhe2013-11-19T13:29:39Z<p>Sewe.cqse.eu: </p>
<hr />
<div>[[Image:Eclipse_DemoCamp_New.jpg]] [[Eclipse_DemoCamps_November_2013| What is an Eclipse DemoCamp?]] <br />
<br />
=== Location ===<br />
<br />
FZI Forschungszentrum Informatik<br><br />
House of Living Labs<br><br />
Haid-und-Neu-Str. 5a<br><br />
Karlsruhe, Germany<br><br />
LatLong: 49.0120458, 8.4246818<br />
<br />
[http://www.fzi.de/en/wir-ueber-uns/so-finden-sie-uns/ Directions]<br />
<br />
=== Date and Time ===<br />
<br />
November 20, 2013 at 17:30<br />
<br />
As in previous years, the FZI Forschungszentrum Informatik is organizing an Eclipse DemoCamp in 2013.<br />
<br />
We are looking forward to welcoming you at the DemoCamp. Participation is free of charge. However, since space is limited, we ask for registration (registration will be available soon on this page).<br />
<br />
=== Sponsors ===<br />
<br />
<div><br />
{| cellpadding="5" style="text-align:center"<br />
|+<br />
| [[Image:FZI50.jpg|none|FZI]] || [[Image:VKSI.GIF|none|VKSI]] || [[File:Andrena120.gif|none|andrena objects AG]]<br />
|-<br />
| [http://www.fzi.de FZI Forschungszentrum Informatik] || [http://www.vksi.de Verein der Karlsruher Software-Ingenieure] || [http://www.andrena.de andrena objects AG]<br />
|}<br />
</div><br />
<br />
If your company is willing to co-sponsor this event, please contact the organizers.<br />
<br />
=== Organizer ===<br />
<br />
FZI Forschungszentrum Informatik, Karlsruhe<br />
<br />
Michael Hauck, [mailto:hauck@fzi.de hauck@fzi.de]<br />
Benjamin Klatt, [mailto:klatt@fzi.de klatt@fzi.de]<br />
<br />
=== Preliminary Agenda ===<br />
<br />
* 17:30 - 17:35 Welcome<br />
* 17:35 - 17:45 Intro by Ralph Mueller, (Eclipse Foundation)<br />
* 17:45 - 18:00 Ben Romberg & Stefan Schürle (andrena objects): C4J<br />
* 18:05 - 18:20 Erik Wittern (FZI): An Eclipse-Based Service Feature Model Designer<br />
* 18:25 - 18:40 Andreas Sewe ([http://www.codetrails.com/ Codetrails]): Code Snippets for the World (and Eclipse)<br />
* 18:45 - 19:10 Break<br />
* 19:10 - 19:25 Werner Keil: Triple E’ class Continuous Delivery<br />
* 19:30 - 19:45 Benjamin Muskalla (Tasktop): Practical puppet by the example of the Mylyn project<br />
* 19:50 - 20:05 Kai Kreuzer (Deutsche Telekom): Eclipse SmartHome - Enabling the Intranet of Things<br />
* 20:05 Closing, get together at FZI<br />
<br />
<br />
<!--=== Presenters / Call for Demos ===<br />
<br />
If you would like to present at this event, please submit your demo (including title, abstract, short speaker bio) to<br />
[mailto:eclipse-democamp@fzi.de eclipse-democamp@fzi.de] .<br />
<br />
Depending on the number of submitted demos, we may have to limit the number of presented demos.--><br />
<br />
=== Registration ===<br />
<br />
Please register on the [https://democamp-karlsruhe-2013.eventbrite.com/ Karlsruhe DemoCamp Eventbrite] site. <br />
<br />
* The Karlsruhe DemoCamp is free of charge.<br />
* Our venue is limited to a maximum audience of 90 people.</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Kepler_2013/Stuttgart&diff=343544Eclipse DemoCamps Kepler 2013/Stuttgart2013-07-17T09:15:55Z<p>Sewe.cqse.eu: /* Sponsors */</p>
<hr />
<div>[[Image:Eclipse_DemoCamp_New.jpg]] [[Eclipse_DemoCamps_Kepler_2013 | What is an Eclipse DemoCamp?]] <br />
<br />
=== Location ===<br />
<br />
[http://www.ibis.com/de/hotel-1704-ibis-styles-stuttgart-ex-all-seasons/index.shtml Ibis Styles Hotel]<br/><br />
Teinacher Straße 20<br/><br />
70372 Stuttgart-Bad Cannstatt<br />
<br />
=== Date and Time ===<br />
<br />
Wednesday, 2013-07-17 17:00<br />
<br />
=== Sponsors ===<br />
<br />
This DemoCamp will be sponsored by itemis AG, Eclipse strategic member and the leading company for model-driven software development. <br />
<br />
[[Image:Itemis pos-2.JPG|168x68px]]<br />
<br />
This DemoCamp will be co-sponsored by Codetrails, the people that brought you [http://www.eclipse.org/recommenders Eclipse Code Recommenders] and [http://marketplace.eclipse.org/content/codetrails-crowd-recommendation-tools-eclipse crowd-sourced code completion].<br />
<br />
[[Image:Codetrails-logo_0.png]]<br />
<br />
If your company is willing to co-sponsor this event, please contact Niko Stotz.<br />
<br />
=== Organizer ===<br />
<br />
[http://www.xing.com/profile/Niko_Stotz Niko Stotz], [http://www.itemis.de itemis AG]<br />
<br />
=== Agenda ===<br />
<br />
'''The language of presentation will be English.'''<br />
<br />
<table cellpadding="5"><br />
<tr><br />
<th>Time</th><br />
<th>Topic</th><br />
<th>Presenter</th><br />
<th>Description</th><br />
</tr><br />
<br />
<tr><br />
<td valign="top">17:00</td><br />
<td valign="top">Reception</td><br />
<td valign="top">Niko Stotz, itemis AG</td><br />
<td/><br />
</tr><br />
<br />
<tr><br />
<td valign="top">17:05</td><br />
<td valign="top">Down the rabbit hole with Code Recommenders &ndash; and into the cloud</td><br />
<td valign="top">[mailto:andreas.sewe@codetrails.com Andreas Sewe], Codetrails</td><br />
<td>This demo will show a working prototype of a crowd-sourced code recommendation engine. The idea is that with every proposal you select in your code completion, you are sharing data that will make everyone’s code completion smarter. By hosting the engine in the cloud, we collect code completion data from an unlimited community of participating developers. The prototype also includes some basic statistical tools for individual users such as calculating how much time or how many keystrokes the code completion has saved the user.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top">17:25</td><br />
<td valign="top">Eclipse Gemini &ndash; OSGi goes Enterprise</td><br />
<td valign="top">[https://www.xing.com/profile/Jan_Stamer Jan Stamer]</td><br />
<td>The [http://eclipse.org/gemini/ Gemini project] is all about modular implementations of Java EE technology. It is a collection of implementations of some of the OSGi Enterprise specifications. Each sub-project is a separate and standalone project that provides unique functionality. They can be used in isolation, in combination or with other OSGi bundles to compose a desired OSGi runtime.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top">17:45</td><br />
<td valign="top">Contracts for Java (C4J) in Eclipse</td><br />
<td valign="top">[mailto:hagen.buchwald@andrena.de Hagen Buchwald], Verein Karlsruher Software Ingenieure<br/>[http://www.xing.com/profile/Florian_Meyerer Florian Meyerer], Mannheim University</td><br />
<td valign="top">[http://c4j-team.github.io/C4J/ Contracts for Java (C4J)] is a Contracts framework for Java 1.6 and later. The primary goal for C4J is ease of use. Contracts are about design and quality, aspects of programming that a lot programmers don't spend enough time and energy on. Therefore a Contracts framework must be simple and painless to use. At the same time the framework must be powerful. C4J is simple and powerful. And the new [https://github.com/C4J-Team/C4J-Eclipse-Plugin C4J plugin for Eclipse] adds the power of C4J seamlessly to Java projects.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top">18:05</td><br />
<td valign="top">Eclipse Xtend &ndash; A Language Made For Java Developers</td><br />
<td valign="top">[https://www.xing.com/profile/Sebastian_Zarnekow Sebastian Zarnekow], itemis AG</td><br />
<td>Are you waiting for closures in Java 8 or hoping for more type inference in Java 9? Thinking about switching to Scala or even holding your horses for Ceylon or Kotlin?<br />
How about keeping Java where it seems fit, but replacing just its outdated parts with a concise and modern language? What about an enhancement to Java instead of yet another attempt to hire a killer.<br />
<br />
[http://xtend-lang.org/ Xtend] is an an open-source programming language hosted at Eclipse.org and built for Java developers. It reuses Java's keywords, terminology and concepts as much as possible, but abandons some dead freight at the same time. Xtend is a very powerful alternative for implementing Java classes and works great with all the existing libraries. Since the language can be seen as a little complementary add-on to Java, it offers many modern language features that you are currently missing in your daily work. Xtend comes with a variety of goodies reaching from type inference over closures and extension methods up to smart string interpolation that make development great fun, again. And of course there is powerful Eclipse IDE integration available.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top">18:25</td><br />
<td valign="top">Pause</td><br />
<td valign="top"/><br />
<td/><br />
</tr><br />
<br />
<tr><br />
<td valign="top">19:00</td><br />
<td valign="top">Components are not enough: Function oriented development for embedded systems.</td><br />
<td valign="top">[https://www.xing.com/profile/Andreas_Graf Andreas Graf], itemis AG</td><br />
<td>Currently, the development processes for software in automotive are focused on the concept of "components".<br />
However, due to the increasing complexity and interdependence, this approach is reaching its limits. Modern customer functions, like driving assistance, are distributed over a number of software components and ECUs. A component-oriented process does not provide a comprehensive view on a function.<br />
<br />
OEMs see function-oriented processes as a solution to the challenge. Function orientation is an emerging strategic topic in automotive. However, in terms of methodology, tool support and organizational issues, the industry is only taking its first steps.<br />
<br />
In the public sponsored research project "IMES" we are building an Eclipse-based toolchain for function-oriented development. Based on the open source project "EATOP", which provides a basic model-implementation of the EAST-ADL standard, the IMES tool supports the modeling of logical functions, the traceability both to requirements as well as implementation (based on Eclipse RMF). It includes editors for feature models and variant specification (an extension to Eclipse featuremodel) as well as tooling for AUTOSAR models (based on Artop) and can be connected to change management systems.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top">19:20</td><br />
<td valign="top">M2M for Java Developers: MQTT with Eclipse Paho</td><br />
<td valign="top">[https://www.xing.com/profile/Dominik_Obermaier Dominik Obermaier], dc-square GmbH</td><br />
<td>Mobile devices like smartphones and tablet computers became an integral part of our modern world and single-board computers like Raspberry Pi are cheaper today than at any time before. Simple and open Machine-to-Machine (M2M) protocols like MQTT enable these devices to communicate in an efficient manner, even in scenarios with unreliable und instable networks. This talk shows how Eclipse Paho - an Eclipse umbrella project for M2M protocols - can be utilized for professional and personal projects to build efficient and scalable solutions for (mobile) devices.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top">19:40</td><br />
<td valign="top">SiLift: Extending EMF Compare with an Operational View on Model Differences</td><br />
<td valign="top">Timo Kehrer, University of Siegen, Software Engineering Group</td><br />
<td valign="top">Currently available difference tools for models often report huge amounts of low-level model changes in an inconvenient way such that complex model changes are difficult to understand. A promising approach to overcome this problem is to tightly integrate model differencing with model editing. Edit operations have shown to form adequate building blocks for an easier understanding of complex model changes.<br />
<br />
In this talk, we introduce the [http://pi.informatik.uni-siegen.de/Projekte/SiLift/ SiLift] tool environment to flexibly specify and recognize complex changes of EMF-based models. In SiLift, edit operations are specified using EMF Henshin. A low-level difference, i.e. a matching of the models which are to be compared, is obtained using the matching engine of EMF Compare.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top">20:00</td><br />
<td valign="top">The Art of Java Performance Tuning</td><br />
<td valign="top">[http://ed-merks.blogspot.de/ Ed Merks], itemis AG</td><br />
<td>Performance tuning Java is as much an art as it is a science. Understanding the intrinsic performance characteristics of method calls, heap allocations, and casts is essential for developing efficient code at the micro level. Understanding the overall performance of applications as a whole is essential for developing efficient algorithms at the macro level. It's critically important in all cases to measure in several different ways and to double check that those measurements are consistent. It's also critical to beware of the JIT effect: many things get faster with repeated use, even to the point where some things are simply free. In this presentation I will share my experience with performance tuning EMF and EMF-based applications specifically; the insights gained have broad application.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top">20:20</td><br />
<td valign="top">Get Together</td><br />
<td valign="top"/><br />
<td/><br />
</tr><br />
<br />
</table><br />
<br />
=== Who Is Attending ===<br />
<br />
Please use Amiando Web Service to [http://de.amiando.com/EclipseDemoCampKepler2013Stuttgart.html register].<br />
<br />
Please contact Niko Stotz if you have any [mailto:Niko.Stotz@itemis.de questions].<br />
<br />
=== For Bloggers and Users of Twitter, Flickr, etc. ===<br />
<br />
In case you plan to blog or tweet about the Eclipse DemoCamp in Stuttgart, please use the tag "#democampstuttgart" in order to make it easier to find all the comments and pictures. Thanks a lot for telling the world about the event!</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Recommenders/BuildingFromSource&diff=343189Recommenders/BuildingFromSource2013-07-12T07:49:10Z<p>Sewe.cqse.eu: /* Build Prerequisites */</p>
<hr />
<div>__TOC__ <br />
<br />
Building Eclipse Code Recommenders from sources should be pretty easy. If some of the steps below fail - let us know. <br />
<br />
= Build Prerequisites =<br />
<br />
If you want to contribute to Eclipse Code Recommenders, we recommend the latest [http://www.eclipse.org/downloads/packages/eclipse-ide-java-and-dsl-developers/keplerr Eclipse IDE for Java and DSL Developers]; it already contains all the required and recommended features for building our projects in the Eclipse IDE.<br />
<br />
* Required features:<br />
** [http://www.eclipse.org/jdt/ Eclipse Java Development Tools],<br />
** [http://www.eclipse.org/pde/ Eclipse Plug-in Development Environment],<br />
** and [http://www.eclipse.org/xtend/ Xtend]<br />
* Recommended features:<br />
** [http://www.eclipse.org/m2e/ Eclipse Git Team Provider],<br />
** [http://www.eclipse.org/m2e/ Maven Integration for Eclipse],<br />
** and the [http://www.eclipse.org/recommenders/ Code Recommenders Developer Tools], of course<br />
<br />
If you want to build Eclipse Code Recommenders from the command line, you will need [http://maven.apache.org/download.html Apache Maven], version 3.0.x. ('''Note:''' Maven 3.1.0 does not yet work, as Eclipse Tycho is incompatible with it.)<br />
<br />
= Building with Maven Tycho =<br />
<pre>$ git clone http://git.eclipse.org/gitroot/recommenders/org.eclipse.recommenders.git<br />
$ cd org.eclipse.recommenders<br />
$ export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=128m"<br />
$ mvn clean install -P e43<br />
</pre><br />
<br />
= Building from Eclipse Workspace =<br />
<br />
Configuring Eclipse Code Recommenders Workspace for Eclipse is slightly more complicated: <br />
<br />
On command line do: <br />
<pre>$ git clone http://git.eclipse.org/gitroot/recommenders/org.eclipse.recommenders.git<br />
</pre> <br />
<br />
Then, <br />
<br />
#Import all projects into your Eclipse workspace. <br />
# Set workspace encoding to UTF-8.<br />
# <font color=red>Set the workspace's target platform: </font><br />
##Go to /targets/e43/ <br />
##Open ''''e43.target'''' target definition with target platform editor.<br />
##Wait until Eclipse resolved all dependencies. Check the progress view to see when resolving finished. <br />
##Now click on the 'Set as target platform' link on the upper right corner of the editor. <br />
#Wait until workspace is rebuild and all compile errors went away (maybe except from a few projects) <br />
# In the case you see error markers on the projects saying ''Execution environment references were not checked for 'project-name' because no environment descriptions are installed.'' your Eclipse installation is missing an Execution Environment Description (EED) for Java 1.6. See [http://wiki.eclipse.org/index.php/Execution_Environments this page] how to install and use EEDs.<br />
#Done. Start a new Eclipse runtime via the product configuration file located under /etc/eclipse/ide.product<br />
#Remove API Baseline. If you want remove alle errors from the problems view, you have to disable the API Baseline: open the preferences, go to API Baselines and set "Missing API baseline" to ignore.<br />
<br />
= Troubleshooting =<br />
<br />
If anything does not work as expected, report it to http://eclipse.org/forums/eclipse.recommenders. We are glad to lend a hand to get the build working for you.<br />
<br />
<br />
<br />
= For Extenders of Code Recommenders =<br />
<br />
First, an ''extender'' is someone who adds new plug-ins to code recommenders that may or may not use (but not manipulate) existing code of Code Recommenders. In order to reuse our code base, there is a special target platform that contains all dependencies as well as all bundles from the head/e42 update site. The file can be found in etc/targets/e42-extender.target.<br />
<br />
To use this target platform definition, just load the target file (via "Open External File"), and set the target platform by clicking on the link on the upper right. There should be no need to import any of code recommenders plug-ins in your workspace.<br />
<br />
<br />
<br />
[[Category:Recommenders]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Recommenders/BuildingFromSource&diff=343188Recommenders/BuildingFromSource2013-07-12T07:48:32Z<p>Sewe.cqse.eu: Updated build prerequisites</p>
<hr />
<div>__TOC__ <br />
<br />
Building Eclipse Code Recommenders from sources should be pretty easy. If some of the steps below fail - let us know. <br />
<br />
= Build Prerequisites =<br />
<br />
If you want to contribute to Eclipse Code Recommenders, we recommend the latest [http://www.eclipse.org/downloads/packages/eclipse-ide-java-and-dsl-developers/keplerr Eclipse IDE for Java and DSL Developers]; it already contains all the required and recommended features for building our projects in the Eclipse IDE.<br />
<br />
* Required features:<br />
** [http://www.eclipse.org/jdt/ Eclipse Java Development Tools],<br />
** [http://www.eclipse.org/pde/ Eclipse Plug-in Development Environment],<br />
** and [http://www.eclipse.org/xtend/ Xtend]<br />
* Recommended features:<br />
** [http://www.eclipse.org/m2e/ Eclipse Git Team Provider],<br />
** [http://www.eclipse.org/m2e/ Maven Integration for Eclipse],<br />
** and the [www.eclipse.org/recommenders/ Code Recommenders Developer Tools], of course<br />
<br />
If you want to build Eclipse Code Recommenders from the command line, you will need [http://maven.apache.org/download.html Apache Maven], version 3.0.x. ('''Note:''' Maven 3.1.0 does not yet work, as Eclipse Tycho is incompatible with it.)<br />
<br />
= Building with Maven Tycho =<br />
<pre>$ git clone http://git.eclipse.org/gitroot/recommenders/org.eclipse.recommenders.git<br />
$ cd org.eclipse.recommenders<br />
$ export MAVEN_OPTS="-Xmx512m -XX:MaxPermSize=128m"<br />
$ mvn clean install -P e43<br />
</pre><br />
<br />
= Building from Eclipse Workspace =<br />
<br />
Configuring Eclipse Code Recommenders Workspace for Eclipse is slightly more complicated: <br />
<br />
On command line do: <br />
<pre>$ git clone http://git.eclipse.org/gitroot/recommenders/org.eclipse.recommenders.git<br />
</pre> <br />
<br />
Then, <br />
<br />
#Import all projects into your Eclipse workspace. <br />
# Set workspace encoding to UTF-8.<br />
# <font color=red>Set the workspace's target platform: </font><br />
##Go to /targets/e43/ <br />
##Open ''''e43.target'''' target definition with target platform editor.<br />
##Wait until Eclipse resolved all dependencies. Check the progress view to see when resolving finished. <br />
##Now click on the 'Set as target platform' link on the upper right corner of the editor. <br />
#Wait until workspace is rebuild and all compile errors went away (maybe except from a few projects) <br />
# In the case you see error markers on the projects saying ''Execution environment references were not checked for 'project-name' because no environment descriptions are installed.'' your Eclipse installation is missing an Execution Environment Description (EED) for Java 1.6. See [http://wiki.eclipse.org/index.php/Execution_Environments this page] how to install and use EEDs.<br />
#Done. Start a new Eclipse runtime via the product configuration file located under /etc/eclipse/ide.product<br />
#Remove API Baseline. If you want remove alle errors from the problems view, you have to disable the API Baseline: open the preferences, go to API Baselines and set "Missing API baseline" to ignore.<br />
<br />
= Troubleshooting =<br />
<br />
If anything does not work as expected, report it to http://eclipse.org/forums/eclipse.recommenders. We are glad to lend a hand to get the build working for you.<br />
<br />
<br />
<br />
= For Extenders of Code Recommenders =<br />
<br />
First, an ''extender'' is someone who adds new plug-ins to code recommenders that may or may not use (but not manipulate) existing code of Code Recommenders. In order to reuse our code base, there is a special target platform that contains all dependencies as well as all bundles from the head/e42 update site. The file can be found in etc/targets/e42-extender.target.<br />
<br />
To use this target platform definition, just load the target file (via "Open External File"), and set the target platform by clicking on the link on the upper right. There should be no need to import any of code recommenders plug-ins in your workspace.<br />
<br />
<br />
<br />
[[Category:Recommenders]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Kepler_2013/Stuttgart&diff=336718Eclipse DemoCamps Kepler 2013/Stuttgart2013-05-17T06:26:16Z<p>Sewe.cqse.eu: Added a new proposal about a crowd-sourced Eclipse Code Recommenders</p>
<hr />
<div>[[Image:Eclipse_DemoCamp_New.jpg]] [[Eclipse_DemoCamps_Kepler_2013 | What is an Eclipse DemoCamp?]] <br />
<br />
=== Location ===<br />
<br />
TBD, Stuttgart City<br />
<br />
=== Date and Time ===<br />
<br />
Wednesday, 2013-07-17 17:00<br />
<br />
=== Sponsors ===<br />
<br />
This Demo Camp will be sponsored by itemis AG, Eclipse strategic member and the leading company for model-driven software development. <br />
<br />
[[Image:Itemis pos-2.JPG|168x68px]] <br />
<br />
If your company is willing to co-sponsor this event, please contact Niko Stotz.<br />
<br />
=== Organizer ===<br />
<br />
[http://www.xing.com/profile/Niko_Stotz Niko Stotz], [http://www.itemis.de itemis AG]<br />
<br />
=== Agenda ===<br />
<br />
'''The language of presentation will be English.'''<br />
<br />
<table cellpadding="5"><br />
<tr><br />
<th>Time</th><br />
<th>Topic</th><br />
<th>Presenter</th><br />
<th>Description</th><br />
</tr><br />
<br />
<tr><br />
<td valign="top"></td><br />
<td valign="top">Eclipse Xtend &ndash; A Language Made For Java Developers</td><br />
<td valign="top">TBD</td><br />
<td>Are you waiting for closures in Java 8 or hoping for more type inference in Java 9? Thinking about switching to Scala or even holding your horses for Ceylon or Kotlin?<br />
How about keeping Java where it seems fit, but replacing just its outdated parts with a concise and modern language? What about an enhancement to Java instead of yet another attempt to hire a killer.<br />
<br />
[http://xtend-lang.org/ Xtend] is an an open-source programming language hosted at Eclipse.org and built for Java developers. It reuses Java's keywords, terminology and concepts as much as possible, but abandons some dead freight at the same time. Xtend is a very powerful alternative for implementing Java classes and works great with all the existing libraries. Since the language can be seen as a little complementary add-on to Java, it offers many modern language features that you are currently missing in your daily work. Xtend comes with a variety of goodies reaching from type inference over closures and extension methods up to smart string interpolation that make development great fun, again. And of course there is powerful Eclipse IDE integration available.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top"></td><br />
<td valign="top">Eclipse Gemini &ndash; OSGi goes Enterprise</td><br />
<td valign="top">[https://www.xing.com/profile/Jan_Stamer Jan Stamer]</td><br />
<td>The [http://eclipse.org/gemini/ Gemini project] is all about modular implementations of Java EE technology. It is a collection of implementations of some of the OSGi Enterprise specifications. Each sub-project is a separate and standalone project that provides unique functionality. They can be used in isolation, in combination or with other OSGi bundles to compose a desired OSGi runtime.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top"></td><br />
<td valign="top">Components are not enough: Function oriented development for embedded systems.</td><br />
<td valign="top">[https://www.xing.com/profile/Andreas_Graf Andreas Graf], itemis AG</td><br />
<td>Currently, the development processes for software in automotive are focused on the concept of "components".<br />
However, due to the increasing complexity and interdependence, this approach is reaching its limits. Modern customer functions, like driving assistance, are distributed over a number of software components and ECUs. A component-oriented process does not provide a comprehensive view on a function.<br />
<br />
OEMs see function-oriented processes as a solution to the challenge. Function orientation is an emerging strategic topic in automotive. However, in terms of methodology, tool support and organizational issues, the industry is only taking its first steps.<br />
<br />
In the public sponsored research project "IMES" we are building an Eclipse-based toolchain for function-oriented development. Based on the open source project "EATOP", which provides a basic model-implementation of the EAST-ADL standard, the IMES tool supports the modeling of logical functions, the traceability both to requirements as well as implementation (based on Eclipse RMF). It includes editors for feature models and variant specification (an extension to Eclipse featuremodel) as well as tooling for AUTOSAR models (based on Artop) and can be connected to change management systems.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top"></td><br />
<td valign="top">The Art of Java Performance Tuning</td><br />
<td valign="top">[http://ed-merks.blogspot.de/ Ed Merks], itemis AG</td><br />
<td>Performance tuning Java is as much an art as it is a science. Understanding the intrinsic performance characteristics of method calls, heap allocations, and casts is essential for developing efficient code at the micro level. Understanding the overall performance of applications as a whole is essential for developing efficient algorithms at the macro level. It's critically important in all cases to measure in several different ways and to double check that those measurements are consistent. It's also critical to beware of the JIT effect: many things get faster with repeated use, even to the point where some things are simply free. In this presentation I will share my experience with performance tuning EMF and EMF-based applications specifically; the insights gained have broad application.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top"></td><br />
<td valign="top">Contracts for Java in Eclipse (C4J)</td><br />
<td valign="top">[mailto:hagen.buchwald@andrena.de Hagen Buchwald], Verein Karlsruher Software Ingenieure<br/>[mailto:flo.meyerer@gmail.com Florian Meyerer], Mannheim University</td><br />
<td valign="top">tbd<br/><br />
[http://c4j-team.github.io/C4J/ C4J-Framework]<br/><br />
[https://github.com/C4J-Team/C4J-Eclipse-Plugin C4J-Plugin for Eclipse]</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top"></td><br />
<td valign="top">M2M for Java Developers: MQTT with Eclipse Paho</td><br />
<td valign="top">[https://www.xing.com/profile/Dominik_Obermaier Dominik Obermaier], dc-square GmbH</td><br />
<td>Mobile devices like smartphones and tablet computers became an integral part of our modern world and single-board computers like Raspberry Pi are cheaper today than at any time before. Simple and open Machine-to-Machine (M2M) protocols like MQTT enable these devices to communicate in an efficient manner, even in scenarios with unreliable und instable networks. This talk shows how Eclipse Paho - an Eclipse umbrella project for M2M protocols - can be utilized for professional and personal projects to build efficient and scalable solutions for (mobile) devices.</td><br />
</tr><br />
<br />
<tr><br />
<td valign="top"></td><br />
<td valign="top">SiLift: Extending EMF Compare with an Operational View on Model Differences</td><br />
<td valign="top">Timo Kehrer, University of Siegen, Software Engineering Group</td><br />
<td><p>Currently available difference tools for models often report huge amounts of low-level model changes in an inconvenient way such that complex model changes are difficult to understand. A promising approach to overcome this problem is to tightly integrate model differencing with model editing. Edit operations have shown to form adequate building blocks for an easier understanding of complex model changes.</p><br />
<p>In this talk, we introduce the [http://pi.informatik.uni-siegen.de/Projekte/SiLift/ SiLift] tool environment to flexibly specify and recognize complex changes of EMF-based models. In SiLift, edit operations are specified using EMF Henshin. A low-level difference, i.e. a matching of the models which are to be compared, is obtained using the matching engine of EMF Compare.</p></td><br />
</tr><br />
</table><br />
<br />
=== Presenters ===<br />
<br />
*'''Topic:''' Down the rabbit hole with Code Recommenders - and into the cloud<br />
*'''Presenter:''' [mailto:andreas.sewe@codetrails.com Andreas Sewe], Codetrails<br />
*'''Description''': This demo will show a working prototype of a crowd-sourced code recommendation engine. The idea is that with every proposal you select in your code completion, you are sharing data that will make everyone’s code completion smarter. By hosting the engine in the cloud, we collect code completion data from an unlimited community of participating developers. The prototype also includes some basic statistical tools for individual users such as calculating how much time or how many keystrokes the code completion has saved the user.<br />
<br />
=== Who Is Attending ===<br />
<br />
Please use Amiando Web Service to [http://de.amiando.com/EclipseDemoCampKepler2013Stuttgart.html register].<br />
<br />
Please contact Niko Stotz if you have any [mailto:Niko.Stotz@itemis.de questions].<br />
<br />
=== For Bloggers and Users of Twitter, Flickr, etc. ===<br />
<br />
In case you plan to blog or tweet about the Eclipse DemoCamp in Stuttgart, please use the tag "#democampstuttgart" in order to make it easier to find all the comments and pictures. Thanks a lot for telling the world about the event!</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Kepler_2013/Kassel&diff=335383Eclipse DemoCamps Kepler 2013/Kassel2013-05-02T14:20:03Z<p>Sewe.cqse.eu: /* Presenters */</p>
<hr />
<div>[[Image:Eclipse_DemoCamp_New.jpg]] [[Eclipse_DemoCamps_Kepler_2013 | What is an Eclipse DemoCamp?]] <br />
<br />
=== Location ===<br />
<br />
[http://maps.google.com/maps?oe=utf-8&client=firefox-a&ie=UTF8&q=Zirkus+Rambazotti+Kassel&fb=1&hq=Zirkus+Rambazotti&hnear=0x47bb3f4e9f7a6c1d:0x2f84633d58221747,Kassel,+Germany&cid=0,0,12052590713734511144&ll=51.305627,9.443994&spn=0.012073,0.025642&t=m&z=16&vpsrc=6&vps=2&vrp=1&mpnum=1000&ei=0iKqT-PnOdOY_QaQ8dHjBA&ppyss=confirm:0 Circus Rambazotti, Ludwig-Erhard-Str. 21, 34131 Kassel] <br />
<br />
If you travel by train and arrive at the ICE Bahnhof Kassel-Willhelmshöhe, take the Tram 4 and exit at "Marbachshöhe".<br />
<br />
=== Date and Time ===<br />
Thursday, June 20th, 2013, opening 17:00<br />
<br />
=== Sponsors ===<br />
<br />
This Eclipse DemoCamp will be sponsored by [http://www.yatta.de/ Yatta Solutions GmbH]<br />
<br />
[[Image:Yatta Logo 160.png|Yatta Solutions GmbH]]<br />
<br />
=== Organizer ===<br />
<br />
*[http://www.xing.com/profile/Manuel_Bork Manuel Bork], Yatta Solutions<br />
<br />
=== Agenda ===<br />
<br />
TBD<br />
<br />
=== Presenters ===<br />
<br />
If you would like to present at this event, please add your name below.<br />
<br />
# Down the Rabbithole with Code Recommenders, [mailto:andreas.sewe@codetrails.com Andreas Sewe], [http://www.codetrails.com/ Codetrails]<br />
#<br />
#<br />
<br />
=== Who Is Attending ===<br />
<br />
If you plan on attending please add your name and company to the list below. If you have any trouble with the wiki, just send an email to [mailto:manuel.bork@yatta.de Manuel Bork].<br />
<br />
# [http://www.xing.com/profile/Johannes_Jacop Johannes Jacop], [http://www.yatta.de Yatta Solutions] <br />
# [http://www.xing.com/profile/Christian_Schneider219 Dr. Christian Schneider], [http://www.yatta.de Yatta Solutions] <br />
# [http://www.xing.com/profile/Manuel_Bork Manuel Bork], [http://www.yatta.de Yatta Solutions]<br />
# Andreas Sewe [http://www.codetrails.com/ Codetrails]<br />
<br />
=== Past DemoCamps ===<br />
<br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_November_2012/Kassel Eclipse DemoCamp November 2012]<br/><br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_Juno_2012/Kassel Eclipse DemoCamp Juno 2012]<br/><br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_November_2011/Kassel Eclipse DemoCamp November 2011]<br/><br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_Indigo_2011/Kassel Eclipse DemoCamp Indigo 2011]<br/><br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_November_2010/Kassel Eclipse DemoCamp November 2010]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Eclipse_DemoCamps_Kepler_2013/Kassel&diff=335382Eclipse DemoCamps Kepler 2013/Kassel2013-05-02T14:18:36Z<p>Sewe.cqse.eu: /* Who Is Attending */</p>
<hr />
<div>[[Image:Eclipse_DemoCamp_New.jpg]] [[Eclipse_DemoCamps_Kepler_2013 | What is an Eclipse DemoCamp?]] <br />
<br />
=== Location ===<br />
<br />
[http://maps.google.com/maps?oe=utf-8&client=firefox-a&ie=UTF8&q=Zirkus+Rambazotti+Kassel&fb=1&hq=Zirkus+Rambazotti&hnear=0x47bb3f4e9f7a6c1d:0x2f84633d58221747,Kassel,+Germany&cid=0,0,12052590713734511144&ll=51.305627,9.443994&spn=0.012073,0.025642&t=m&z=16&vpsrc=6&vps=2&vrp=1&mpnum=1000&ei=0iKqT-PnOdOY_QaQ8dHjBA&ppyss=confirm:0 Circus Rambazotti, Ludwig-Erhard-Str. 21, 34131 Kassel] <br />
<br />
If you travel by train and arrive at the ICE Bahnhof Kassel-Willhelmshöhe, take the Tram 4 and exit at "Marbachshöhe".<br />
<br />
=== Date and Time ===<br />
Thursday, June 20th, 2013, opening 17:00<br />
<br />
=== Sponsors ===<br />
<br />
This Eclipse DemoCamp will be sponsored by [http://www.yatta.de/ Yatta Solutions GmbH]<br />
<br />
[[Image:Yatta Logo 160.png|Yatta Solutions GmbH]]<br />
<br />
=== Organizer ===<br />
<br />
*[http://www.xing.com/profile/Manuel_Bork Manuel Bork], Yatta Solutions<br />
<br />
=== Agenda ===<br />
<br />
TBD<br />
<br />
=== Presenters ===<br />
<br />
If you would like to present at this event, please add your name below.<br />
<br />
#<br />
#<br />
#<br />
<br />
=== Who Is Attending ===<br />
<br />
If you plan on attending please add your name and company to the list below. If you have any trouble with the wiki, just send an email to [mailto:manuel.bork@yatta.de Manuel Bork].<br />
<br />
# [http://www.xing.com/profile/Johannes_Jacop Johannes Jacop], [http://www.yatta.de Yatta Solutions] <br />
# [http://www.xing.com/profile/Christian_Schneider219 Dr. Christian Schneider], [http://www.yatta.de Yatta Solutions] <br />
# [http://www.xing.com/profile/Manuel_Bork Manuel Bork], [http://www.yatta.de Yatta Solutions]<br />
# Andreas Sewe [http://www.codetrails.com/ Codetrails]<br />
<br />
=== Past DemoCamps ===<br />
<br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_November_2012/Kassel Eclipse DemoCamp November 2012]<br/><br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_Juno_2012/Kassel Eclipse DemoCamp Juno 2012]<br/><br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_November_2011/Kassel Eclipse DemoCamp November 2011]<br/><br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_Indigo_2011/Kassel Eclipse DemoCamp Indigo 2011]<br/><br />
[http://wiki.eclipse.org/Eclipse_DemoCamps_November_2010/Kassel Eclipse DemoCamp November 2010]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2013_Ideas&diff=333329Google Summer of Code 2013 Ideas2013-04-09T19:32:53Z<p>Sewe.cqse.eu: Added missing proposal (new models API) for Code Recommenders</p>
<hr />
<div>[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20&query_format=advanced&keywords_type=allwords&list_id=4495706&bug_status=NEW Existing bugs marked "helpwanted"] are a good source of project ideas.<br />
<br />
= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Workspace-Local Code Search ==<br />
<br />
When writing software, developers frequently find themselves in a situation where they are absolutely certain that someone else must have faced (and solved!) the same problem before, but they just cannot find that piece of code.<br />
This is where the proposed code search feature can help:<br />
Based on the context the developer currently is in (e.g., the current method and the available objects), code search will search through the entire workspace and present pieces of code that match the current context.<br />
For this proposal to work well, the search engine must be (1) fast and (2) present its results in a condensed snippet form, so that the developer can quickly decide which results are worth a closer look.<br />
<br />
A prototype of a code search engine has already been developed as a Master's thesis at Technische Universität Darmstadt.<br />
This project could either build upon that prototype or, taking into account the lessons learned there, start from scratch.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: [https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.codesearch.git/ Prototype implementation in incubator]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=401843 Bugzilla issue]<br />
<br />
Interested students : Kavith Thiranga Lokuhewage (rc404mekt@gmail.com)<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Social Snippets ==<br />
<br />
With [http://snipmatch.com/ SnipMatch], [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders] already offers one way of searching for and accessing snippets.<br />
However, at the moment, there is no easy way to create new snippets and to share these snippets with other developers.<br />
This goal of this proposal is thus to create a social snippets infrastructure, which allows developers to create and rate snippets.<br />
This infrastructure should then support multiple backends, SnipMatch and its collection of snippets being one of them. <br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=401771 Bugzilla issue]<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Social Extdocs ==<br />
<br />
Currently, the Extdoc view provides extended documentation one classes and methods which has been data-mined from code; there is no way for the user to influence the documentation yet. The goal of this proposal is to enhance Extdoc such that users can create, annotate, and rate contributions to the documentation of classes or methods. <br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=404637 Bugzilla issue]<br />
<br />
Interested Student: Dammina Sahabandu<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Usage Data Collection for Code Completion and Beyond ==<br />
<br />
Do you know how much time code completion saves you per day? No? Well, this proposal should address that by (locally) collecting usage data that can answer this and more sophisticated questions. Moreover, the collected data can then be used to make recommendations on the most effective use of your IDE, e.g., recommending a keyboard shortcut that you don't use (and presumably don't even know about).<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: https://git.eclipse.org/r/#/c/10611/ [https://bugs.eclipse.org/bugs/show_bug.cgi?id=401851 Bugzilla issue]<br />
<br />
Interested Student: Timur Achmetow<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Proposal Ranking ==<br />
<br />
Over the years, [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders] has developed and experimented with numerous code completion engines, providing intelligent code completion for method calls, method overrides, call chains and (soon) types, not to mention subwords completion.<br />
In the course of this work, it turned out that the existing ranking mechanisms of JDT leave something to be desired.<br />
The goal of this project is thus to come up with a mechanism that can incorporate a variety of recommenders and produces the ranking the user expects, even if the individual engines disagree on what constitutes the perfect recommendation.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: https://git.eclipse.org/r/#/c/10611/<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=402710 Bugzilla issue]<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: New Models API ==<br />
<br />
Eclipse Code Recommenders draws its knowledge about how to use an API from so-called models. Whenever you trigger code completion, for example, Code Recommenders looks up the correct model and uses it to make a prediction about the method you are most likely to call. Now, code completion is not the only intelligent recommender system in store for Code Recommenders. We have ideas for about a dozen more. Consequently, the logic managing the models needs a big overhaul to cope with this wealth of models.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=403148 Bugzilla issue]<br />
<br />
== [http://www.eclipse.org/vjet/ Eclipse VJET]: Improve VJET's support for JQuery UI ==<br />
<br />
[http://www.eclipse.org/vjet/ VJET] Is a JavaScript IDE which provides the best development experience for developers building object based JavaScript. With content assist for classes which are comparable to Java content assist and support for concepts which are exclusive to JavaScript and javascript frameworks. We are looking for help with improving the Jquery support and supporting the JQuery plugin model. [http://www.eclipse.org/vjet/ VJET] has developed a type system for JavaScript which allows for static and dynamic typing. The primary goal is to add to the JQuery meta type library (currently lives here -http://git.eclipse.org/c/vjet/org.eclipse.vjet.typelibs.git/tree/JQueryTL ) with jQuery UI support. The secondary goal is to come up with an extension to support the JQuery plugin model. <br />
<br />
Possible Mentor: Justin Early (contact us on the [https://dev.eclipse.org/mailman/listinfo/vjet-dev mailing list])<br />
<br />
Interested Student: Atul Pratap Singh<br />
<br />
== [http://www.eclipse.org/vjet/ Eclipse VJET]: Help test and improve VJET's NodeJS support ==<br />
<br />
[http://www.eclipse.org/vjet/ VJET] Is a JavaScript IDE which provides the best development experience for developers building object based JavaScript. With content assist for classes which are comparable to Java content assist and support for concepts which are exclusive to JavaScript and javascript frameworks. We are looking for help with testing NodeJS support provided by VJET and supporting the NodeJS user defined modules. [http://www.eclipse.org/vjet/ VJET] has developed a type system for JavaScript which allows for static and dynamic typing. The primary goal is to test the support for NodeJS that VJET supports. The secondary goal is to come up with an extension to VJET to support the NodeJs module system.<br />
<br />
Possible Mentor: Justin Early (contact us on the [https://dev.eclipse.org/mailman/listinfo/vjet-dev mailing list])<br />
<br />
== [http://www.eclipse.org/platform/overview.php Eclipse Platform]: Create filterable Console View ==<br />
<br />
The console view is a very important tool for developers, the analyse stacktraces here, look at System.out messages, etc. It should allow to have a filter to filter for example for a package name. It should be possible to save defined filters similar to the Android LogCat view based on fields. Another idea is to implement Stack Trace folding as in IntelliJ Idea (search for 'Console Folding'). Optional this work could also start the migration of this view to Eclipse 4.<br />
<br />
Possible Mentor: Lars Vogel and Markus Alexander Kuppe<br />
<br />
Interested student: Lukas Zorich (lukas.zorich@gmail.com)<br />
<br />
== [http://www.eclipse.org/platform/overview.php Eclipse Platform]: Create Eclipse 4 (e4) based Progress View (see [https://bugs.eclipse.org/401655 bug #401655]) ==<br />
<br />
The progress view provides the main status overview for the Jobs API and is used not only in the Eclipse IDE itself but also by many RCP apps. With the move to e4, the progress view has not been adapted to the new API though and thus is currently not useable in plain e4 apps. If time permits other legacy views (e.g. the console view) could be ported to Eclipse 4 too.<br />
<br />
Possible Mentor: Lars Vogel, Markus Alexander Kuppe and Sopot Çela<br />
<br />
== [http://www.eclipse.org/orion/ Eclipse Orion]: Create a app store or portal for Orion plugins ==<br />
<br />
At the moment, the Orion list of PlugIns is housed at a team member's [http://mamacdon.github.com GitHub account] and it's desirable to create a more formal approach to how and where Orion Plugins are managed. This could take into account teams or products which want to host their own (possibly internal) list of approved plugins, for example. This task may also include dynamic lists of plugin providers for an Orion installation. <br />
<br />
Possible Mentor: Ken Walker and Mark Macdonald (contact us on the [https://dev.eclipse.org/mailman/listinfo/orion-dev mailing list])<br />
<br />
== [http://www.eclipse.org/platform/ Eclipse Platform]: Implementing generic in JFace viewers ==<br />
<br />
JFace viewers are heavily used in Eclipse and developers could benefit from Generic support to avoid unnecessary casting. https://bugs.eclipse.org/bugs/show_bug.cgi?id=395213 suggested that we move the JFace viewers to generics. <br />
<br />
Optional this work can include porting certain parts of org.eclipse.ui to the Eclipse 4 infrastructure.<br />
<br />
<br> Possible Mentor: Lars Vogel and Markus Alexander Kuppe<br>Interested non-student: Peter Andberg (peter.andberg@gmail.com) <br><br />
Interested student: Hendrik Still (hendrik.still@gammas.de)<br />
<br />
== [http://www.eclipse.org/nebula/ Eclipse Nebula]: Provide Nebula Integration for WindowBuilder ==<br />
[[Image:gsoc2013wb.png|thumb||200px]]<br />
The Nebula and WindowBuilder projects are seeking a mechanism to enable inclusion of (Nebula) widgets into the WindowBuilder pallete. Nebula users would then be able to effortless use the widgets by using the provided drag and drop mechanism in WindowBuilder. We are looking for a general abstraction that enables us to easily incorporate widgets into the WindowBuilder pallete and let WindowBuilder consume specific widget parameters and hints to optimize the user experience. Tooling and extension points are already available in WindowBuilder and we are looking for ways to leverage this. The inclusion should not only work for Nebula widgets but for all widgets. The solution could include some sort of discovery mechanism to automatically detect and include widgets.<br />
<br />
[https://developers.google.com/java-dev-tools/wbpro/NewComponentsTutorial.pdf New Components Manual]<br />
<br />
[https://developers.google.com/java-dev-tools/wbpro/DesignerCustomizationAPI.pdf Designer Customization]<br />
<br />
<br />
We are looking for creative visually oriented students who love to push pixels. <br />
<br />
Possible Mentor: Wim Jongman<br />
<br />
Interested Student: [mailto:paulconnolly@ittd.ie Paul Connolly]<br />
<br />
== [http://www.eclipse.org/etrice eTrice]: Provide Error Markers and Quick Fixes in State Chart Diagrams ==<br />
<br />
Last year we had three successful [[Google_Summer_of_Code_2012_Ideas#Ideas_around_the_eTrice_project | GSoC projects]].<br />
One of those was the [[Google_Summer_of_Code_2012_Ideas#Extended_Model_Validation_and_State_Graph_Proposal_Generation_Based_on_Protocol_Semantics | Extended Validation and Proposal Generation for State Machines]].<br />
<br />
This year we would like to make the markers (infos and warnings) that are generated by the algorithm available in the diagram.<br />
The goal is to<br />
* provide visual feed back for infos and warnings<br />
* create a mechanism to allow the user to pick from a list of proposals (similar to quick fixes)<br />
<br />
One kind of proposal is that an incoming message should be handled. That could be handled in two ways: add the corresponding trigger to an existing transition starting at this state or<br />
create a new transition with this trigger. To initiate this kind of action a button could be added to Graphiti's context button pad that opens a dialog with a list of proposals or quick fixes.<br />
<br />
For this project some knowledge of [http://www.eclipse.org/graphiti Graphiti] and ideally of eTrice's implementation of the State Machine Editor would be helpful.<br />
<br />
Possible mentor: Henrik Rentz-Reichert<br />
<br />
Interested Student: [mailto:gsocjayant@gmail.com Jayant Gupta]<br />
<br />
== [http://wiki.eclipse.org/Orion Eclipse Orion]: Debugger Plug-in for Client- and Server-side ==<br />
<br />
A debugger to inspect code execution at runtime is an often used tool and taken for granted in mature desktop-based IDEs. This is not yet the case for web-based IDEs like Orion. The goal of this project is to develop a browser-based debugger that integrates into Orion and allows for a consistent use of the IDE without the need to switch to specialized tools when debugging JavaScript on the client-side or some (optimally arbitrary) other programming language on the server-side.<br />
<br />
The principle to control the client and server debugger is the same: through a remote debugging protocol. Therefore it should be possible to use the same UI parts for every line-based debugger that supports remote debugging.<br />
<br />
The Orion project already has a working solution to communicate with the Chrome browser, which can be used as a starting point. The goals would be to<br />
* provide a reusable debugging infrastructure,<br />
* a connection to a client-side and to a server-side debugger and<br />
* a debugger UI that integrates into Orion.<br />
<br />
Possible Mentor: Simon Kaegi<br />
<br />
Possible Student: [mailto:leor.email@gmail.com Leo Roos] ([http://leoroos.wordpress.com/ blog])<br />
<br />
== [http://eclipse.org/nattable/ Nebula NatTable]: CSS styling support ==<br />
<br />
NatTable already supports a flexible way for styling. This styling configuration is currently done in code by setting SWT styles into the ConfigRegistry of NatTable. To separate styling information out of the source code, there should be CSS styling support in NatTable. This way NatTable can be included and styled in an Eclipse 4 application like any other control. <br />
<br />
Possible Mentors: Dirk Fauth, Edwin Park<br />
<br />
== [http://eclipse.org/nattable/ Nebula NatTable]: Next Generation NatTable architecture ==<br />
<br />
NatTable is a framework to create enterprise ready tables/grids to an application that is based on SWT. It is very flexible in terms of configuration and extension and can handle huge datasets. It's huge feature set makes it interesting in various projects and use cases. Unfortunately the current architecture has reached its limits and needs to be overhauled. With this project we would like to: <br />
<br />
*ensure that NatTable will be a project that is important in the future <br />
*lower the costs for learning to use NatTable <br />
*make it easier to configure NatTable <br />
*make it easier to extend NatTable <br />
*add support for additional UI toolkits<br />
<br />
We are currently specifying the new architecture based on dependency injection and the presentation model. For that specification we are working on an experimental branch, to prove that the concept is working. Note that we don't want to throw away the current NatTable code, we want to reuse it by refactoring it to match the new architecture. In various places this might mean to reimplement stuff, in some cases it will simply be removing SWT dependencies and hard references. <br />
<br />
Possible Mentors: Dirk Fauth, Edwin Park <br />
<br />
Interested Student: Timur Achmetow<br />
<br />
== [http://eclipse.org/nattable/ Nebula NatTable]: Next Generation NatTable extensions ==<br />
<br />
One of the main concepts in NatTable is, that is can be used with only the necessary libraries (currently this means SWT), and can be extended with specific extensions (e.g. GlazedLists). For the next generation architecture we would like to extend that approach to make it possible to configure in which environment the NatTable should be used. This includes the selection of the DI container (Eclipse 4, Spring, Guice) and the UI toolkit (SWT, JavaFX, Swing, HTML5). Of course there are others out there that can be added to those lists. This project is intended to create those extensions based on the results of the Next Generation NatTable architecture project. <br />
<br />
Possible Mentors: Dirk Fauth, Edwin Park<br />
<br />
<br />
== [http://www.eclipse.org/platform/ Eclipse Platform]: Implement annotations for databinding ==<br />
<br />
Databinding is in the current version quite a verbose task. By using annotations the required code can be reduced and more readable. This can be done by annotating a field and refering to the bound field with required binding properties. The framework would then need to scan for the annotation and create the bindings.<br />
<br />
This implementation might look like the following:<br />
@Bind(bindCondition=WidgetProperties.text(SWT.Modify), targetClass=Todo.class, targetMethod="summary")<br />
Text text;<br />
<br />
The annotation would then, togeter with the annotated field, have all required information to create observable objets and the binding<br />
<br />
<br> Interested non-student: Peter Andberg (peter.andberg@gmail.com)<br />
<br />
== [http://eclipse.org/gef GEF]: Record figures and HTML-like labels in DOT for Zest ==<br />
<br />
The GEF Zest visualization toolkit contains support for a subset of the Graphviz DOT language (see [[Zest/DOT|DOT for Zest]]). The Graphviz DOT language supports HTML-like labels and record-based nodes (see Graphviz documentation on [http://www.graphviz.org/doc/info/shapes.html#html html shapes] and [http://www.graphviz.org/doc/info/shapes.html#record record shapes]). This allows very versatile renderings and therefore is a widely used feature of the DOT language. The Xtext-based DOT grammar in Zest is compatible with record labels (since they are represented as strings), but the interpreter does not render record nodes yet. HTML-like labels are currently not valid according to the grammar. The goal of this project is to:<br />
<br />
* implement custom figures and render record-based nodes from DOT input<br />
* extend the Xtext-based DOT grammar to support HTML-like labels<br />
* enhance the figures for the many styling options of HTML-like labels<br />
* add HTML-like labels to the DOT export for Zest graphs with record figures<br />
<br />
This feature has been requested by the community (see [https://bugs.eclipse.org/321775 bug 321775] and [https://bugs.eclipse.org/337640 bug 337640]) and its implementation would be a very useful contribution.<br />
<br />
Possible mentor: Fabian Steeg (fsteeg@gmail.com); interested students: add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/gef-dev gef-dev] mailing list (with CC to [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev])<br />
<br />
Interested students: Mayur Patil (ram.nath241089@gmail.com)<br />
<br />
== [[SWTBot]]: Improvements to test Recorder & Generator: Usability, GEF/GMF,... ==<br />
<br />
SWTBot is mainly a high-level API that is meant to interact with Eclipse applications through code with the same "grain" as end-users operate with it. It's a layer on top of SWT that wraps event management in APIs descibing user-actions. These API make it much easier and much more productive to write UI tests.<br/><br />
Recently, a [[SWTBot/Generator|test recorder & generator]] was added to SWTBot. The goal of this recorder is to simply monitor SWT events produced by a normal usage of an application, and to generate some code relying on SWTBot APIs. Using this tool, one can simply reproduce a bug scenario and will immediatly have a code skeletton of a UI tests to reproduce it, saving a lot of time.<br />
<br />
This test recorder and generator is still quite young, and lacks some cool stuff. Here are some area where a contribution would be welcome:<br />
* Support for GEF/GMF events: read in the Draw2d event stack and deduce which operations were actually performed by users and turn them into Java code using SWTBot API.<br />
* Improve usability: Currently starting the recorder is not an easy task (relies on system properties). Also once it is started, it only shows the lines of codes to copy-paste. Some things could be improved to make it more user-friendly (syntax highlighting, automatic creation of a Java file,...)<br />
* Multi-event mappings: Current Test Recorder & Generator associate individual events to UI operation. It's OK for SWTBot, but some more complex SWTBot methods (showView...) actually map multiple events. Generator should support this mutli-event mapping.<br />
<br />
Possible mentors:<br />
* Mickael Istria (JBoss Tools, Red Hat) (mistria@redhat,com)<br />
<br />
Interested students:<br />
* Rohit Agrawal (rohi0012@e.ntu.edu.sg)<br />
<br />
*Kanarupan Kularatnarajah (kanarupanxiii@gmail.com, University of Moratuwa): Worked on Automating UI testing for an Eclipse based product via an integration of Maven and SWTBot. In those test cases, along with several SWT widgets, GEF editor scenarios were included. <br />
<br />
* add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/swtbot-dev swtbot-dev] mailing list (with CC to [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev])<br />
<br />
== Eclipse Packaging Project (EPP) Custom splash to inform users of events/alerts/etc.==<br />
<br />
As a means of drawing more attention to Eclipse Foundation events (e.g. EclipseCon), security alerts, and other activities, create a custom startup ("splash") screen for the Eclipse packages.<br />
<br />
Please see {{Bug|404825}}. Comment on the bug or on the soc-dev mailing list.<br />
<br />
Possible mentors:<br />
<br />
* Wayne Beaton (The Eclipse Foundation)<br />
<br />
== Eclipse JDT: Folding for Java code blocks ==<br />
<br />
Eclipse has general folding functionality for editors (classes, methods, comments). It does not, however, currently have support for folding Java code blocks (any<br />
pair of {...} including if, for, do/while, try/catch/finally, unnamed and synchronized blocks). According to comments on {{Bug|60929}} adding this support should be relatively easy. A Google Code project apparently includes an implementation, but I haven't looked at the it, I don't know how good/useful it is, and the project seems to be dead. At very least, there should be some good ideas in there that can be leveraged to provide a solution. Depending on licensing and provenance, we may even be able to leverage some code from that project.<br />
<br />
Possible mentors:<br />
<br />
* Wayne Beaton (The Eclipse Foundation)<br />
** I am not a committers on the JDT project, which means that I do not have an inside track in terms of getting the code accepted by the project. It would be better to find a mentor from that JDT for this GSoC project.<br />
<br />
[[Category:Google Summer of Code]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2013_Ideas&diff=331566Google Summer of Code 2013 Ideas2013-03-19T16:01:17Z<p>Sewe.cqse.eu: Added links to Bugzilla issues</p>
<hr />
<div>[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20&query_format=advanced&keywords_type=allwords&list_id=4495706&bug_status=NEW Existing bugs marked "helpwanted"] are a good source of project ideas.<br />
<br />
= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Workspace-Local Code Search ==<br />
<br />
When writing software, developers frequently find themselves in a situation where they are absolutely certain that someone else must have faced (and solved!) the same problem before, but they just cannot find that piece of code.<br />
This is where the proposed code search feature can help:<br />
Based on the context the developer currently is in (e.g., the current method and the available objects), code search will search through the entire workspace and present pieces of code that match the current context.<br />
For this proposal to work well, the search engine must be (1) fast and (2) present its results in a condensed snippet form, so that the developer can quickly decide which results are worth a closer look.<br />
<br />
A prototype of a code search engine has already been developed as a Master's thesis at Technische Universität Darmstadt.<br />
This project could either build upon that prototype or, taking into account the lessons learned there, start from scratch.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: [https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.codesearch.git/ Prototype implementation in incubator]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=401843 Bugzilla issue]<br />
<br />
Interested students : Kavith Thiranga Lokuhewage (rc404mekt@gmail.com)<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Social Snippets ==<br />
<br />
With [http://snipmatch.com/ SnipMatch], [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders] already offers one way of searching for and accessing snippets.<br />
However, at the moment, there is no easy way to create new snippets and to share these snippets with other developers.<br />
This goal of this proposal is thus to create a social snippets infrastructure, which allows developers to create and rate snippets.<br />
This infrastructure should then support multiple backends, SnipMatch and its collection of snippets being one of them. <br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: [https://bugs.eclipse.org/bugs/show_bug.cgi?id=401771 Bugzilla issue]<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Social Extdoc ==<br />
<br />
Currently, the Extdoc view provides extended documentation one classes and methods which has been data-mined from code; there is no way for the user to influence the documentation yet. The goal of this proposal is to enhance Extdoc such that users can create, annotate, and rate contributions to the documentation of classes or methods. <br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Usage Data Collection for Code Completion and Beyond ==<br />
<br />
Do you know how much time code completion saves you per day? No? Well, this proposal should address that by (locally) collecting usage data that can answer this and more sophisticated questions. Moreover, the collected data can then be used to make recommendations on the most effective use of your IDE, e.g., recommending a keyboard shortcut that you don't use (and presumably don't even know about).<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Interested Student: Timur Achmetow<br />
<br />
Additional Resources: https://git.eclipse.org/r/#/c/10611/ [https://bugs.eclipse.org/bugs/show_bug.cgi?id=401851 Bugzilla issue]<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Advanced Ranking Mechanisms for Multiple Code Recommenders ==<br />
<br />
Over the years, [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders] has developed and experimented with numerous code completion engines, providing intelligent code completion for method calls, method overrides, call chains and (soon) types, not to mention subwords completion.<br />
In the course of this work, it turned out that the existing ranking mechanisms of JDT leave something to be desired.<br />
The goal of this project is thus to come up with a mechanism that can incorporate a variety of recommenders and produces the ranking the user expects, even if the individual engines disagree on what constitutes the perfect recommendation.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: https://git.eclipse.org/r/#/c/10611/<br />
<br />
== [http://www.eclipse.org/vjet/ Eclipse VJET]: Improve VJET's support for JQuery UI ==<br />
<br />
[http://www.eclipse.org/vjet/ VJET] Is a JavaScript IDE which provides the best development experience for developers building object based JavaScript. With content assist for classes which are comparable to Java content assist and support for concepts which are exclusive to JavaScript and javascript frameworks. We are looking for help with improving the Jquery support and supporting the JQuery plugin model. [http://www.eclipse.org/vjet/ VJET] has developed a type system for JavaScript which allows for static and dynamic typing. The primary goal is to add to the JQuery meta type library (currently lives here -http://git.eclipse.org/c/vjet/org.eclipse.vjet.typelibs.git/tree/JQueryTL ) with jQuery UI support. The secondary goal is to come up with an extension to support the JQuery plugin model. <br />
<br />
Possible Mentor: Justin Early (contact us on the [https://dev.eclipse.org/mailman/listinfo/vjet-dev mailing list])<br />
<br />
Interested Student: Atul Pratap Singh<br />
<br />
== [http://www.eclipse.org/vjet/ Eclipse VJET]: Help test and improve VJET's NodeJS support ==<br />
<br />
[http://www.eclipse.org/vjet/ VJET] Is a JavaScript IDE which provides the best development experience for developers building object based JavaScript. With content assist for classes which are comparable to Java content assist and support for concepts which are exclusive to JavaScript and javascript frameworks. We are looking for help with testing NodeJS support provided by VJET and supporting the NodeJS user defined modules. [http://www.eclipse.org/vjet/ VJET] has developed a type system for JavaScript which allows for static and dynamic typing. The primary goal is to test the support for NodeJS that VJET supports. The secondary goal is to come up with an extension to VJET to support the NodeJs module system.<br />
<br />
Possible Mentor: Justin Early (contact us on the [https://dev.eclipse.org/mailman/listinfo/vjet-dev mailing list])<br />
<br />
== [http://www.eclipse.org/platform/overview.php Eclipse Platform]: Create filterable Console View ==<br />
<br />
The console view is a very important tool for developers, the analyse stacktraces here, look at System.out messages, etc. It should allow to have a filter to filter for example for a package name. It should be possible to save defined filters similar to the Android LogCat view based on fields. Optional this work could also start the migration of this view to Eclipse 4.<br />
<br />
Possible Mentor: Lars Vogel and Markus Alexander Kuppe<br />
<br />
Interested student: Lukas Zorich (lukas.zorich@gmail.com)<br />
<br />
== [http://www.eclipse.org/platform/overview.php Eclipse Platform]: Create Eclipse 4 (e4) based Progress View (see [https://bugs.eclipse.org/401655 bug #401655]) ==<br />
<br />
The progress view provides the main status overview for the Jobs API and is used not only in the Eclipse IDE itself but also by many RCP apps. With the move to e4, the progress view has not been adapted to the new API though and thus is currently not useable in plain e4 apps. If time permits other legacy views (e.g. the console view) could be ported to Eclipse 4 too.<br />
<br />
Possible Mentor: Lars Vogel, Markus Alexander Kuppe and Sopot Çela<br />
<br />
== [http://www.eclipse.org/orion/ Eclipse Orion]: Create a app store or portal for Orion plugins ==<br />
<br />
At the moment, the Orion list of PlugIns is housed at a team member's [http://mamacdon.github.com GitHub account] and it's desirable to create a more formal approach to how and where Orion Plugins are managed. This could take into account teams or products which want to host their own (possibly internal) list of approved plugins, for example. This task may also include dynamic lists of plugin providers for an Orion installation. <br />
<br />
Possible Mentor: Ken Walker and Mark Macdonald (contact us on the [https://dev.eclipse.org/mailman/listinfo/orion-dev mailing list])<br />
<br />
== [http://www.eclipse.org/platform/ Eclipse Platform]: Implementing generic in JFace viewers ==<br />
<br />
JFace viewers are heavily used in Eclipse and developers could benefit from Generic support to avoid unnecessary casting. https://bugs.eclipse.org/bugs/show_bug.cgi?id=395213 suggested that we move the JFace viewers to generics. <br />
<br />
Optional this work can include porting certain parts of org.eclipse.ui to the Eclipse 4 infrastructure.<br />
<br />
<br> Possible Mentor: Lars Vogel and Markus Alexander Kuppe<br>Interested non-student: Peter Andberg (peter.andberg@gmail.com) <br><br />
Interested student: Hendrik Still (hendrik.still@gammas.de)<br />
<br />
== [http://www.eclipse.org/nebula/ Eclipse Nebula]: Provide Nebula Integration for WindowBuilder ==<br />
[[Image:gsoc2013wb.png|thumb||200px]]<br />
The Nebula and WindowBuilder projects are seeking a mechanism to enable inclusion of (Nebula) widgets into the WindowBuilder pallete. Nebula users would then be able to effortless use the widgets by using the provided drag and drop mechanism in WindowBuilder. We are looking for a general abstraction that enables us to easily incorporate widgets into the WindowBuilder pallete and let WindowBuilder consume specific widget parameters and hints to optimize the user experience. Tooling and extension points are already available in WindowBuilder and we are looking for ways to leverage this. The inclusion should not only work for Nebula widgets but for all widgets. The solution could include some sort of discovery mechanism to automatically detect and include widgets.<br />
<br />
[https://developers.google.com/java-dev-tools/wbpro/NewComponentsTutorial.pdf New Components Manual]<br />
<br />
[https://developers.google.com/java-dev-tools/wbpro/DesignerCustomizationAPI.pdf Designer Customization]<br />
<br />
<br />
We are looking for creative visually oriented students who love to push pixels. <br />
<br />
Possible Mentor: Wim Jongman<br />
<br />
== [http://www.eclipse.org/etrice eTrice]: Provide Error Markers and Quick Fixes in State Chart Diagrams ==<br />
<br />
Last year we had three successful [[Google_Summer_of_Code_2012_Ideas#Ideas_around_the_eTrice_project | GSoC projects]].<br />
One of those was the [[Google_Summer_of_Code_2012_Ideas#Extended_Model_Validation_and_State_Graph_Proposal_Generation_Based_on_Protocol_Semantics | Extended Validation and Proposal Generation for State Machines]].<br />
<br />
This year we would like to make the markers (infos and warnings) that are generated by the algorithm available in the diagram.<br />
The goal is to<br />
* provide visual feed back for infos and warnings<br />
* create a mechanism to allow the user to pick from a list of proposals (similar to quick fixes)<br />
<br />
One kind of proposal is that an incoming message should be handled. That could be handled in two ways: add the corresponding trigger to an existing transition starting at this state or<br />
create a new transition with this trigger. To initiate this kind of action a button could be added to Graphiti's context button pad that opens a dialog with a list of proposals or quick fixes.<br />
<br />
For this project some knowledge of [http://www.eclipse.org/graphiti Graphiti] and ideally of eTrice's implementation of the State Machine Editor would be helpful.<br />
<br />
Possible mentor: Henrik Rentz-Reichert<br />
<br />
Interested Student: [mailto:gsocjayant@gmail.com Jayant Gupta]<br />
<br />
== [http://wiki.eclipse.org/Orion Eclipse Orion]: Debugger Plug-in for Client- and Server-side ==<br />
<br />
A debugger to inspect code execution at runtime is an often used tool and taken for granted in mature desktop-based IDEs. This is not yet the case for web-based IDEs like Orion. The goal of this project is to develop a browser-based debugger that integrates into Orion and allows for a consistent use of the IDE without the need to switch to specialized tools when debugging JavaScript on the client-side or (optimally) some other arbitrary language on the server-side.<br />
<br />
The principle to control the client and server debugger is the same: through a remote debugging protocol. Therefore it should be possible to use the same UI parts for every line-based debugger that supports remote debugging just by implementing a connector module, that abstracts from the specifics of the debugging protocol.<br />
<br />
The Orion project already has a working solution to communicate with the Chrome browser, which can be used as an orientation. The goals would be to<br />
* provide a reusable debugging infrastructure,<br />
* a connection to a client-side and to a server-side debugger and<br />
* a debugger UI that integrates into Orion.<br />
<br />
Possible Mentor: Simon Kaegi<br />
<br />
Possible Student: Leo Roos<br />
<br />
== [http://eclipse.org/nattable/ Nebula NatTable]: CSS styling support ==<br />
<br />
NatTable already supports a flexible way for styling. This styling configuration is currently done in code by setting SWT styles into the ConfigRegistry of NatTable. To separate styling information out of the source code, there should be CSS styling support in NatTable. This way NatTable can be included and styled in an Eclipse 4 application like any other control. <br />
<br />
Possible Mentors: Dirk Fauth, Edwin Park<br />
<br />
== [http://eclipse.org/nattable/ Nebula NatTable]: Next Generation NatTable architecture ==<br />
<br />
NatTable is a framework to create enterprise ready tables/grids to an application that is based on SWT. It is very flexible in terms of configuration and extension and can handle huge datasets. It's huge feature set makes it interesting in various projects and use cases. Unfortunately the current architecture has reached its limits and needs to be overhauled. With this project we would like to: <br />
<br />
*ensure that NatTable will be a project that is important in the future <br />
*lower the costs for learning to use NatTable <br />
*make it easier to configure NatTable <br />
*make it easier to extend NatTable <br />
*add support for additional UI toolkits<br />
<br />
We are currently specifying the new architecture based on dependency injection and the presentation model. For that specification we are working on an experimental branch, to prove that the concept is working. Note that we don't want to throw away the current NatTable code, we want to reuse it by refactoring it to match the new architecture. In various places this might mean to reimplement stuff, in some cases it will simply be removing SWT dependencies and hard references. <br />
<br />
Possible Mentors: Dirk Fauth, Edwin Park <br />
<br />
Interested Student: Timur Achmetow<br />
<br />
== [http://eclipse.org/nattable/ Nebula NatTable]: Next Generation NatTable extensions ==<br />
<br />
One of the main concepts in NatTable is, that is can be used with only the necessary libraries (currently this means SWT), and can be extended with specific extensions (e.g. GlazedLists). For the next generation architecture we would like to extend that approach to make it possible to configure in which environment the NatTable should be used. This includes the selection of the DI container (Eclipse 4, Spring, Guice) and the UI toolkit (SWT, JavaFX, Swing, HTML5). Of course there are others out there that can be added to those lists. This project is intended to create those extensions based on the results of the Next Generation NatTable architecture project. <br />
<br />
Possible Mentors: Dirk Fauth, Edwin Park<br />
<br />
<br />
== [http://www.eclipse.org/platform/ Eclipse Platform]: Implement annotations for databinding ==<br />
<br />
Databinding is in the current version quite a verbose task. By using annotations the required code can be reduced and more readable. This can be done by annotating a field and refering to the bound field with required binding properties. The framework would then need to scan for the annotation and create the bindings.<br />
<br />
This implementation might look like the following:<br />
@Bind(bindCondition=WidgetProperties.text(SWT.Modify), targetClass=Todo.class, targetMethod="summary")<br />
Text text;<br />
<br />
The annotation would then, togeter with the annotated field, have all required information to create observable objets and the binding<br />
<br />
<br> Interested non-student: Peter Andberg (peter.andberg@gmail.com)<br />
<br />
== [http://eclipse.org/gef GEF]: Record figures and HTML-like labels in DOT for Zest ==<br />
<br />
The GEF Zest visualization toolkit contains support for a subset of the Graphviz DOT language (see [[Zest/DOT|DOT for Zest]]). The Graphviz DOT language supports HTML-like labels and record-based nodes (see Graphviz documentation on [http://www.graphviz.org/doc/info/shapes.html#html html shapes] and [http://www.graphviz.org/doc/info/shapes.html#record record shapes]). This allows very versatile renderings and therefore is a widely used feature of the DOT language. The Xtext-based DOT grammar in Zest is compatible with record labels (since they are represented as strings), but the interpreter does not render record nodes yet. HTML-like labels are currently not valid according to the grammar. The goal of this project is to:<br />
<br />
* implement custom figures and render record-based nodes from DOT input<br />
* extend the Xtext-based DOT grammar to support HTML-like labels<br />
* enhance the figures for the many styling options of HTML-like labels<br />
* add HTML-like labels to the DOT export for Zest graphs with record figures<br />
<br />
This feature has been requested by the community (see [https://bugs.eclipse.org/321775 bug 321775] and [https://bugs.eclipse.org/337640 bug 337640]) and its implementation would be a very useful contribution.<br />
<br />
Possible mentor: Fabian Steeg (fsteeg@gmail.com); interested students: add yourself here and get in contact on the [https://dev.eclipse.org/mailman/listinfo/gef-dev gef-dev] mailing list (with CC to [https://dev.eclipse.org/mailman/listinfo/soc-dev soc-dev])<br />
<br />
Interested students: Mayur Patil (ram.nath241089@gmail.com)</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Recommenders/CodingConventions&diff=331044Recommenders/CodingConventions2013-03-13T08:56:06Z<p>Sewe.cqse.eu: Point to JLS suggestion on modifier order</p>
<hr />
<div>__TOC__ <br />
<br />
= Introduction =<br />
<br />
This document lists Java coding recommendations for Eclipse Code Recommenders Committers. This text is an excerpt of several sources(http://geosoft.no/development/javastyle.html, Effective Java, Clean Code, ...) but slightly adopted for the Code Recommenders project. The recommendations described here are based on established standards collected from a number of sources, individual experience, local requirements/needs, as well as suggestions given in. If available, examples and explanations are given. Otherwise the references on the books are obtained to allow further research (e.g., "Item NN:" is kept for recommendations taken from Effective Java).<br />
<br />
For students, the referenced books are available at Software Technology group and can be lent.<br />
<br />
== Layout of the Recommendation. ==<br />
<br />
The recommendations are grouped by topic and each recommendation is numbered to make it easier to refer to during reviews. <br />
<br />
Layout for the recommendations is as follows: <br />
<br />
#n. Guideline short description <br />
#Example if applicable <br />
#Motivation, background and additional information.<br />
<br />
The motivation section is important. Coding standards and guidelines tend to start "religious wars", and it is important to state the background for the recommendation. <br />
<br />
== Recommendation Importance ==<br />
<br />
In the guideline sections the terms '''must''', '''should''' and '''can''' have special meaning. A must requirement must be followed, a should is a strong recommendation, and a can is a general guideline. <br />
<br />
== Automatic Style Checking ==<br />
<br />
Many tools provide automatic code style checking and automated code formatting. Checkstyle by Oliver Burn is probably one of the most popular of such tools. An Eclipse integration for Checkstyle can be found here http://eclipse-cs.sourceforge.net. <br />
<br />
To use Checkstyle with Code Recommenders guidelines please use this xml configuration file: &lt;TODO&gt;&nbsp;<br />
<br />
= General Recommendation =<br />
<br />
== Any violation to the guide is allowed if it enhances readability. ==<br />
<br />
The main goal of the recommendation is to improve readability and thereby the understanding and the maintainability and general quality of the code. It is impossible to cover all the specific cases in a general guide and the programmer should be flexible.<br />
<br />
== No code without license header! ==<br />
<br />
At Eclipse every java source code file (at least) needs an EPL license header '''BEFORE''' it is checked in. The typical license header looks like this: <br />
<pre>/**<br />
* Copyright (c) 2010 Darmstadt University of Technology.<br />
* All rights reserved. This program and the accompanying materials<br />
* are made available under the terms of the Eclipse Public License v1.0<br />
* which accompanies this distribution, and is available at<br />
* http://www.eclipse.org/legal/epl-v10.html<br />
*<br />
* Contributors:<br />
* Marcel Bruch - initial API and implementation.<br />
*/<br />
package org.eclipse.recommenders.internal.rcp.codecompletion;<br />
<br />
import ...<br />
public class CompilerAstCompletionNodeFinder extends ASTVisitor {<br />
...<br />
}<br />
</pre> <br />
Adopt the copyright header and Contributors section according to your affiliation and name. Inform your build master if you are using a new license. Otherwise it may break the build.<br />
<br />
== No check-in without running ''mvn clean install'' locally. ==<br />
<pre>$ pwd<br />
/Users/Marcel/Workspaces/code-recommenders/public/org.eclipse.recommenders.parent<br />
$ mvn&nbsp;clean install<br />
... wait a few minutes and check the build results<br />
</pre> <br />
The one who breaks the build... you already know what happens, right?<br />
<br />
= Naming Conventions =<br />
<br />
== Project Naming Conventions ==<br />
<br />
There are several kinds of projects: <br />
<br />
*Plug-in projects<br />
*Feature (source) projects<br />
*Test plug-in or fragment projects<br />
*Test fixture projects<br />
*Repository projects<br />
*Product projects<br />
*Releng projects (including target platform definitions etc.)<br />
<br />
Finding appropriate names for projects is challenging. Eclipse defines many package naming conventions but only few project naming conventions. The guiding principle to name a plug-in is to name the project after its main package (yes, there should only be one, and yes, this one should be unique to all plug-ins). This section gives some additional naming conventions for Code Recommenders project. Note, that Code Recommenders have RCP as well as server plug-ins which makes the naming convention a bit harder.<br />
<br />
<br />
=== Plug-in Naming Conventions ===<br />
<br />
Plug-in names follow the standard Eclipse Naming conventions. That means that (i) the '''project name on disk is the same as the plug-in id''' and (ii) plug-ins are named after their primary package. We recommend to flag plug-ins with a '''platform flag'''. Plug-ins that are considered to run on a server platform should be flagged with ''server'', plug-ins considered to run inside Eclipse RCP with ''rcp'', and plug-ins that can run on any platform without any platform flag. <br />
<br />
The general naming schema for plug-ins is as follows: <br />
<pre>plug-in id:<br />
<br />
org.eclipse.recommenders.&lt;component&gt;[""|.rcp|.server][.*]<br />
<br />
<br />
source plug-in id:<br />
<br />
org.eclipse.recommenders.&lt;component&gt;[""|.rcp|.server][.*].source <br />
<br />
<br />
platform flag:<br />
<br />
[""|.rcp|.server]<br />
</pre> <br />
<br> <br />
<br />
Examples: <br />
<pre>org.eclipse.recommenders.utils<br />
org.eclipse.recommenders.utils.gson<br />
org.eclipse.recommenders.utils.rcp<br />
org.eclipse.recommenders.utils.web (put the webclient in here?)<br />
<br />
org.eclipse.recommenders.injection<br />
<br />
<br />
org.eclipse.recommenders.jayes<br />
org.eclipse.recommenders.bayesnet&nbsp;???<br />
<br />
"rcp core plugins - no component since these plug-ins offer central services":<br />
org.eclipse.recommenders.rcp&nbsp;<br />
org.eclipse.recommenders.rcp.builder<br />
org.eclipse.recommenders.rcp.store<br />
org.eclipse.recommenders.rcp.completion<br />
<br />
org.eclipse.recommenders.overrides.rcp<br />
org.eclipse.recommenders.chain.rcp<br />
org.eclipse.recommenders.subwords.rcp<br />
<br />
<br />
<br />
<br />
org.eclipse.recommenders.analysis<br />
org.eclipse.recommenders.analysis.rcp<br />
<br />
org.eclipse.recommenders.codesearch (&lt;-- implicit commons)<br />
org.eclipse.recommenders.codesearch.rcp<br />
org.eclipse.recommenders.codesearch.server<br />
<br />
org.eclipse.recommenders.snipmatch (&lt;-- implicit commons)<br />
org.eclipse.recommenders.snipmatch.rcp<br />
org.eclipse.recommenders.snipmatch.server<br />
<br />
org.eclipse.recommenders.stacktrace (&lt;-- implicit commons)<br />
org.eclipse.recommenders.stacktrace.rcp<br />
org.eclipse.recommenders.stacktrace.server<br />
<br />
org.eclipse.recommenders.calls (&lt;-- implicit commons)<br />
org.eclipse.recommenders.calls.server&nbsp;???<br />
org.eclipse.recommenders.calls.rcp<br />
</pre><br />
<br />
=== Test Projects Naming Convention ===<br />
<br />
Test projects are mostly fragments. They use the same naming conventions as plug-ins except that they use the '''tests''' flag right after the project name (i.e. org.eclipse.recommenders.tests). This practice is recommended by the Eclipse architecture council.<br />
<br />
Schema:<br />
<pre><br />
tests project id:<br />
<br />
org.eclipse.recommenders.tests.&lt;component&gt;[.*]<br />
<br />
source tests project id (pure virtual - used in source features at most):<br />
<br />
org.eclipse.&lt;subproject&gt;.tests.&lt;component&gt;[.*].source<br />
</pre><br />
<br />
Usually, these names look like the plug-in name they contribute tests for but with the additional '''tests''' flag. Examples:<br />
<pre><br />
org.eclipse.recommenders.tests.calls.rcp<br />
org.eclipse.recommenders.tests.rcp.builder<br />
</pre><br />
<br />
Test projects may offer common test infrastructure that may be reused between several test projects. These general purpose project may declare their own namespaces but should consider using the '''commons''' or '''shared''' namespace, e.g., org.eclipse.recommenders.tests.commons or org.eclipse.recommenders.tests.shared.<br />
<br />
=== Feature Project Naming Convention ===<br />
To line up the names according to the tests convention, we decided to use the '''feature''' flag and put it (similar to tests) directly behind the org.eclipse.recommenders prefix.<br />
<br />
Schema:<br />
<pre><br />
feature id: <br />
<br />
org.eclipse.recommenders.feature.&lt;component&gt;[.*]<br />
<br />
<br />
source feature id:<br />
<br />
org.eclipse.recommenders.feature.&lt;component&gt;[.*].source<br />
</pre><br />
<br />
Examples:<br />
<pre><br />
org.eclipse.recommenders.feature.calls.rcp<br />
org.eclipse.recommenders.feature.calls.rcp.source<br />
</pre><br />
<br />
There may be additional feature '''packagings''' such as special packages for e4, rcp (==e3), server etc. The '''source''' flag is always the last segment in the feature id.<br />
<br />
=== P2 Repository Projects ===<br />
<br />
P2 repository projects should be prefixed with a '''repository''' flag.<br />
<br />
Schema:<br />
<pre><br />
<br />
p2 repository id:<br />
<br />
org.eclipse.recommenders.repository.&lt;distribution&gt;.[variant]<br />
</pre><br />
<br />
Examples:<br />
<pre><br />
org.eclipse.recommenders.repository{.all}<br />
org.eclipse.recommenders.repository.rcp<br />
org.eclipse.recommenders.repository.e4<br />
org.eclipse.recommenders.repository.server<br />
</pre><br />
<br />
=== Product Projects ===<br />
<br />
Products are currently used to build easy-to-install server distributions allowing developers to create an in-house knowledge base using code recommenders. More such packages may follow. Product projects should be prefixed with a '''product''' flag as follows.<br />
<br />
Schema:<br />
<pre><br />
<br />
product id:<br />
<br />
org.eclipse.recommenders.product.&lt;distribution&gt;.[variant]<br />
</pre><br />
<br />
Examples:<br />
<pre><br />
org.eclipse.recommenders.product.server<br />
</pre><br />
<br />
the distribution template should pickup the platform flag as specified for plug-ins and features.<br />
<br />
== Project Disk Layout ==<br />
<br />
Git repositories should be structured following this layout:<br />
<br />
<pre><br />
/<br />
pom.xml (general settings such as versions, compiler settings etc.; group id=org.eclipse.recommenders)<br />
plugins/<br />
pom.xml (specific build settings)<br />
org.eclipse.recommenders.*<br />
features/<br />
pom.xml (if needed)<br />
org.eclipse.recommenders.feature.*<br />
org.eclipse.recommenders.feature.*.source<br />
tests/<br />
pom.xml (specific test settings)<br />
org.eclipse.recommenders.tests.*<br />
fixtures/<br />
org.eclipse.recommenders.fixture.*<br />
repositories/<br />
org.eclipse.recommenders.repository.*<br />
build/<br />
org.eclipse.recommenders.build.*<br />
products/<br />
org.eclipse.recommenders.product.*<br />
</pre><br />
<br />
Using flags such as '''feature, build, tests''' etc. seems redundant for project names given this disk layout. However, having all these projects in a single Eclipse workspace requires all projects to have a unique name. This is a bit redundant but I think an acceptable approach.<br />
<br />
We considered using a per-component layout but this seems to be too much overhead given that our components consists of just a few plug-ins (sometimes just one project), and thus, are yet too small.<br />
<br />
== Code Naming Conventions ==<br />
<br />
=== Names representing packages should be in all lower case. ===<br />
<pre> mypackage, com.company.application.ui </pre> <br />
Package naming convention used by Sun for the Java core packages. The initial package name representing the domain name must be in lower case.<br> <br />
<br />
<br> <br />
<br />
=== Eclipse Package Naming Conventions ===<br />
<br />
At Eclipse there are a set of naming conventions described in great detail here: [[Naming_Conventions|Eclipse general naming conventions]]. This section summarizes them and add a few Code Recommenders specifc ones.<br><br />
<br />
<br />
<br />
All packages start with: <br />
<pre>org.eclipse.recommenders.*<br />
</pre> <br />
Internal packages always start with <br />
<pre>org.eclipse.recommenders.internal.* // NOT org.eclipse.recommenders.other.package.internal;<br />
// NOT org.eclipse.recommenders.other.internal.package;<br />
</pre> <br />
Test packages start with <br />
<pre>org.eclipse.recommenders.tests.* // NOT org.eclipse.recommenders.other.package.tests;<br />
// NOT org.eclipse.recommenders.other.tests.package;<br />
</pre> <br />
<br> Example packages start with <br />
<pre>org.eclipse.recommenders.examples.* // NOT org.eclipse.recommenders.other.package.examples;<br />
// NOT org.eclipse.recommenders.other.examples.package;<br />
</pre> <br />
General package naming recommendations <br />
<pre>org.eclipse.recommenders.&lt;component&gt;[.*].wiring --&gt; classes that contain glue code to configure and wire objects such as Google Guice modules, web service descriptors etc.<br />
org.eclipse.recommenders.&lt;component&gt;[.*].net --&gt; classes that contain mostly classes for network communication<br />
org.eclipse.recommenders.tests.&lt;component&gt;[.*].interactive --&gt; classes that contain interactive (i.e., manual) test suites (Eclipse convention)<br />
</pre><br />
<br />
=== Names representing types must be nouns and written in mixed case starting with upper case.<br> ===<br />
<pre>Line, AudioSystem</pre> <br />
Common practice in the Java development community and also the type naming convention used by Sun for the Java core packages.<br> <br />
<br />
=== Interfaces follow the Eclipse Style I[TypeName] convention ===<br />
<pre>public interface IVariableUsageResolver // NOT just VariableUsageResolver<br />
{<br />
...<br />
}<br />
</pre> <br />
The I[TypeName] convention allows developers to quickly assess the relevant interfaces in a package. Like it or not - this is an Eclipse convention we have to obey. <br />
<br />
=== Variable names must be in mixed case starting with lower case.<br> ===<br />
<pre>line, audioSystem</pre> <br />
Common practice in the Java development community and also the naming convention for variables used by Sun for the Java core packages. Makes variables easy to distinguish from types, and effectively resolves potential naming collision as in the declaration Line line; <br />
<br />
=== Names representing constants (final variables) must be all uppercase using underscore to separate words. ===<br />
<pre>MAX_ITERATIONS, COLOR_RED</pre> <br />
Common practice in the Java development community and also the naming convention used by Sun for the Java core packages. <br />
<br />
TODO&nbsp;:Add section about enums <br />
<br />
=== Names representing methods must be verbs and written in mixed case starting with lower case. ===<br />
<pre>getName(), computeTotalWidth()</pre> <br />
Common practice in the Java development community and also the naming convention used by Sun for the Java core packages. This is identical to variable names, but methods in Java are already distinguishable from variables by their specific form. <br />
<br />
=== Abbreviations and acronyms should not be uppercase when used as name. ===<br />
<pre>exportHtmlSource(); // NOT: exportHTMLSource();<br />
openDvdPlayer(); // NOT: openDVDPlayer();<br />
</pre> <br />
Using all uppercase for the base name will give conflicts with the naming conventions given above. A variable of this type whould have to be named dVD, hTML etc. which obviously is not very readable. Another problem is illustrated in the examples above; When the name is connected to another, the readability is seriously reduced; The word following the acronym does not stand out as it should. <br />
<br />
TODO <br />
<br />
liste der Standard abkürzungen: <br />
<br />
ast -&gt; jdt.deom rec -&gt; recommenders jdt -&gt; IJavaElement compiler -&gt; compiler internal <br />
<br />
cu -&gt; compilationUnit -&gt; preferred compilationUnit (no abbrev) <br />
<br />
=== Private class variables must not have any field prefix or suffix. ===<br />
<pre>class Person<br />
{<br />
private String name; // NOT private String _name;<br />
// NOT private String fName;<br />
// NOT private String name_;<br />
...<br />
}<br />
</pre> <br />
<br> <br />
<pre>void setName(String name)<br />
{<br />
this.name = name; // NOT name_= name;<br />
}<br />
</pre> <br />
To eliminate misinterpretations qualify field puts with this. and use the same names. Use IDE highlighting settings to make more visible on which kind of variable you are working. <br />
<br />
TODO <br />
<br />
=== Generic variables should have the same name as their type. ===<br />
<pre>void setTopic(Topic topic) // NOT: void setTopic(Topic value)<br />
// NOT: void setTopic(Topic aTopic)<br />
// NOT: void setTopic(Topic t) <br />
<br />
void connect(Database database) // NOT: void connect(Database db)<br />
// NOT: void connect(Database oracleDB)<br />
<br />
</pre> <br />
Reduce complexity by reducing the number of terms and names used. Also makes it easy to deduce the type given a variable name only. If for some reason this convention doesn't seem to fit it is a strong indication that the type name is badly chosen. <br />
<br />
Non-generic variables have a role. These variables can often be named by combining role and type: <br />
<pre>Point startingPoint, centerPoint;<br />
Name loginName;<br />
</pre> <br />
=== All names should be written in English. ===<br />
<br />
English is the preferred language for international development. <br />
<br />
=== Variables with a large scope should have long names, variables with a small scope can have short names ===<br />
<br />
Scratch variables used for temporary storage or indices are best kept short. A programmer reading such variables should be able to assume that its value is not used outside a few lines of code. Common scratch variables for integers are i, j, k, m, n and for characters c and d. <br />
<br />
=== The name of the object is implicit, and should be avoided in a method name. ===<br />
<pre>line.getLength(); // NOT: line.getLineLength();</pre> <br />
The latter might seem natural in the class declaration, but proves superfluous in use, as shown in the example.<br />
<br />
== Specific Naming Conventions ==<br />
<br />
=== The terms ''get/set'' must be used where an attribute is accessed directly. ===<br />
<pre>employee.getName();<br />
employee.setName(name);<br />
<br />
matrix.getElement(2, 4);<br />
matrix.setElement(2, 4, value);<br />
</pre> <br />
Common practice in the Java community and the convention used by Sun for the Java core packages. Getters should not change the internal state of the object. Exceptions may be lazy initializers. Getter should actually return something&nbsp;:-) <br />
<br />
NOTE: this is a pure GET. No real computation effort needed. <br />
<br />
=== ''is'' prefix should be used for boolean variables and methods. ===<br />
<pre>isSet, isVisible, isFinished, isFound, isOpen</pre> <br />
This is the naming convention for boolean methods and variables used by Sun for the Java core packages. Using the is prefix solves a common problem of choosing bad boolean names like ''status'' or ''flag''. ''isStatus'' or ''isFlag'' simply doesn't fit, and the programmer is forced to chose more meaningful names. <br />
<br />
Setter methods for boolean variables must have set prefix as in: <br />
<pre>void setFound(boolean isFound);</pre> <br />
There are a few alternatives to the is prefix that fits better in some situations. These are ''has'', ''can'' and ''should'' prefixes: <br />
<pre>boolean hasLicense();<br />
boolean canEvaluate();<br />
boolean shouldAbort = false;<br />
</pre> <br />
=== The term ''compute'' can be used in methods where something is computed. ===<br />
<pre>valueSet.computeAverage();<br />
matrix.computeInverse()<br />
</pre> <br />
Give the reader the immediate clue that this is a potential time consuming operation, and if used repeatedly, he might consider caching the result. Consistent use of the term enhances readability. <br />
<br />
=== The term find can be used in methods where something is looked up. ===<br />
<pre>vertex.findNearestVertex();<br />
matrix.findSmallestElement();<br />
node.findShortestPath(Node destinationNode);<br />
</pre> <br />
Give the reader the immediate clue that this is a simple look up method with a minimum of computations involved. Consistent use of the term enhances readability. <br />
<br />
=== The term ''initialize'' can be used where an object or a concept is established. ===<br />
<pre>printer.initializeFontSet();</pre> <br />
The American ''initialize'' should be preferred over the English ''initialise''. Abbreviation ''init'' should be avoided. <br />
<br />
<br> <br />
<br />
The use of ''initializeXYZ()'' in constructors to initialize complex fields is preferred over direct field initalizations. <br />
<pre><br />
Set&lt;Statements&gt; supportedCompletionRequests;<br />
// NOT Set&lt;Statements&gt; supportedCompletionNodes = createSupportedCompletionRequest()<br />
<br />
public CallsCompletionEngine(..) {<br />
...<br />
initializeSuportedCompletionRequests();<br />
}<br />
<br />
private void initializeSuportedCompletionRequests() <br />
{<br />
supportedCompletionRequests = Sets.newHashSet();<br />
supportedCompletionRequests.add(CompletionOnMemberAccess.class);<br />
supportedCompletionRequests.add(CompletionOnMessageSend.class);<br />
supportedCompletionRequests.add(CompletionOnQualifiedNameReference.class);<br />
supportedCompletionRequests.add(CompletionOnSingleNameReference.class);<br />
}<br />
</pre> <br />
=== JFC (Java Swing) and SWT variables should be suffixed by the element type. ===<br />
<pre>widthScale, nameTextField, leftScrollbar, mainPanel, fileToggle, minLabel, printerDialog</pre> <br />
Enhances readability since the name gives the user an immediate clue of the type of the variable and thereby the available resources of the object. <br />
<br />
=== Plural form should be used on names representing a collection of objects. ===<br />
<pre>Collection&lt;Point&gt; points;<br />
int[] values;<br />
</pre> <br />
Enhances readability since the name gives the user an immediate clue of the type of the variable and the operations that can be performed on its elements. <br />
<br />
=== ''numberOf'' prefix should be used for variables representing a number of objects. ===<br />
<pre>numberOfPoints, numberOfLines</pre> <br />
Note that Sun use num prefix in the core Java packages for such variables. This is probably meant as an abbreviation of number of, but as it looks more like number it makes the variable name strange and misleading. If "number of" is the preferred phrase, ''numberOf'' prefix can be used instead of just ''n''. ''num'' prefix must not be used. <br />
<br />
<br> <br />
<br />
=== Iterator variables should be called it ===<br />
<pre>for (Iterator it = points.iterator(); it.hasNext(); )<br />
{<br />
...<br />
} <br />
<br />
for (int i = 0; i &lt; numberOfTables; i++)<br />
{<br />
...<br />
}<br />
</pre> <br />
=== Complement names must be used for complement entities. ===<br />
<pre> <br />
get/set, add/remove, create/destroy, start/stop, insert/delete,<br />
increment/decrement, old/new, begin/end, first/last, up/down, min/max,<br />
next/previous, old/new, open/close, show/hide, suspend/resume, etc.<br />
</pre> <br />
Reduce complexity by symmetry. <br />
<br />
=== Abbreviations in names should be avoided. ===<br />
<pre>computeAverage(); // NOT: compAvg();<br />
ActionEvent event; // NOT: ActionEvent e;<br />
catch (Exception exception) { // NOT: catch (Exception e) {<br />
<br />
</pre> <br />
There are two types of words to consider. First are the common words listed in a language dictionary. These must never be abbreviated. Never write: <br />
<br />
cmd instead of command<br> comp instead of compute<br> cp instead of copy<br> e instead of exception<br> init instead of initialize<br> pt instead of point<br> etc. <br />
<br />
Then there are domain specific phrases that are more naturally known through their acronym or abbreviations. These phrases should be kept abbreviated. Never write: <br />
<br />
HypertextMarkupLanguage instead of html<br> CentralProcessingUnit instead of cpu<br> PriceEarningRatio instead of pe<br> etc. <br />
<br />
TODO: cu, exception changed <br />
<br />
=== Negated boolean variable names must be avoided. ===<br />
<pre>bool isError; // NOT: isNoError<br />
bool isFound; // NOT: isNotFound<br />
</pre> <br />
The problem arise when the logical not operator is used and double negative arises. It is not immediately apparent what ''!isNotError'' means. <br />
<br />
=== Associated constants (final variables) should be prefixed by a common type name. ===<br />
<pre>final int COLOR_RED = 1;<br />
final int COLOR_GREEN = 2;<br />
final int COLOR_BLUE = 3;<br />
</pre> <br />
This indicates that the constants belong together, and what concept the constants represents. <br />
<br />
An alternative to this approach is to put the constants inside an interface effectively prefixing their names with the name of the interface: <br />
<pre>interface Color<br />
{<br />
final int RED = 1;<br />
final int GREEN = 2;<br />
final int BLUE = 3;<br />
}<br />
</pre> <br />
<br> <br />
<br />
=== Exception classes should be suffixed with Exception. ===<br />
<pre>class AccessException extends Exception{...}</pre> <br />
Exception classes are really not part of the main design of the program, and naming them like this makes them stand out relative to the other classes. This standard is followed by Sun in the basic Java library.<br />
<br />
= General Programming =<br />
<br />
== Creating and Destroying Objects ==<br />
=== Item 1: Consider static factory methods instead of constructors ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 2: Consider a builder when faced with many constructor parameters ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 3: Enforce the singleton property with a private constructor or an enum type ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 4: Enforce noninstantiability with a private constructor ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 5: Avoid creating unnecessary objects ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 6: Eliminate obsolete object references ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 7: Avoid finalizers ===<br />
see ''"Effective Java"'' for details.<br />
<br />
== Methods Common to All Objects ==<br />
=== Item 8: Obey the general contract when overriding equals===<br />
see ''"Effective Java"'' for details.<br />
=== Item 9: Always override hashCode when you override equals ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 10: Always override toString ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 11: Override clone judiciously<br />
=== Item 12: Consider implementing Comparable ===<br />
see ''"Effective Java"'' for details.<br />
<br />
== Generics ==<br />
=== Item 23: Don’t use raw types in new code ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 24: Eliminate unchecked warnings ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 25: Prefer lists to arrays ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 26: Favor generic types ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 27: Favor generic methods ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 28: Use bounded wildcards to increase API flexibility ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 29: Consider typesafe heterogeneous containers ===<br />
see ''"Effective Java"'' for details.<br />
<br />
<br />
== General Programming Style ==<br />
<br />
=== Item 45: Minimize the scope of local variables ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 46: Prefer for-each loops to traditional for loops ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 47: Know and use the libraries ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 48: Avoid float and double if exact answers are required ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 49: Prefer primitive types to boxed primitives ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 50: Avoid strings where other types are more appropriate ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 51: Beware the performance of string concatenation ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 52: Refer to objects by their interfaces ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 53: Prefer interfaces to reflection ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 54: Use native methods judiciously ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 55: Optimize judiciously ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 56: Adhere to generally accepted naming conventions ===<br />
see ''"Effective Java"'' for details.<br />
<br />
<br />
<br />
== Exceptions ==<br />
=== Item 57: Use exceptions only for exceptional conditions ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 58: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 59: Avoid unnecessary use of checked exceptions ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 60: Favor the use of standard exceptions ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 61: Throw exceptions appropriate to the abstraction ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 62: Document all exceptions thrown by each method ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 63: Include failure-capture information in detail messages ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 64: Strive for failure atomicity ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 65: Don’t ignore exceptions ===<br />
see ''"Effective Java"'' for details.<br />
<br />
<br />
<br />
<br />
= Statements =<br />
<br />
== Package and Import Statements ==<br />
<br />
=== The package statement must be the first statement of the file. All files should belong to a specific package. ===<br />
The package statement location is enforced by the Java language. Letting all files belong to an actual (rather than the Java default) package enforces Java language object oriented programming techniques.<br />
<br />
=== The import statements must follow the package statement. import statements should be sorted with the most fundamental packages first, and grouped with associated packages together and one blank line between groups.<br />
<pre><br />
import java.io.IOException;<br />
import java.net.URL;<br />
<br />
import java.rmi.RmiServer;<br />
import java.rmi.server.Server;<br />
<br />
import javax.swing.JPanel;<br />
import javax.swing.event.ActionEvent;<br />
<br />
import org.linux.apache.server.SoapServer;<br />
</pre><br />
<br />
<br />
The import statement location is enforced by the Java language. The sorting makes it simple to browse the list when there are many imports, and it makes it easy to determine the dependiencies of the present package The grouping reduce complexity by collapsing related information into a common unit.<br />
<br />
Your IDE supports you on this. Check out your settings.<br />
<br />
=== Imported classes should always be listed explicitly. ===<br />
<br />
<pre><br />
import java.util.List; // NOT: import java.util.*;<br />
import java.util.ArrayList;<br />
import java.util.HashSet;<br />
</pre><br />
<br />
Importing classes explicitly gives an excellent documentation value for the class at hand and makes the class easier to comprehend and maintain.<br />
<br />
Your IDE will always keep the import list minimal and up to date - if you enable this feature in your preferences.<br />
<br />
== Classes and Interfaces ==<br />
<br />
=== Class and Interface declarations should be organized in the following manner: ===<br />
<pre><br />
Class/Interface documentation.<br />
class or interface statement.<br />
Class (static) variables in the order public, protected, package (no access modifier), private.<br />
Instance variables in the order public, protected, package (no access modifier), private.<br />
Constructors.<br />
Methods (in order they are used in code AKA vertical density).<br />
</pre><br />
<br />
Reduce complexity by making the location of each class element predictable.<br />
<br />
=== Item 13: Minimize the accessibility of classes and members ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 14: In public classes, use accessor methods, not public fields ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 15: Minimize mutability ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 16: Favor composition over inheritance ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 17: Design and document for inheritance or else prohibit it ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 18: Prefer interfaces to abstract classes ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 19: Use interfaces only to define types ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 20: Prefer class hierarchies to tagged classes ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 21: Use function objects to represent strategies ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 22: Favor static member classes over nonstatic ===<br />
see ''"Effective Java"'' for details.<br />
<br />
<br />
<br />
== Enums and Annotations ==<br />
=== Item 30: Use enums instead of int constants ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 31: Use instance fields instead of ordinals ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 32: Use EnumSet instead of bit fields ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 33: Use EnumMap instead of ordinal indexing ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 34: Emulate extensible enums with interfaces ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 35: Prefer annotations to naming patterns ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 36: Consistently use the Override annotation ===<br />
see ''"Effective Java"'' for details.<br />
=== Item 37: Use marker interfaces to define types ===<br />
see ''"Effective Java"'' for details.<br />
<br />
<br />
<br />
== Methods ==<br />
<br />
<br />
=== Methods should be small! ===<br />
The first rule of methods is that they should be small. The second rule of methods is that '''they should be smaller than that!''<br />
<br />
This brings up another question: '''20 lines isn't too large, right?''' Here at code recommenders we would say "No, a method with 20 lines is too large." Methods typically can be broke down to smaller chunks containing of 2,3, or 4 methods each. Sounds strange but the large a method the higher the probability that your method does many different things and thus would violate the next guideline. Thus, if you have a method that is larger than 5 lines carefully look on your code and be sure that this piece of work cannot be divided further into smaller pieces.<br />
<br />
<br />
=== Methods should do one thing and one thing only ===<br />
From Clean Code:<br />
Methods should do one thing. And they should do it well. They should do '''only'' this one thing.<br />
<br />
TODO: provide a code snippet<br />
<br />
=== API Methods should never return null! ===<br />
<br />
<pre><br />
// bad: <br />
public IJavaElement getEnclosing(){<br />
return hasElement? elem: null;<br />
}<br />
<br />
// better:<br />
public Optional<IJavaElement> getEnclosing(){<br />
return Optional.fromNullable(elem);<br />
// or: Optional.absent()<br />
}<br />
<br />
</pre><br />
<br />
Developers tend to assume that methods never return null. This is the source of most NullPointerExceptions. Thus, if a method may return null consider using Optional<T> classes as provided by Google Guava 10.0. Code Recommenders currently has it's own class for this (org.eclipse.recommenders.utils.Option) but this will be replaced soon. This guideline applies for public and protected methods that may be called from external clients. Dealing with null values internally is up to the developer. It's not enforced to apply this guideline to private methods too - it may or may not make sense depending on your case.<br />
<br />
If there are methods such as hasX(), you may consider to throw an exception if getX() would return null. Not sure yet, which approach is more favorable. We are currently one-by-one changing our APIs to use optional classes.<br />
<br />
=== Method modifiers should be given in the following order: ===<br />
<pre><annotations> <access> abstract static final synchronized native strictfp</pre><br />
<br />
Following any <annotations> (like <code>@Overide</code> or <code>@Nullable</code>), which are not ''real'' modifiers, the <access> modifier (if present, one of public, protected or private) must be the first modifier.<br />
<br />
<pre>public static double square(double a); // NOT: static public double square(double a);</pre><br />
<br />
The most important lesson here is to keep the access modifier as the first modifier.<br />
Of the possible modifiers, this is by far the most important, and it must stand out in the method declaration.<br />
For the other modifiers, the order is less important.<br />
Nevertheless, the suggestions of the [http://docs.oracle.com/javase/specs/jls/se7/html/jls-8.html#jls-8.4.3 Java Language Specification] on modifier order should be followed.<br />
<br />
=== Item 38: Check parameters for validity === <br />
see ''Effective Java'' for details.<br />
=== Item 39: Make defensive copies when needed ===<br />
see ''Effective Java'' for details.<br />
=== Item 40: Design method signatures carefully ===<br />
see ''Effective Java'' for details.<br />
=== Item 41: Use overloading judiciously ===<br />
see ''Effective Java'' for details.<br />
=== Item 42: Use varargs judiciously ===<br />
see ''Effective Java'' for details.<br />
=== Item 43: Return empty arrays or collections, not nulls ===<br />
see ''Effective Java'' for details.<br />
=== Item 44: Write doc comments for all exposed API elements ===<br />
see ''Effective Java'' for details.<br />
<br />
<br />
<br />
== Variables ==<br />
<br />
<br />
=== Type conversions must always be done explicitly. Never rely on implicit type conversion. ===<br />
<pre> floatValue = (int) intValue; // NOT: floatValue = intValue; </pre><br />
By this, the programmer indicates that he is aware of the different types involved and that the mix is intentional.<br />
<br />
=== Array specifiers must be attached to the type not the variable. ===<br />
<pre> int[] a = new int[20]; // NOT: int a[] = new int[20]</pre><br />
The arrayness is a feature of the base type, not the variable. It is not known why Sun allows both forms.<br />
<br />
=== Prefer primitive types over their wrapping types ===<br />
<br />
<pre><br />
void m(Boolean b){ // NOT:<br />
if(!b.booleanValue())<br />
// do something;<br />
}<br />
<br />
void m(boolean b){ // BETTER:<br />
if(!b)<br />
// do something;<br />
}<br />
<br />
</pre><br />
<br />
You should use primitive types instead of their wrapping types whenever possible. When using the wrapping type, we assume that ''null'' is a valid '''''and''''' possible value that must be handled. Favor wrapper types if conversion between primitive and object type (int vs. Integer) would otherwise occur very frequently.<br />
<br />
=== Variables should be initialized where they are declared and they should be declared in the smallest scope possible. ===<br />
This ensures that variables are valid at any time. Sometimes it is impossible to initialize a variable to a valid value where it is declared. In these cases it should be left uninitialized rather than initialized to some phony value.<br />
<pre><br />
m(){ // NOT<br />
List<C> res = Collections.emptyList();<br />
if(someExpression){<br />
...<br />
res = new ArrayList();<br />
.... // 10 lines more<br />
}<br />
return res;<br />
}<br />
<br />
Better:<br />
<br />
m(){<br />
if(someExpression){<br />
...<br />
List<C> res = new ArrayList();<br />
.... // 10 lines more<br />
return res;<br />
}<br />
return Collections.emptyList();<br />
}<br />
<br />
</pre><br />
<br />
=== Variables must never have dual meaning. ===<br />
Enhances readability by ensuring all concepts are represented uniquely. Reduce chance of error by side effects.<br />
<br />
=== Class variables should never be declared public. ===<br />
The concept of Java information hiding and encapsulation is violated by public variables. Use private variables and access functions instead. One exception to this rule is when the class is essentially a data structure, with no behavior (equivalent to a C++ struct). In this case it is appropriate to make the class' instance variables public [2].<br />
<br />
=== Arrays should be declared with their brackets next to the type. ===<br />
<pre><br />
double[] vertex; // NOT: double vertex[];<br />
int[] count; // NOT: int count[];<br />
<br />
public static void main(String[] arguments)<br />
<br />
public double[] computeVertex()<br />
</pre><br />
The reason for is twofold. First, the array-ness is a feature of the class, not the variable. Second, when returning an array from a method, it is not possible to have the brackets with other than the type (as shown in the last example).<br />
<br />
=== Variables should be kept alive for as short a time as possible. ===<br />
Keeping the operations on a variable within a small scope, it is easier to control the effects and side effects of the variable.<br />
<br />
== Loops ==<br />
<br />
=== Only loop control statements must be included in the for() construction. ===<br />
<pre><br />
sum = 0; // NOT: for (i = 0, sum = 0; i < 100; i++)<br />
for (i = 0; i < 100; i++) sum += value[i];<br />
sum += value[i];<br />
</pre><br />
Increase maintainability and readability. Make a clear distinction of what controls and what is contained in the loop.<br />
<br />
=== Loop variables should be initialized immediately before the loop. ===<br />
<pre><br />
isDone = false; // NOT: bool isDone = false;<br />
while (!isDone) { // :<br />
: // while (!isDone) {<br />
} // :<br />
// }<br />
</pre><br />
<br />
=== The use of do-while loops can be avoided. ===<br />
do-while loops are less readable than ordinary while loops and for loops since the conditional is at the bottom of the loop. The reader must scan the entire loop in order to understand the scope of the loop.<br />
In addition, do-while loops are not needed. Any do-while loop can easily be rewritten into a while loop or a for loop. Reducing the number of constructs used enhance readability.<br />
<br />
=== The use of break and continue in loops should be avoided. ===<br />
These statements should only be used if they prove to give higher readability than their structured counterparts.<br />
<br />
<br />
== Conditionals ==<br />
<br />
=== Complex conditional expressions must be avoided. Introduce temporary boolean variables or selfexplaining methods instead. ===<br />
<pre><br />
bool isFinished = (elementNo < 0) || (elementNo > maxElement);<br />
bool isRepeatedEntry = elementNo == lastElement;<br />
if (isFinished || isRepeatedEntry) {<br />
:<br />
}<br />
<br />
<br />
// NOT:<br />
if ((elementNo < 0) || (elementNo > maxElement)||<br />
elementNo == lastElement) {<br />
:<br />
}<br />
<br />
<br />
// even better:<br />
if (isFinished(..) || isRepeatedEntry(..)) {<br />
:<br />
}<br />
</pre><br />
<br />
By assigning boolean variables to expressions, the program gets automatic documentation. The construction will be easier to read, debug and maintain. Using methods that reveal the intension of these checks should be preferred over use of temporary variables!<br />
<br />
<br />
=== The nominal case should be put in the if-part and the exception in the else-part of an if statement. ===<br />
<pre><br />
boolean isOk = readFile(fileName);<br />
if (isOk) {<br />
:<br />
}<br />
else {<br />
:<br />
}<br />
</pre><br />
<br />
Makes sure that the exceptions does not obscure the normal path of execution. This is important for both the readability and performance.<br />
<br />
<br />
=== The conditional should be put on a separate line enclosed by curly brackets. ===<br />
<pre><br />
if (isDone)<br />
{ // NOT: if (isDone) doCleanup();<br />
doCleanup();<br />
}<br />
</pre><br />
This is for debugging purposes. When writing on a single line, it is not apparent whether the test is really true or not. Also the usage of curly brackets ensure that no statements accidentally fall out of an if branch: <br />
<br />
<pre><br />
if (isDone) <br />
doCleanup();<br />
unregisterListener(); // unregister will always be called - even if !isDone<br />
</pre><br />
<br />
=== Executable statements in conditionals must be avoided. ===<br />
<pre><br />
InputStream stream = File.open(fileName, "w");<br />
if (stream != null) {<br />
:<br />
}<br />
<br />
// NOT:<br />
if (File.open(fileName, "w") != null)) {<br />
:<br />
}<br />
</pre><br />
<br />
Conditionals with executable statements are simply very difficult to read. This is especially true for programmers new to Java.<br />
<br />
== Miscellaneous ==<br />
<br />
=== The use of magic numbers in the code should be avoided. Numbers other than 0 and 1 can be considered declared as named constants instead. ===<br />
<pre><br />
private static final int TEAM_SIZE = 11;<br />
:<br />
Player[] players = new Player[TEAM_SIZE]; // NOT: Player[] players = new Player[11];<br />
If the number does not have an obvious meaning by itself, the readability is enhanced by introducing a named constant instead.<br />
58. Floating point constants should always be written with decimal point and at least one decimal.<br />
double total = 0.0; // NOT: double total = 0;<br />
double speed = 3.0e8; // NOT: double speed = 3e8;<br />
<br />
double sum;<br />
:<br />
sum = (a + b) * 10.0;<br />
</pre><br />
This emphasize the different nature of integer and floating point numbers. Mathematically the two model completely different and non-compatible concepts.<br />
<br />
Also, as in the last example above, it emphasize the type of the assigned variable (sum) at a point in the code where this might not be evident.<br />
<br />
=== Floating point constants should always be written with a digit before the decimal point. ===<br />
<pre><br />
double total = 0.5; // NOT: double total = .5;<br />
</pre><br />
The number and expression system in Java is borrowed from mathematics and one should adhere to mathematical conventions for syntax wherever possible. Also, 0.5 is a lot more readable than .5; There is no way it can be mixed with the integer 5.<br />
<br />
=== Static variables or methods must always be refered to through the class name and never through an instance variable. ===<br />
<pre> Thread.sleep(1000); // NOT: thread.sleep(1000); </pre><br />
This emphasize that the element references is static and independent of any particular instance. For the same reason the class name should also be included when a variable or method is accessed from within the same class.<br />
=== Default interface implementations can be prefixed by Default. ===<br />
<pre>class DefaultTableCellRenderer implements TableCellRenderer {...}</pre> <br />
It is not uncommon to create a simplistic class implementation of an interface providing default behaviour to the interface methods. The convention of prefixing these classes by Default has been adopted by Sun for the Java library.<br />
<br />
=== Singleton classes should return their sole instance through method ''getInstance''. ===<br />
<pre> <br />
class UnitManager<br />
{<br />
private final static UnitManager instance_ = new UnitManager(); <br />
<br />
private UnitManager() {...} <br />
<br />
public static UnitManager getInstance() // NOT: get() or instance() or unitManager() etc.<br />
{<br />
return instance_;<br />
}<br />
}<br />
</pre> <br />
Common practice in the Java community though not consistently followed by Sun in the JDK. The above layout is the preferred pattern. <br />
<br />
=== Classes that creates instances on behalf of others (factories) can do so through method new[ClassName] ===<br />
<pre>class PointFactory<br />
{<br />
public Point newPoint(...)<br />
{<br />
...<br />
}<br />
}<br />
</pre> <br />
Indicates that the instance is created by new inside the factory method and that the construct is a controlled replacement of new Point(). <br />
<br />
=== Consider static factory methods instead of constructors ===<br />
<br />
Advantages: <br />
<br />
#One advantage of static factory methods is that, unlike constructors, they have names. <br />
#A second advantage of static factory methods is that, unlike constructors, they are not required to create a new object each time they’re invoked. <br />
#A third advantage of static factory methods is that, unlike constructors, they can return an object of any subtype of their return type.<br />
<br />
Disadvantages: <br />
<br />
#The main disadvantage of providing only static factory methods is that classes without public or protected constructors cannot be subclassed. <br />
#A second disadvantage of static factory methods is that they are not readily distinguishable from other static methods.<br />
<br />
Follow a set of conventions when using them: <br />
<br />
*'''valueOf''' - Returns an instance that has, loosely speaking, the same value as its parameters. Such static factories are effectively type-conversion methods. Example: String.valueOf(boolean); <br />
*'''of''' - A concise alternative to valueOf, popularized by EnumSet. <br />
*'''getInstance''' - Returns an instance that is described by the parameters but cannot be said to have the same value. In the case of a singleton, getInstance takes no parameters and returns the sole instance. <br />
*'''newInstance''' - Like getInstance, except that newInstance guarantees that each instance returned is distinct from all others. <br />
*'''getType''' - Like getInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method. <br />
*'''newType''' - Like newInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method. <br />
*'''create[SomeSuffix]''' - Like newType, but may perform some special initializations on the returned objects. Example: Type.createWithDefaultResolver(...);<br />
<br />
=== Public methods may delegate work to private/protected do[MethodName] methods and enclose their invocation with try/catch ===<br />
<pre>public void append(..)<br />
{<br />
try<br />
{<br />
doAppend(..);<br />
} <br />
catch (Exception e)<br />
{<br />
logAppendFailedError(e);<br />
}<br />
}<br />
</pre> <br />
Sometimes the code to execute may throw exceptions which should be catched and not rethrown. Also subclasses may reimplement some behavior of the algorithm. To ensure consistency with the API one may delegate to a do[MethodName]() method and make the public method final. This way the superclass can ensure some consistency independent of actual subclasses executed. <br />
<br />
=== Functions (methods returning an object) should be named after what they return and procedures (void methods) after what they do. ===<br />
<br />
Increase readability. Makes it clear what the unit should do and especially all the things it is not supposed to do. This again makes it easier to keep the code clean of side effects.<br />
<br />
= Layout and Comments =<br />
<br />
== Layout ==<br />
<br />
Code Recommenders provides a code formatter template for Eclipse which must be used by all committers. It's located in the releng project.<br />
<br />
== Comments ==<br />
<br />
Most conventions on comments are enforced by the code formatter template of the code recommenders project. Thus just a few general notes on comments here.<br />
<br />
=== Tricky code should not be commented but rewritten. ===<br />
In general, the use of comments should be minimized by making the code self-documenting by appropriate name choices and an explicit logical structure.<br />
<br />
=== All comments should be written in English. ===<br />
In an international environment English is the preferred language.<br />
<br />
<br />
=== Use // for all non-JavaDoc comments, including multi-line comments. ===<br />
<pre><br />
// Comment spanning<br />
// more than one line.<br />
</pre><br />
Since multilevel Java commenting is not supported, using // comments ensure that it is always possible to comment out entire sections of a file using /* */ for debugging purposes etc.<br />
<br />
<br />
=== The declaration of anonymous collection variables should be followed by a comment stating the common type of the elements of the collection. ===<br />
<pre><br />
private Multimap<String /* simple class name*/, String /* full qualified class names*/> simple2fullyQualifiedClassnames;<br />
</pre><br />
Without the extra comment it can be hard to figure out what the collection consist of, and thereby how to treat the elements of the collection. In methods taking collection variables as input, the common type of the elements should be given in the associated JavaDoc comment.<br />
Whenever possible one should of course qualify the collection with the type to make the comment superflous:<br />
<br />
= List of accepted acronyms =<br />
<br />
;cu <br />
:Abbreviation for ''Compilation Unit''. Although accepted the usage of ''compilationUnit'' should be preferred over ''cu''. <br />
;ast <br />
:Abbreviation for ''Abstract Syntax Tree''. <br />
;jdt <br />
:Abbreviation for ''Java Development Tools'' - also used if IJavaElements are used to make clear the difference to code recommenders or ast constructs with similar names. <br />
;rec <br />
:Abbreviation for ''Recommenders''. Typically used as prefix if objects of similar names are used in the same context. Example: jdtCu vs. recCu<br />
<br />
<br />
= Something left over? =<br />
<br />
Send comments to recommenders-dev@eclipse.org<br />
<br />
[[Category:Recommenders]]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2013_Ideas&diff=329644Google Summer of Code 2013 Ideas2013-02-25T09:34:40Z<p>Sewe.cqse.eu: Added additional resources for some Code Recommenders proposals</p>
<hr />
<div>[https://bugs.eclipse.org/bugs/buglist.cgi?keywords=helpwanted%2C%20&query_format=advanced&keywords_type=allwords&list_id=4495706&bug_status=NEW Existing bugs marked "helpwanted"] are a good source of project ideas.<br />
<br />
= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Workspace-Local Code Search ==<br />
<br />
When writing software, developers frequently find themselves in a situation where they are absolutely certain that someone else must have faced (and solved!) the same problem before, but they just cannot find that piece of code.<br />
This is where the proposed code search feature can help:<br />
Based on the context the developer currently is in (e.g., the current method and the available objects), code search will search through the entire workspace and present pieces of code that match the current context.<br />
For this proposal to work well, the search engine must be (1) fast and (2) present its results in a condensed snippet form, so that the developer can quickly decide which results are worth a closer look.<br />
<br />
A prototype of a code search engine has already been developed as a Master's thesis at Technische Universität Darmstadt.<br />
This project could either build upon that prototype or, taking into account the lessons learned there, start from scratch.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: [https://git.eclipse.org/c/recommenders.incubator/org.eclipse.recommenders.codesearch.git/ Prototype implementation in incubator]<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Social Snippets ==<br />
<br />
With [http://snipmatch.com/ SnipMatch], [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders] already offers one way of searching for and accessing snippets.<br />
However, at the moment, there is no easy way to create new snippets and to share these snippets with other developers.<br />
This goal of this proposal is thus to create a social snippets infrastructure, which allows developers to create and rate snippets.<br />
This infrastructure should then support multiple backends, SnipMatch and its collection of snippets being one of them. <br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Social Extdoc ==<br />
<br />
Currently, the Extdoc view provides extended documentation one classes and methods which has been data-mined from code; there is no way for the user to influence the documentation yet. The goal of this proposal is to enhance Extdoc such that users can create, annotate, and rate contributions to the documentation of classes or methods. <br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Usage Data Collection for Code Completion and Beyond ==<br />
<br />
Do you know how much time code completion saves you per day? No? Well, this proposal should address that by (locally) collecting usage data that can answer this and more sophisticated questions. Moreover, the collected data can then be used to make recommendations on the most effective use of your IDE, e.g., recommending a keyboard shortcut that you don't use (and presumably don't even know about).<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: https://git.eclipse.org/r/#/c/10611/<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders]: Advanced Ranking Mechanisms for Multiple Code Recommenders ==<br />
<br />
Over the years, [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders] has developed and experimented with numerous code completion engines, providing intelligent code completion for method calls, method overrides, call chains and (soon) types, not to mention subwords completion.<br />
In the course of this work, it turned out that the existing ranking mechanisms of JDT leave something to be desired.<br />
The goal of this project is thus to come up with a mechanism that can incorporate a variety of recommenders and produces the ranking the user expects, even if the individual engines disagree on what constitutes the perfect recommendation.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
Additional Resources: https://git.eclipse.org/r/#/c/10611/<br />
<br />
== [http://www.eclipse.org/vjet/ Eclipse VJET]: Improve VJET's support for JQuery UI ==<br />
<br />
[http://www.eclipse.org/vjet/ VJET] Is a JavaScript IDE which provides the best development experience for developers building object based JavaScript. With content assist for classes which are comparable to Java content assist and support for concepts which are exclusive to JavaScript and javascript frameworks. We are looking for help with improving the Jquery support and supporting the JQuery plugin model. [http://www.eclipse.org/vjet/ VJET] has developed a type system for JavaScript which allows for static and dynamic typing. The primary goal is to add to the JQuery meta type library (currently lives here -http://git.eclipse.org/c/vjet/org.eclipse.vjet.typelibs.git/tree/JQueryTL ) with jQuery UI support. The secondary goal is to come up with an extension to support the JQuery plugin model. <br />
<br />
Possible Mentor: Justin Early (contact us on the [https://dev.eclipse.org/mailman/listinfo/vjet-dev mailing list])<br />
<br />
== [http://www.eclipse.org/vjet/ Eclipse VJET]: Help test and improve VJET's NodeJS support ==<br />
<br />
[http://www.eclipse.org/vjet/ VJET] Is a JavaScript IDE which provides the best development experience for developers building object based JavaScript. With content assist for classes which are comparable to Java content assist and support for concepts which are exclusive to JavaScript and javascript frameworks. We are looking for help with testing NodeJS support provided by VJET and supporting the NodeJS user defined modules. [http://www.eclipse.org/vjet/ VJET] has developed a type system for JavaScript which allows for static and dynamic typing. The primary goal is to test the support for NodeJS that VJET supports. The secondary goal is to come up with an extension to VJET to support the NodeJs module system.<br />
<br />
Possible Mentor: Justin Early (contact us on the [https://dev.eclipse.org/mailman/listinfo/vjet-dev mailing list])<br />
<br />
== [http://www.eclipse.org/platform/overview.php Eclipse Platform]: Create filterable Console View ==<br />
<br />
The console view is a very important tool for developers, the analyse stacktraces here, look at System.out messages, etc. It should allow to have a filter to filter for example for a package name. It should be possible to save defined filters similar to the Android LogCat view based on fields. Optional this work could also start the migration of this view to Eclipse 4.<br />
<br />
Possible Mentor: Lars Vogel and Markus Alexander Kuppe<br />
<br />
== [http://www.eclipse.org/platform/overview.php Eclipse Platform]: Create Eclipse 4 (e4) based Progress View (see [https://bugs.eclipse.org/401655 bug #401655]) ==<br />
<br />
The progress view provides the main status overview for the Jobs API and is used not only in the Eclipse IDE itself but also by many RCP apps. With the move to e4, the progress view has not been adapted to the new API though and thus is currently not useable in plain e4 apps. If time permits other legacy views (e.g. the console view) could be ported to Eclipse 4 too.<br />
<br />
Possible Mentor: Lars Vogel and Markus Alexander Kuppe<br />
<br />
== [http://www.eclipse.org/orion/ Eclipse Orion]: Create a app store or portal for Orion plugins ==<br />
<br />
At the moment, the Orion list of PlugIns is housed at a team member's [http://mamacdon.github.com GitHub account] and it's desirable to create a more formal approach to how and where Orion Plugins are managed. This could take into account teams or products which want to host their own (possibly internal) list of approved plugins, for example. This task may also include dynamic lists of plugin providers for an Orion installation. <br />
<br />
Possible Mentor: Ken Walker and Mark Macdonald (contact us on the [https://dev.eclipse.org/mailman/listinfo/orion-dev mailing list])<br />
<br />
== [http://www.eclipse.org/platform/ Eclipse Platform]: Implementing generic in JFace viewers ==<br />
<br />
JFace viewers are heavily used in Eclipse and developers could benefit from Generic support to avoid unnecessary casting. https://bugs.eclipse.org/bugs/show_bug.cgi?id=395213 suggested that we move the JFace viewers to generics. <br />
<br />
<br />
Possible Mentor: Lars Vogel and Markus Alexander Kuppe<br />
<br />
== [http://www.eclipse.org/nebula/ Eclipse Nebula]: Provide Nebula Integration for WindowBuilder ==<br />
[[Image:gsoc2013wb.png|thumb||200px]]<br />
The Nebula and WindowBuilder projects are seeking a mechanism to enable inclusion of (Nebula) widgets into the WindowBuilder pallete. Nebula users would then be able to effortless use the widgets by using the provided drag and drop mechanism in WindowBuilder. We are looking for a general abstraction that enables us to easily incorporate widgets into the WindowBuilder pallete and let WindowBuilder consume specific widget parameters and hints to optimize the user experience. Tooling and extension points are already available in WindowBuilder and we are looking for ways to leverage this. The inclusion should not only work for Nebula widgets but for all widgets. The solution could include some sort of discovery mechanism to automatically detect and include widgets.<br />
<br />
[https://developers.google.com/java-dev-tools/wbpro/NewComponentsTutorial.pdf New Components Manual]<br />
<br />
[https://developers.google.com/java-dev-tools/wbpro/DesignerCustomizationAPI.pdf Designer Customization]<br />
<br />
<br />
We are looking for creative visually oriented students who love to push pixels. <br />
<br />
Possible Mentor: Wim Jongman</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2013_Ideas&diff=328848Google Summer of Code 2013 Ideas2013-02-14T12:48:02Z<p>Sewe.cqse.eu: Proposals for Eclipse Code Recommenders</p>
<hr />
<div>= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Core Recommenders]: Workspace-Local Code Search ==<br />
<br />
When writing software, developers frequently find themselves in a situation where they are absolutely certain that someone else must have faced (and solved!) the same problem before, but they just cannot find that piece of code.<br />
This is where the proposed code search feature can help:<br />
Based on the context the developer currently is in (e.g., the current method and the available objects), code search will search through the entire workspace and present pieces of code that match the current context.<br />
For this proposal to work well, the search engine must be (1) fast and (2) present its results in a condensed snippet form, so that the developer can quickly decide which results are worth a closer look.<br />
<br />
A prototype of a code search engine has already been developed as a Master's thesis at Technische Universität Darmstadt.<br />
This project could either build upon that prototype or, taking into account the lessons learned there, start from scratch.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Core Recommenders]: Social Snippets ==<br />
<br />
With [http://snipmatch.com/ SnipMatch], [http://www.eclipse.org/recommenders/ Eclipse Code Recommenders] already offers one way of searching for and accessing snippets.<br />
However, at the moment, there is no easy way to create new snippets and to share these snippets with other developers.<br />
This goal of this proposal is thus to create a social snippets infrastructure, which allows developers to create and rate snippets.<br />
This infrastructure should then support multiple backends, SnipMatch and its collection of snippets being one of them. <br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Core Recommenders]: Social Extdoc ==<br />
<br />
Currently, the Extdoc view provides extended documentation one classes and methods which has been data-mined from code; there is no way for the user to influence the documentation yet. The goal of this proposal is to enhance Extdoc such that users can create, annotate, and rate contributions to the documentation of classes or methods. <br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Core Recommenders]: Usage Data Collection for Code Completion and Beyond ==<br />
<br />
Do you know how much time code completion saves you per day? No? Well, this proposal should address that by collecting usage data that can answer this and more sophisticated questions. Moreover, the collected data can then be used to make recommendations on the most effective use of your IDE, e.g., recommending a keyboard shortcut that you don't use (and presumably don't even know about).<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Core Recommenders]: Advanced Ranking Mechanisms for Multiple Code Recommenders ==<br />
<br />
Over the years, [http://www.eclipse.org/recommenders/ Eclipse Core Recommenders] has developed and experimented with numerous code completion engines, providing intelligent code completion for method calls, method overrides, call chains and (soon) types, not to mention subwords completion.<br />
In the course of this work, it turned out that the existing ranking mechanisms of JDT leave something to be desired.<br />
The goal of this project is thus to come up with a mechanism that can incorporate a variety of recommenders and produces the ranking the user expects, even if the individual engines disagree on what constitutes the perfect recommendation.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code_2013_Ideas&diff=328844Google Summer of Code 2013 Ideas2013-02-14T12:27:36Z<p>Sewe.cqse.eu: Workspace-local code search</p>
<hr />
<div>= Rules =<br />
<br />
*Be creative <br />
*Be specific: what do you want to be implemented <br />
*If you are willing to mentor those ideas, add your name and email to the idea. <br />
*GSoC project ideas should align with an existing Eclipse project <br />
*If you're an interested student, add your name and email next to the idea. '''It is ok to have several students interested in one idea.''' <br />
*'''Aspiring students''' and mentors '''need to register and submit their proposals on the [http://socghop.appspot.com/ SoC app]'''<br />
<br />
== Mentors info ==<br />
<br />
If you were a mentor last year then you are automatically in the list this year (the GSoC site may require that you re-register, but we think of you as "in"). <br />
<br />
Note that we only accept as mentors people who are known to us. This includes Eclipse committers. If you would like to be a mentor, please either introduce yourself to the group using the soc-dev mailing list, or send a note to [mailto:emo@eclipse.org EMO]. <br />
<br />
== Ideas submission ==<br />
<br />
Idea proposal should contain the following information: <br />
<br />
*project title, like "WTP - Improve auto-complete in xml editor" <br />
*description with links to bug reports, project wiki pages, etc <br />
*Reporter: who submitted idea (optional e-mail) <br />
*Possible Mentors: who would like to mentor the students <br />
*More info: other links or e-mail <br />
*Eclipse Project: link to main eclipse project that improvement is targeting <br />
*Potential students: who is interested (with optional e-mail). This one completely informal, to actually be interested you need to submit the proposal. Contact the idea owner or possible mentor to get some details before submitting it.<br />
<br />
= Ideas =<br />
<br />
These are some ideas. Students feel free to base your GSoC proposals on these ideas (note that you are more likely to find a mentor for an idea that has been proposed by a mentor). Some of these ideas can be factored into multiple projects; a GSoC project proposal can work on parts of these ideas (i.e. you don't necessarily have to do it all). <br />
<br />
There are other sources of ideas. There are numerous bugs in the Eclipse Bugzilla issue tracking system marked as "[https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=NEW&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Cvotes&field0-0-0=classification&field0-1-0=short_desc&field0-1-1=short_desc&keywords=helpwanted&keywords_type=allwords&negate0=1&query_format=advanced&type0-0-0=equals&type0-1-0=allwords&type0-1-1=allwords&value0-0-0=Mylyn&value0-1-0=%5Bconnector%5D&value0-1-1=%5Bbridge%5D helpwanted]" that may give you ideas.<br />
<br />
== [http://www.eclipse.org/recommenders/ Eclipse Core Recommenders]: Workspace-Local Code Search ==<br />
<br />
When writing software, developers frequently find themselves in a situation, where they are absolutely certain that someone else must have faced (and solved!) the same problem before, but they just cannot find that piece of code.<br />
This is where the proposed code search feature can help:<br />
Based on the context the developer currently is in (e.g., the current method and the available objects), code search will search through the entire workspace and present pieces of code that match the current context.<br />
For this proposal to work well, the search engine must be (1) fast and (2) present its results in a condensed snippet form, so that the developer can quickly decide which results are worth a closer look.<br />
<br />
A prototype of a code search engine has already been developed as a Master's thesis at Technische Universität Darmstadt.<br />
This project could either build upon that prototype or, taking into account the lessons learned there, start from scratch.<br />
<br />
Possible Mentors: Marcel Bruch, Andreas Sewe (contact us on the [https://dev.eclipse.org/mailman/listinfo/recommenders-dev mailing list])<br />
<br />
== Idea #2 ==</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Google_Summer_of_Code&diff=328842Google Summer of Code2013-02-14T12:19:40Z<p>Sewe.cqse.eu: Changed current year to 2013</p>
<hr />
<div>[[Image:Soc20070506.png|frame|right|Like this image, think you can do better, vote for it here?]]<br />
<br />
The Eclipse Foundation participates in Google's Summer of Code.<br />
Thank you for your interest in Eclipse. Eclipse is a great place to spend a summer learning, coding, participating and contributing. We are an exciting open source project with a vibrant community, and we look forward to your application and your project ideas.<br />
<br />
A good way to meet those involved with the program is to participate in the mailing list, or visit the #eclipse-soc and #eclipse IRC channels on Freenode.<br />
<br />
The program is administered by Ahti Kitsik and Wayne Beaton. It's best if you use the public communication channel whenever possible; however, if you need to communicate in private, please feel free to send [mailto:wayne@eclipse.org Wayne] a note.<br />
<br />
== Current Year ==<br />
<br />
<br />
Google has announced the Google Summer of Code program. <br />
<br />
You can find our project proposals at the [[Google Summer of Code 2013 Ideas|GSoC 2013 Ideas]] page.<br />
<br />
== Ongoing Projects ==<br />
Every project appreciates input. We recommend that you take a look around Eclipse to see if there is anything you find particularly interesting. If you do find a project that you're interested in, take a look at their bugs to see if there are any problems that you feel you can solve.<br />
<br />
If you're looking for a project that is particularly student-friendly, consider the following:<br />
<br />
*[[Eclipse IDE for Education]<br />
*Eclipse Communication Framework (ECF) Project<br />
*Gyrex - Equinox on Servers <br />
<br />
== Past Years ==<br />
*[[Google Summer of Code 2012]] <br />
*[[Google Summer of Code 2012 Ideas]]<br />
*[[Google Summer of Code 2011]] <br />
*[[Google Summer of Code 2011 Ideas]]<br />
*[[Google Summer of Code 2010]] <br />
*[[Google Summer of Code 2010 Ideas]]<br />
*[[Google Summer of Code 2009]] <br />
*[[Google Summer of Code 2009 Ideas]] <br />
*[[Google Summer of Code 2008]] <br />
*[[Google Summer of Code 2008 Ideas]] <br />
*[[Google Summer of Code 2008 improvements]] <br />
*[[Google Summer of Code 2007]] <br />
*[[Google Summer of Code 2007 Ideas]] <br />
*[[Google Summer of Code 2006]]<br />
<br />
== Related Links==<br />
*[http://www.doxapest.co.id/index.php/pest-control-dan-anti-rayap Anti Rayap] & [http://www.doxapest.co.id/index.php/pest-control-dan-anti-rayap Pest Control]<br />
*[http://littletods.com/en/content/4-perlengkapan-bayi Perlengkapan Bayi]<br />
*[http://www.pbtaxand.com/our-services/tax-advisory-services Konsultan Pajak]<br />
*[http://saranasukses.com/outsourcing-indonesia.html Outsourcing Indonesia]<br />
*[http://www.goldenfibreglass.com/product-tangki-fiberglass.php Tangki Fiberglass]<br />
*[http://www.goldenfibreglass.com/product-atap-fiberglass.php Atap Fiberglass]</div>Sewe.cqse.euhttps://wiki.eclipse.org/index.php?title=Recommenders/Release/Checklist&diff=326628Recommenders/Release/Checklist2013-01-16T08:58:30Z<p>Sewe.cqse.eu: Added some step-by-step descriptions</p>
<hr />
<div>This is a action list that should be checked before a new drop is promoted. <br />
<br />
#Walk trough all UI test cases and check applicability (especially for postponed scenarios)? Do that a few days before drop date. <br />
#Are all UI test suites running? <br />
#Do all manual test scenarios still work? <br />
#Are all versions in pom.xml, manifest.mf, and feature.xml files updated? <br />
#*Run '''mvn org.eclipse.tycho:tycho-versions-plugin:set-version -DnewVersion=&lt;version&gt;''' from the project parent (as described [http://community.jboss.org/en/tools/blog/2011/09/17/coping-with-versions-in-large-multi-module-osgi-projects here]) <br />
#*Verify correctness by '''grep'''ing for the old version <br />
#Added News and Noteworthy/0.x to org.eclipse.recommenders.doc.user plug-in generation task? <br />
#Added all new plug-in dependencies to feature? <br />
#Are plug-ins available from dev update channel? <br />
#Does a test install in a clean Eclipse installation work? <br />
#*Perform a fresh install <br />
#*Add the locally-built dev update site (file://''GIT_ROOT''/dist/org.eclipse.recommenders.repository.rcp.dev.''ECLIPSE''/target/repository) in the '''Help/Install New Software...''' dialog <br />
#*Perform an update <br />
#Website updated? <br />
#Marketplace updated? <br />
#Announcements ready? <br />
#Created a post in the forum?<br />
<br />
[[Category:Recommenders|Release]]</div>Sewe.cqse.eu