https://wiki.eclipse.org/api.php?action=feedcontributions&user=Eclipse.kovatsch.net&feedformat=atomEclipsepedia - User contributions [en]2024-03-29T11:33:42ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=IoT/Face-to-Face-October23-2017&diff=420141IoT/Face-to-Face-October23-20172017-10-24T09:36:35Z<p>Eclipse.kovatsch.net: /* New Project Introduction */</p>
<hr />
<div>== IoT Working Group Meeting ==<br />
A meeting of the Eclipse IoT community and IoT enthusiasts. Join us this day long session to learn about IoT and share your thoughts on the requirements for building an Internet of Things based on open source and open standards.<br />
<br />
=== Event Details ===<br />
*'''When:''' October 23, 2017, 9:00am - 16:30<br />
*'''Where:''' EclipseCon Europe, Ludwigsburg, Germany<br />
<br />
*This WG meeting is co-located with [https://www.eclipsecon.org/europe2017/unconference Europe Unconference] in Ludwigsburg, Germany. Attendees will need to register for the Unconference.<br />
<br />
<br />
*Session coordinators: Ian Skerrett, Benjamin Cabé<br />
<br />
=== Agenda ===<br />
==== Project Updates / New Project Introduction ====<br />
<br />
Each project will spend 10 minutes updating on their current status. The update should include:<br />
<br />
*Project Overview: Short (1 slide) reminder about your project functionality. This is for people who are new to the project.<br />
* Project stats: tell us how well your project is doing. Number of download, number of contributors, number of bugs opened, number of mailing list subscribers, etc.<br />
* Project plan: when is the next release and what are the key features.<br />
* Key Challenges: What challenges/issues are you having? <br />
* Collaboration Opportunities: Where do you see potential for collaboration with other Eclipse IoT projects or other communities.<br />
<br />
<br />
===== Projects =====<br />
* Eclipse SmartHome, Kai Kreuzer, Deutsche Telekom<br />
* Eclipse hawkBit, Michael Hirsch, Bosch SI<br />
* Eclipse Milo, Jens Reimann<br />
* Eclipse Hono, Kai Hudalla, Bosch SI<br />
* Eclipse 4diac, Monika Wenger, fortiss<br />
* Eclipse Unide, Benjamin Cabé (on behalf of Axel Meinhardt, Bosch SI)<br />
* Eclipse Californium, Achim Kraus, Bosch SI<br />
* Eclipse Kura, Cristiano de Alti, Eurotech<br />
* Eclipse Kapua, Stefano Morson, Eurotech<br />
<br />
** <add project><br />
<br />
===== New Project Introduction =====<br />
* Eclipse Ditto, Thomas Jäckle, Bosch SI<br />
* Eclipse Thingweb, Matthias Kovatsch, Siemens AG<br />
** [https://projects.eclipse.org/proposals/thingweb Proposal]<br />
** [[Media:2017_Thingweb-Proposal.pdf|Slides]]<br />
* Eclipse Cyclone, Hans van't Hag, Prismtech<br />
<br />
==== Testbeds ====<br />
* Asset Tracking Testbed<br />
* Industry 4.0 Testbed - Axel Meinhardt & Frank Patz-Brockmann<br />
<br />
==== New Member Introduction ====<br />
<br />
* SAP, Michael Picht<br />
* InfluxData, David Simmons<br />
<br />
==== Invited Speakers ====<br />
<br />
* Intro to Kubernetes, Chris Aniszczyk, CNCF Foundation<br />
* Blockchain and IoT: Introduction to IOTA, Dominik Schiener, IOTA Foundation<br />
<br />
==== Collaboration Topics / Open Whiteboard ====<br />
* oneM2M collaboration opportunity with Eclipse IoT WG open source projects (Jason Yin, Huawei)<br />
* Community Building, Roxanne Joncas and Ian Skerrett<br />
* Fostering inter-project collaboration, Jens Reimann and Kai Hudalla</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=File:2017_Thingweb-Proposal.pdf&diff=420140File:2017 Thingweb-Proposal.pdf2017-10-24T09:34:24Z<p>Eclipse.kovatsch.net: Slides shown at the EclipseCon Europe 2017 Unconference</p>
<hr />
<div>Slides shown at the EclipseCon Europe 2017 Unconference</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Release_Process&diff=405024Californium/Release Process2016-05-09T11:51:10Z<p>Eclipse.kovatsch.net: /* How-to release Californium */</p>
<hr />
<div><br />
= How-to release Californium =<br />
<br />
Californium consists of the following components<br />
# Californium (parent)<br />
## Element Connector<br />
## Scandium<br />
## Californium core<br />
# Tools<br />
# Actinium<br />
<br />
Some of the components have dependencies on other components. Thus, in order to successfully build all of the components they need to be built in the order given above.<br />
<br />
=== Repositories ===<br />
<br />
The source code for Californium's components is managed in separate GitHub repositories as follows:<br />
{| class="wikitable"<br />
!Component<br />
!Standard URI<br />
!SSH URI (to be used on HIPP)<br />
|-<br />
|Californium (Core + Scandium + element-connector)<br />
|https://github.com/eclipse/californium.git<br />
|ssh://deploy_github_eclipse_californium/eclipse/californium.git<br />
|-<br />
|Tools<br />
|https://github.com/eclipse/californium.tools.git<br />
|ssh://deploy_github_eclipse_californium.tools/eclipse/californium.tools.git<br />
|-<br />
|Actinium<br />
|https://github.com/eclipse/californium.actinium.git<br />
|ssh://deploy_github_eclipse_californium.actinium/eclipse/californium.actinium.git<br />
|-<br />
|}<br />
<br />
=== Release Process ===<br />
<br />
The repositories mentioned above can be built either from the command line or using a separate Hudson build job for each repository.<br />
The following table contains the steps required to build and release a repository and the corresponding actions from the command line or the respective Hudson build job configuration required to make it happen.<br />
<br />
The ''Standard URIs'' from the table above are supposed to be used from the command line whereas the ''SSH URIs'' need to be used in build jobs on our HIPP instance in order to be able to push tags created during the build back to GitHub using deploy keys associated with the ''SSH URIs''.<br />
<br />
<br />
{| class="wikitable"<br />
!Step<br />
!Command Line<br />
!Hudson Build Job Configuration<br />
|-<br />
|Create build job<br />
| not necessary<br />
|<br />
# Create a new build job using the '''Build a free-style software job''' option<br />
# Check the '''This build is parameterized''' checkbox and add the following parameters:<br />
## '''RELEASE_VERSION''' - no '''Default Value'''<br />
## '''NEXT_VERSION''' - no '''Default Value'''<br />
# Under '''Advanced Job Options''' click the '''Advanced...''' button<br />
# Check the '''Clean workspace before build''' checkbox<br />
|-<br />
|Checkout repository<br />
|Use the ''Standard URI'' from the table above to clone the repository<br/><code>git clone https://github.com/eclipse/californium.git</code><br />
|Fill out '''Source Code Management''' section of build configuration like this (make sure to use the ''SSH URI'' from the table above):<br />
# '''Url of repository''': ''ssh://deploy_github_eclipse_californium/eclipse/californium.git''<br />
# '''Branch specifier''': ''master''<br />
# click '''Advanced...''' button in the '''Branches to build''' section to expand more options<br />
# '''Checkout/merge to local branch''': ''master''<br />
# check '''Skip internal tag'''<br />
# check '''Use Command line git to clone'''<br />
|-<br />
|Set release version (probably the same as the current one but without the ''-SNAPSHOT'' suffix)<br />
|<br />
For ''Californium (parent)'':<br/><br />
<code>mvn versions:set -DnewVersion=X.Y.Z</code><br />
<br />
For all other components (because the artifact version is implicitly set by the parent pom):<br/><br />
<code>mvn versions:update-parent versions:update-child-modules -DparentVersion=X.Y.Z</code><br />
|<br />
# In the '''Build''' section click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# For building ''Californium (parent)'' set<br />
## '''Goals''': ''versions:set''<br />
## '''Properties''': ''newVersion=${RELEASE_VERSION}''<br />
# For building all other components set<br />
## '''Goals''': ''versions:update-parent versions:update-child-modules''<br />
## '''Properties''': ''parentVersion=${RELEASE_VERSION}''<br />
|-<br />
|Build & test the code<br />
|<br />
<code><br />
mvn clean install -DsnapshotDependencyAllowed=false<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''clean install''<br />
## '''Properties''': ''maven.test.failure.ignore=false'' ''snapshotDependencyAllowed=false'' ''enableEclipseJarSigner=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Commit pom.xml containing the release version and create a corresponding tag for it<br />
|<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git tag "X.Y.Z"<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Execute shell'''<br />
# In the newly created build step add the following script <br/><br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release ${RELEASE_VERSION}"<br />
<br />
git tag ${RELEASE_VERSION}<br />
</code><br />
|-<br />
|Publish artifacts to Eclipse release repository<br />
|<br />
<code>mvn deploy -DskipStaging=true</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''mvn:deploy''<br />
## '''Properties''': ''skipStaging=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Publish artifacts to Maven Central's staging repo<br />
|<br />
<code>mvn deploy</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''mvn:deploy''<br />
## '''Properties''': ''createGPGSignature=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Set next development version<br />
|<br />
For building ''Californium (parent)'':<br />
<br />
<code>mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT</code><br />
<br />
For building all other components:<br />
<br />
<code>mvn versions:update-parent versions:update-child-modules -DparentVersion=X.Y.Z-SNAPSHOT -DallowSnapshots=true</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# For building ''Californium (parent)'' set<br />
## '''Goals''': ''versions:set''<br />
## '''Properties''': ''newVersion=${NEXT_VERSION}''<br />
# For building all other components set<br />
## '''Goals''': ''versions:update-parent versions:update-child-modules''<br />
## '''Properties''': ''parentVersion=${NEXT_VERSION}'' ''allowSnapshots=true''<br />
|-<br />
|Push changes to SCM<br />
|<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git push && git push --tags<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Execute shell'''<br />
# In the newly created build step add the following script <br/><br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release ${RELEASE_VERSION}"<br />
<br />
git push ssh://deploy_github_eclipse_californium/eclipse/californium.git && git push --tags ssh://deploy_github_eclipse_californium/eclipse/californium.git<br />
</code><br />
|-<br />
|}<br />
<br />
= Reference Instructions =<br />
<br />
1st get a copy of '''all''' the californium repository:<br />
<br />
<code><br />
git clone git@github.com:eclipse/californium.git<br />
<br />
git clone git@github.com:eclipse/californium.tools.git<br />
<br />
git clone git@github.com:eclipse/californium.actinium.git<br />
</code><br />
<br />
You need to process the repository in the correct order:<br />
<br />
<code><br />
californium<br />
<br />
tools<br />
<br />
actinium<br />
</code><br />
<br />
In each repository:<br />
* set the final version (probably the same as the current one but without "SNAPSHOT")<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z<br />
</code><br />
<br />
* build & sign the artifacts (you need a gpg key; see below)<br />
<br />
<code><br />
mvn clean install -Prelease<br />
</code><br />
<br />
* looks in ./target/ does the artifacts looks nice?<br />
* check if there is no *-SNAPSHOT in the dependency: <br />
<br />
<code><br />
mvn dependency:tree<br />
</code><br />
<br />
* then commit the pom.xml, and tag the release:<br />
<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git tag "X.Y.Z"<br />
</code><br />
<br />
* publish the artifacts on maven central<br />
<br />
<code><br />
mvn deploy -Prelease<br />
</code><br />
<br />
* prepare for the next cycle:<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT<br />
<br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
</code><br />
<br />
* push the commits<br />
<br />
<code><br />
git push && git push --tags<br />
</code><br />
<br />
Now connect on the [https://oss.sonatype.org/#stagingRepositories Sonatype OSS Nexus] and close the staging repository. If it's fine you will be able to "release" the repository and the artifact will show up in maven central in a few hours.<br />
Next step is to edit the [https://projects.eclipse.org/projects/technology.californium/governance Eclipse project metadata] and announce it on the mailing list.<br />
<br />
----<br />
<br />
= GPG Help =<br />
<br />
Under CygWin the following error might occur:<br />
<code><br />
gpg: cannot open tty `no tty': No such file or directory<br />
</code><br />
<br />
This can be fixed by configuring gpg through an active profile in <code>.m2\settings.xml</code> where also the Sonatype password is stored:<br />
<br />
<pre><br />
<settings><br />
<servers><br />
<server><br />
<id>ossrh</id><br />
<username>[username]</username><br />
<password>[password]</password><br />
</server><br />
</servers><br />
<profiles><br />
<profile><br />
<id>gpg</id><br />
<properties><br />
<gpg.executable>gpg</gpg.executable><br />
<gpg.passphrase>[password]</gpg.passphrase><br />
</properties><br />
</profile><br />
</profiles><br />
<activeProfiles><br />
<activeProfile>gpg</activeProfile><br />
</activeProfiles><br />
</settings><br />
</pre></div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Release_Process&diff=405023Californium/Release Process2016-05-09T11:49:41Z<p>Eclipse.kovatsch.net: /* Reference Instructions */</p>
<hr />
<div><br />
= How-to release Californium =<br />
<br />
Californium consists of the following components<br />
# Californium (parent)<br />
# Element Connector<br />
# Scandium<br />
# Californium (core)<br />
# Tools<br />
# Actinium<br />
<br />
Some of the components have dependencies on other components. Thus, in order to successfully build all of the components they need to be built in the order given above.<br />
<br />
=== Repositories ===<br />
<br />
The source code for Californium's components is managed in separate GitHub repositories as follows:<br />
{| class="wikitable"<br />
!Component<br />
!Standard URI<br />
!SSH URI (to be used on HIPP)<br />
|-<br />
|Californium (Core + Scandium + element-connector)<br />
|https://github.com/eclipse/californium.git<br />
|ssh://deploy_github_eclipse_californium/eclipse/californium.git<br />
|-<br />
|Tools<br />
|https://github.com/eclipse/californium.tools.git<br />
|ssh://deploy_github_eclipse_californium.tools/eclipse/californium.tools.git<br />
|-<br />
|Actinium<br />
|https://github.com/eclipse/californium.actinium.git<br />
|ssh://deploy_github_eclipse_californium.actinium/eclipse/californium.actinium.git<br />
|-<br />
|}<br />
<br />
=== Release Process ===<br />
<br />
The repositories mentioned above can be built either from the command line or using a separate Hudson build job for each repository.<br />
The following table contains the steps required to build and release a repository and the corresponding actions from the command line or the respective Hudson build job configuration required to make it happen.<br />
<br />
The ''Standard URIs'' from the table above are supposed to be used from the command line whereas the ''SSH URIs'' need to be used in build jobs on our HIPP instance in order to be able to push tags created during the build back to GitHub using deploy keys associated with the ''SSH URIs''.<br />
<br />
<br />
{| class="wikitable"<br />
!Step<br />
!Command Line<br />
!Hudson Build Job Configuration<br />
|-<br />
|Create build job<br />
| not necessary<br />
|<br />
# Create a new build job using the '''Build a free-style software job''' option<br />
# Check the '''This build is parameterized''' checkbox and add the following parameters:<br />
## '''RELEASE_VERSION''' - no '''Default Value'''<br />
## '''NEXT_VERSION''' - no '''Default Value'''<br />
# Under '''Advanced Job Options''' click the '''Advanced...''' button<br />
# Check the '''Clean workspace before build''' checkbox<br />
|-<br />
|Checkout repository<br />
|Use the ''Standard URI'' from the table above to clone the repository<br/><code>git clone https://github.com/eclipse/californium.git</code><br />
|Fill out '''Source Code Management''' section of build configuration like this (make sure to use the ''SSH URI'' from the table above):<br />
# '''Url of repository''': ''ssh://deploy_github_eclipse_californium/eclipse/californium.git''<br />
# '''Branch specifier''': ''master''<br />
# click '''Advanced...''' button in the '''Branches to build''' section to expand more options<br />
# '''Checkout/merge to local branch''': ''master''<br />
# check '''Skip internal tag'''<br />
# check '''Use Command line git to clone'''<br />
|-<br />
|Set release version (probably the same as the current one but without the ''-SNAPSHOT'' suffix)<br />
|<br />
For ''Californium (parent)'':<br/><br />
<code>mvn versions:set -DnewVersion=X.Y.Z</code><br />
<br />
For all other components (because the artifact version is implicitly set by the parent pom):<br/><br />
<code>mvn versions:update-parent versions:update-child-modules -DparentVersion=X.Y.Z</code><br />
|<br />
# In the '''Build''' section click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# For building ''Californium (parent)'' set<br />
## '''Goals''': ''versions:set''<br />
## '''Properties''': ''newVersion=${RELEASE_VERSION}''<br />
# For building all other components set<br />
## '''Goals''': ''versions:update-parent versions:update-child-modules''<br />
## '''Properties''': ''parentVersion=${RELEASE_VERSION}''<br />
|-<br />
|Build & test the code<br />
|<br />
<code><br />
mvn clean install -DsnapshotDependencyAllowed=false<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''clean install''<br />
## '''Properties''': ''maven.test.failure.ignore=false'' ''snapshotDependencyAllowed=false'' ''enableEclipseJarSigner=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Commit pom.xml containing the release version and create a corresponding tag for it<br />
|<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git tag "X.Y.Z"<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Execute shell'''<br />
# In the newly created build step add the following script <br/><br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release ${RELEASE_VERSION}"<br />
<br />
git tag ${RELEASE_VERSION}<br />
</code><br />
|-<br />
|Publish artifacts to Eclipse release repository<br />
|<br />
<code>mvn deploy -DskipStaging=true</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''mvn:deploy''<br />
## '''Properties''': ''skipStaging=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Publish artifacts to Maven Central's staging repo<br />
|<br />
<code>mvn deploy</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''mvn:deploy''<br />
## '''Properties''': ''createGPGSignature=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Set next development version<br />
|<br />
For building ''Californium (parent)'':<br />
<br />
<code>mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT</code><br />
<br />
For building all other components:<br />
<br />
<code>mvn versions:update-parent versions:update-child-modules -DparentVersion=X.Y.Z-SNAPSHOT -DallowSnapshots=true</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# For building ''Californium (parent)'' set<br />
## '''Goals''': ''versions:set''<br />
## '''Properties''': ''newVersion=${NEXT_VERSION}''<br />
# For building all other components set<br />
## '''Goals''': ''versions:update-parent versions:update-child-modules''<br />
## '''Properties''': ''parentVersion=${NEXT_VERSION}'' ''allowSnapshots=true''<br />
|-<br />
|Push changes to SCM<br />
|<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git push && git push --tags<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Execute shell'''<br />
# In the newly created build step add the following script <br/><br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release ${RELEASE_VERSION}"<br />
<br />
git push ssh://deploy_github_eclipse_californium/eclipse/californium.git && git push --tags ssh://deploy_github_eclipse_californium/eclipse/californium.git<br />
</code><br />
|-<br />
|}<br />
<br />
= Reference Instructions =<br />
<br />
1st get a copy of '''all''' the californium repository:<br />
<br />
<code><br />
git clone git@github.com:eclipse/californium.git<br />
<br />
git clone git@github.com:eclipse/californium.tools.git<br />
<br />
git clone git@github.com:eclipse/californium.actinium.git<br />
</code><br />
<br />
You need to process the repository in the correct order:<br />
<br />
<code><br />
californium<br />
<br />
tools<br />
<br />
actinium<br />
</code><br />
<br />
In each repository:<br />
* set the final version (probably the same as the current one but without "SNAPSHOT")<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z<br />
</code><br />
<br />
* build & sign the artifacts (you need a gpg key; see below)<br />
<br />
<code><br />
mvn clean install -Prelease<br />
</code><br />
<br />
* looks in ./target/ does the artifacts looks nice?<br />
* check if there is no *-SNAPSHOT in the dependency: <br />
<br />
<code><br />
mvn dependency:tree<br />
</code><br />
<br />
* then commit the pom.xml, and tag the release:<br />
<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git tag "X.Y.Z"<br />
</code><br />
<br />
* publish the artifacts on maven central<br />
<br />
<code><br />
mvn deploy -Prelease<br />
</code><br />
<br />
* prepare for the next cycle:<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT<br />
<br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
</code><br />
<br />
* push the commits<br />
<br />
<code><br />
git push && git push --tags<br />
</code><br />
<br />
Now connect on the [https://oss.sonatype.org/#stagingRepositories Sonatype OSS Nexus] and close the staging repository. If it's fine you will be able to "release" the repository and the artifact will show up in maven central in a few hours.<br />
Next step is to edit the [https://projects.eclipse.org/projects/technology.californium/governance Eclipse project metadata] and announce it on the mailing list.<br />
<br />
----<br />
<br />
= GPG Help =<br />
<br />
Under CygWin the following error might occur:<br />
<code><br />
gpg: cannot open tty `no tty': No such file or directory<br />
</code><br />
<br />
This can be fixed by configuring gpg through an active profile in <code>.m2\settings.xml</code> where also the Sonatype password is stored:<br />
<br />
<pre><br />
<settings><br />
<servers><br />
<server><br />
<id>ossrh</id><br />
<username>[username]</username><br />
<password>[password]</password><br />
</server><br />
</servers><br />
<profiles><br />
<profile><br />
<id>gpg</id><br />
<properties><br />
<gpg.executable>gpg</gpg.executable><br />
<gpg.passphrase>[password]</gpg.passphrase><br />
</properties><br />
</profile><br />
</profiles><br />
<activeProfiles><br />
<activeProfile>gpg</activeProfile><br />
</activeProfiles><br />
</settings><br />
</pre></div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Release_Process&diff=405022Californium/Release Process2016-05-09T11:48:57Z<p>Eclipse.kovatsch.net: /* Repositories */</p>
<hr />
<div><br />
= How-to release Californium =<br />
<br />
Californium consists of the following components<br />
# Californium (parent)<br />
# Element Connector<br />
# Scandium<br />
# Californium (core)<br />
# Tools<br />
# Actinium<br />
<br />
Some of the components have dependencies on other components. Thus, in order to successfully build all of the components they need to be built in the order given above.<br />
<br />
=== Repositories ===<br />
<br />
The source code for Californium's components is managed in separate GitHub repositories as follows:<br />
{| class="wikitable"<br />
!Component<br />
!Standard URI<br />
!SSH URI (to be used on HIPP)<br />
|-<br />
|Californium (Core + Scandium + element-connector)<br />
|https://github.com/eclipse/californium.git<br />
|ssh://deploy_github_eclipse_californium/eclipse/californium.git<br />
|-<br />
|Tools<br />
|https://github.com/eclipse/californium.tools.git<br />
|ssh://deploy_github_eclipse_californium.tools/eclipse/californium.tools.git<br />
|-<br />
|Actinium<br />
|https://github.com/eclipse/californium.actinium.git<br />
|ssh://deploy_github_eclipse_californium.actinium/eclipse/californium.actinium.git<br />
|-<br />
|}<br />
<br />
=== Release Process ===<br />
<br />
The repositories mentioned above can be built either from the command line or using a separate Hudson build job for each repository.<br />
The following table contains the steps required to build and release a repository and the corresponding actions from the command line or the respective Hudson build job configuration required to make it happen.<br />
<br />
The ''Standard URIs'' from the table above are supposed to be used from the command line whereas the ''SSH URIs'' need to be used in build jobs on our HIPP instance in order to be able to push tags created during the build back to GitHub using deploy keys associated with the ''SSH URIs''.<br />
<br />
<br />
{| class="wikitable"<br />
!Step<br />
!Command Line<br />
!Hudson Build Job Configuration<br />
|-<br />
|Create build job<br />
| not necessary<br />
|<br />
# Create a new build job using the '''Build a free-style software job''' option<br />
# Check the '''This build is parameterized''' checkbox and add the following parameters:<br />
## '''RELEASE_VERSION''' - no '''Default Value'''<br />
## '''NEXT_VERSION''' - no '''Default Value'''<br />
# Under '''Advanced Job Options''' click the '''Advanced...''' button<br />
# Check the '''Clean workspace before build''' checkbox<br />
|-<br />
|Checkout repository<br />
|Use the ''Standard URI'' from the table above to clone the repository<br/><code>git clone https://github.com/eclipse/californium.git</code><br />
|Fill out '''Source Code Management''' section of build configuration like this (make sure to use the ''SSH URI'' from the table above):<br />
# '''Url of repository''': ''ssh://deploy_github_eclipse_californium/eclipse/californium.git''<br />
# '''Branch specifier''': ''master''<br />
# click '''Advanced...''' button in the '''Branches to build''' section to expand more options<br />
# '''Checkout/merge to local branch''': ''master''<br />
# check '''Skip internal tag'''<br />
# check '''Use Command line git to clone'''<br />
|-<br />
|Set release version (probably the same as the current one but without the ''-SNAPSHOT'' suffix)<br />
|<br />
For ''Californium (parent)'':<br/><br />
<code>mvn versions:set -DnewVersion=X.Y.Z</code><br />
<br />
For all other components (because the artifact version is implicitly set by the parent pom):<br/><br />
<code>mvn versions:update-parent versions:update-child-modules -DparentVersion=X.Y.Z</code><br />
|<br />
# In the '''Build''' section click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# For building ''Californium (parent)'' set<br />
## '''Goals''': ''versions:set''<br />
## '''Properties''': ''newVersion=${RELEASE_VERSION}''<br />
# For building all other components set<br />
## '''Goals''': ''versions:update-parent versions:update-child-modules''<br />
## '''Properties''': ''parentVersion=${RELEASE_VERSION}''<br />
|-<br />
|Build & test the code<br />
|<br />
<code><br />
mvn clean install -DsnapshotDependencyAllowed=false<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''clean install''<br />
## '''Properties''': ''maven.test.failure.ignore=false'' ''snapshotDependencyAllowed=false'' ''enableEclipseJarSigner=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Commit pom.xml containing the release version and create a corresponding tag for it<br />
|<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git tag "X.Y.Z"<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Execute shell'''<br />
# In the newly created build step add the following script <br/><br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release ${RELEASE_VERSION}"<br />
<br />
git tag ${RELEASE_VERSION}<br />
</code><br />
|-<br />
|Publish artifacts to Eclipse release repository<br />
|<br />
<code>mvn deploy -DskipStaging=true</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''mvn:deploy''<br />
## '''Properties''': ''skipStaging=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Publish artifacts to Maven Central's staging repo<br />
|<br />
<code>mvn deploy</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# In the newly created build step set<br />
## '''Goals''': ''mvn:deploy''<br />
## '''Properties''': ''createGPGSignature=true''<br />
# Click the build step's '''Advanced''' button<br />
## select ''Deploy to repo.eclipse.org + OSSRH'' from the '''Global settings''' drop-down list<br />
|-<br />
|Set next development version<br />
|<br />
For building ''Californium (parent)'':<br />
<br />
<code>mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT</code><br />
<br />
For building all other components:<br />
<br />
<code>mvn versions:update-parent versions:update-child-modules -DparentVersion=X.Y.Z-SNAPSHOT -DallowSnapshots=true</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Invoke Maven 3'''<br />
# For building ''Californium (parent)'' set<br />
## '''Goals''': ''versions:set''<br />
## '''Properties''': ''newVersion=${NEXT_VERSION}''<br />
# For building all other components set<br />
## '''Goals''': ''versions:update-parent versions:update-child-modules''<br />
## '''Properties''': ''parentVersion=${NEXT_VERSION}'' ''allowSnapshots=true''<br />
|-<br />
|Push changes to SCM<br />
|<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git push && git push --tags<br />
</code><br />
|<br />
# Click the '''Add build step''' drop-down list and select '''Execute shell'''<br />
# In the newly created build step add the following script <br/><br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release ${RELEASE_VERSION}"<br />
<br />
git push ssh://deploy_github_eclipse_californium/eclipse/californium.git && git push --tags ssh://deploy_github_eclipse_californium/eclipse/californium.git<br />
</code><br />
|-<br />
|}<br />
<br />
= Reference Instructions =<br />
<br />
1st get a copy of '''all''' the californium repository:<br />
<br />
<code><br />
git clone git@github.com:eclipse/californium.element-connector.git<br />
<br />
git clone git@github.com:eclipse/californium.scandium.git<br />
<br />
git clone git@github.com:eclipse/californium.git<br />
<br />
git clone git@github.com:eclipse/californium.tools.git<br />
<br />
git clone git@github.com:eclipse/californium.actinium.git<br />
</code><br />
<br />
You need to process the repository in the correct order:<br />
<br />
<code><br />
element-connector<br />
<br />
scandium<br />
<br />
californium<br />
<br />
tools<br />
<br />
actinium<br />
</code><br />
<br />
In each repository:<br />
* set the final version (probably the same as the current one but without "SNAPSHOT")<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z<br />
</code><br />
<br />
* build & sign the artifacts (you need a gpg key; see below)<br />
<br />
<code><br />
mvn clean install -Prelease<br />
</code><br />
<br />
* looks in ./target/ does the artifacts looks nice?<br />
* check if there is no *-SNAPSHOT in the dependency: <br />
<br />
<code><br />
mvn dependency:tree<br />
</code><br />
<br />
* then commit the pom.xml, and tag the release:<br />
<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git tag "X.Y.Z"<br />
</code><br />
<br />
* publish the artifacts on maven central<br />
<br />
<code><br />
mvn deploy -Prelease<br />
</code><br />
<br />
* prepare for the next cycle:<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT<br />
<br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
</code><br />
<br />
* push the commits<br />
<br />
<code><br />
git push && git push --tags<br />
</code><br />
<br />
Now connect on the [https://oss.sonatype.org/#stagingRepositories Sonatype OSS Nexus] and close the staging repository. If it's fine you will be able to "release" the repository and the artifact will show up in maven central in a few hours.<br />
Next step is to edit the [https://projects.eclipse.org/projects/technology.californium/governance Eclipse project metadata] and announce it on the mailing list.<br />
<br />
----<br />
<br />
= GPG Help =<br />
<br />
Under CygWin the following error might occur:<br />
<code><br />
gpg: cannot open tty `no tty': No such file or directory<br />
</code><br />
<br />
This can be fixed by configuring gpg through an active profile in <code>.m2\settings.xml</code> where also the Sonatype password is stored:<br />
<br />
<pre><br />
<settings><br />
<servers><br />
<server><br />
<id>ossrh</id><br />
<username>[username]</username><br />
<password>[password]</password><br />
</server><br />
</servers><br />
<profiles><br />
<profile><br />
<id>gpg</id><br />
<properties><br />
<gpg.executable>gpg</gpg.executable><br />
<gpg.passphrase>[password]</gpg.passphrase><br />
</properties><br />
</profile><br />
</profiles><br />
<activeProfiles><br />
<activeProfile>gpg</activeProfile><br />
</activeProfiles><br />
</settings><br />
</pre></div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Signing_Process&diff=390862Californium/Signing Process2015-09-02T14:48:44Z<p>Eclipse.kovatsch.net: </p>
<hr />
<div>This is a straw-man proposal to document the signing process to push milestones and releases to Maven Central. Please correct any false or unclear information given here.<br />
<br />
----<br />
<br />
It is important for the project to distribute milestones and releases to Maven Central because most people will want to pull in their dependencies from there. This requires the builds to be signed using GPG, which is usually done using the private key of the committer who performs the release locally on his own machine.<br />
<br />
The above process is problematic when within a company network. Furthermore, it is desirable to have a reproducible publishing process in place that can be triggered by any committer, always yielding the same result, i.e. independent from which person actually triggered the process. The Eclipse Foundation provides the facility to sign JAR files and also Windows and OS X applications with the Foundation's certificate. However, it does not provide any facility so far to GPG sign artifacts. Thus, we use the following signing process for the Californium project to distribute milestone and release builds through the HIPP:<br />
<br />
== Summary ==<br />
<br />
# Eclipse webmaster creates the GPG key pair for signing on the HIPP using cf-dev@eclipse.org<br />
# GPG key is kept in the home directory of the genie account of the HIPP<br />
# All committers sign the GPG key with their (personal) keys<br />
# The project also has a Sonatype account that is associated with '''the genie account (?)''' to deploy to the staging repository<br />
# Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml) on the HIPP<br />
# In order to create a Milestone and/or Release a committer tags the intended commit in GitHub accordingly and manually triggers the release build in Hudson, which checks out the particular version, builds the release, signs the artifacts using the project GPG key, and deploys the artifacts to the Sonatype staging repository using the corresponding Maven plugin<br />
# To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required (e.g., when the HIPP is suspected to be compromised)<br />
<br />
== Using the Hudson Instance ==<br />
<br />
The HIPP already supports GPG. Release builds can be either triggered manually or whenever changes are committed to the Git repository. The build process can automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).<br />
<br />
For this, we need to specify the '''Maven Central staging repo credentials (see open questions)''' and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).<br />
<br />
== Key Creation ==<br />
<br />
The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the GPG key ring on the project's HIPP machine.<br />
<br />
The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.<br />
<br />
Californium committers sign this key with their (personal) keys in order to improve trustworthiness.<br />
<br />
== Traceability ==<br />
<br />
The Hudson log shows what triggered the corresponding build (a SCM change or a user), and hence the release. The build is based on a Git commit, which in turn also has an author and committer.<br />
<br />
This tracability assumes that the HIPP is not compromised, of course, and that no normal user can trigger custom release builds that use sources other than a traceable Git commit.<br />
<br />
If it is suspected that the any part of the HIPP instance or GPG key is compromised in any way, the project should revoke the key immediately (see below) and once the system has been stabilized, a request must be made for a new key (see Key Creation).<br />
<br />
== Key Invalidation ==<br />
<br />
The key should expire after '''recommended time'''.<br />
If something goes wrong, a majority vote by the committers should be required to invalidate and/or replace the key through the webmaster.<br />
<br />
== Open Questions ==<br />
<br />
* Thanh Ha recommended that the trusted builds are built from trusted commits/tags, which are signed by a committer key. How do committers sign these?<br />
* Do we also need a project account for the oss.sonatype.org repo? I remember some automatic synchronization between this and the Eclipse repo for release builds...</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Signing_Process&diff=390858Californium/Signing Process2015-09-02T13:49:15Z<p>Eclipse.kovatsch.net: </p>
<hr />
<div>This is a straw-man proposal to document the signing process to push milestones and releases to Maven Central. Please correct any false or unclear information given here.<br />
<br />
----<br />
<br />
It is important for the project to distribute milestones and releases to Maven Central because most people will want to pull in their dependencies from there. This requires the builds to be signed using GPG, which is usually done using the private key of the committer who performs the release locally on his own machine.<br />
<br />
The above process is problematic when within a company network. Furthermore, it is desirable to have a reproducible publishing process in place that can be triggered by any committer, always yielding the same result, i.e. independent from which person actually triggered the process. The Eclipse Foundation provides the facility to sign JAR files and also Windows and OS X applications with the Foundation's certificate. However, it does not provide any facility so far to GPG sign artifacts. Thus, we use the following signing process for the Californium project to distribute milestone and release builds through the HIPP:<br />
<br />
== Summary ==<br />
<br />
# Eclipse webmaster creates the GPG key pair for signing on the HIPP using cf-dev@eclipse.org<br />
# GPG key is kept in the home directory of the genie account of the HIPP<br />
# All committers sign the GPG key with their (personal) keys<br />
# The project also has a Sonatype account that is associated with '''the genie account (?)''' to deploy to the staging repository<br />
# Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml) on the HIPP<br />
# In order to create a Milestone and/or Release a committer tags the intended commit in GitHub accordingly and manually triggers the release build in Hudson, which checks out the particular version, builds the release, signs the artifacts using the project GPG key, and deploys the artifcats to the Sonatype staging repository<br />
# The committer then performs the necessary steps in the Sonatype Nexus to publish the artifacts on Maven Central<br />
# To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required<br />
<br />
== Using the Hudson Instance ==<br />
<br />
The HIPP already supports GPG. Release builds can be either triggered manually or whenever changes are committed to the Git repository. The build process can automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).<br />
<br />
For this, we need to specify the '''Maven Central staging repo credentials (see open questions)''' and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).<br />
<br />
== Key Creation ==<br />
<br />
The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the GPG key ring on the project's HIPP machine.<br />
<br />
The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.<br />
<br />
Californium committers sign this key with their (personal) keys in order to improve trustworthiness.<br />
<br />
== Traceability ==<br />
<br />
The Hudson log shows what triggered the corresponding build (a SCM change or a user), and hence the release. The build is based on a Git commit, which in turn also has an author and committer.<br />
<br />
This tracability assumes that the HIPP is not compromised, of course, and that no normal user can trigger custom release builds that use sources other than a traceable Git commit.<br />
<br />
If it is suspected that the any part of the HIPP instance or GPG key is compromised in any way, the project should revoke the key immediately (see below) and once the system has been stabilized, a request must be made for a new key (see Key Creation).<br />
<br />
== Key Invalidation ==<br />
<br />
The key should expire after '''recommended time'''.<br />
If something goes wrong, a majority vote by the committers should be required to invalidate and/or replace the key through the webmaster.<br />
<br />
== Open Questions ==<br />
<br />
* Thanh Ha recommended that the trusted builds are built from trusted commits/tags, which are signed by a committer key. How do committers sign these?<br />
* Do we also need a project account for the oss.sonatype.org repo? I remember some automatic synchronization between this and the Eclipse repo for release builds...</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Signing_Process&diff=390797Californium/Signing Process2015-09-01T14:08:19Z<p>Eclipse.kovatsch.net: </p>
<hr />
<div>This is a straw-man proposal to document the signing process to push milestones and releases to Maven Central. Please correct any false or unclear information given here.<br />
<br />
----<br />
<br />
It is important for the project to distribute milestones and releases to Maven Central because most people will want to pull in their dependencies from there. This requires the builds to be signed using GPG, which is usually done using the private key of the committer who performs the release locally on his own machine.<br />
<br />
The above process is problematic when within a company network. Furthermore, it is desirable to have a reproducible publishing process in place that can be triggered by any committer, always yielding the same result, i.e. independent from which person actually triggered the process. The Eclipse Foundation provides the facility to sign JAR files and also Windows and OS X applications with the Foundation's certificate. However, it does not provide any facility so far to GPG sign artifacts. Thus, we use the following signing process for the Californium project to distribute milestone and release builds through the HIPP:<br />
<br />
== Summary ==<br />
<br />
# Eclipse webmaster creates the GPG key pair for signing on the HIPP using cf-dev@eclipse.org<br />
# GPG key is kept in the home directory of the genie account of the HIPP<br />
# All committers sign the GPG key with their (personal) keys<br />
# Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml)<br />
# HIPP polls Git repo to trigger Milestone and/or Release builds<br />
# To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required<br />
<br />
== Using the Hudson Instance ==<br />
<br />
The HIPP already supports GPG. It can poll the Git repository at a chosen rate and trigger Milestone and/or Release builds, which automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).<br />
<br />
For this, we need to specify the '''Maven Central staging repo credentials (see open questions)''' and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).<br />
<br />
== Key Creation ==<br />
<br />
The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the keyring.<br />
<br />
The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.<br />
<br />
Californium committers sign this key with their (personal) keys in order to improve trustworthiness.<br />
<br />
== Key Invalidation ==<br />
<br />
The key should expire after '''recommended time'''.<br />
If something goes wrong, a majority vote by the committers should be required to invalidate and/or replace the key through the webmaster.<br />
<br />
== Traceability ==<br />
<br />
The Hudson log shows what triggered the corresponding build (a SCM change or a user), and hence the release. The build is based on a Git commit, which in turn also has an author and committer.<br />
<br />
This traceability assumes that the HIPP is not compromised, of course, and that no normal user can trigger custom release builds that use sources other than a traceable Git commit.<br />
<br />
== Open Questions ==<br />
<br />
* Thanh Ha recommended that the trusted builds are built from trusted commits/tags, which are signed by a committer key. How do committers sign these?<br />
* Do we also need a project account for the oss.sonatype.org repo? I remember some automatic synchronization between this and the Eclipse repo for release builds...</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Signing_Process&diff=390789Californium/Signing Process2015-09-01T11:53:45Z<p>Eclipse.kovatsch.net: </p>
<hr />
<div>This is a straw-man proposal to document the signing process to push milestones and releases to Maven Central. Please correct any false or unclear information given here.<br />
<br />
----<br />
<br />
It is important for the project to distribute milestones and releases to Maven Central because most people will want to pull in their dependencies from there. This requires the builds to be signed using GPG, which is usually done using the private key of the committer who performs the release locally on his own machine.<br />
<br />
The above process is problematic when within a company network. Furthermore, it is desirable to have a reproducible publishing process in place that can be triggered by any committer, always yielding the same result, i.e. independent from which person actually triggered the process. The Eclipse Foundation provides the facility to sign JAR files and also Windows and OS X applications with the Foundation's certificate. However, it does not provide any facility so far to GPG sign artifacts. Thus, we use the following signing process for the Californium project to distribute milestone and release builds through the HIPP:<br />
<br />
== Summary ==<br />
<br />
# Eclipse webmaster creates the GPG key pair for signing on the HIPP using cf-dev@eclipse.org<br />
# GPG key is kept in the home directory of the genie account of the HIPP<br />
# All committers sign the GPG key with their (personal) keys<br />
# Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml)<br />
# HIPP polls Git repo to trigger Milestone and/or Release builds<br />
# To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required<br />
<br />
== Using the Hudson Instance ==<br />
<br />
The HIPP already supports GPG. It can poll the Git repository at a chosen rate and trigger Milestone and/or Release builds, which automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).<br />
<br />
For this, we need to specify the '''Maven Central staging repo credentials (see open questions)''' and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).<br />
<br />
== Key Creation ==<br />
<br />
The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the keyring.<br />
<br />
The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.<br />
<br />
Californium committers sign this key with their (personal) keys in order to improve trustworthiness.<br />
<br />
== Key Invalidation ==<br />
<br />
The key should expire after '''recommended time'''.<br />
If something goes wrong, a majority vote by the committers should be required to invalidate and/or replace the key through the webmaster.<br />
<br />
== Open Questions ==<br />
<br />
* Thanh Ha recommended that the trusted builds are built from trusted commits/tags, which are signed by a committer key. How do committers sign these?<br />
* Do we also need a project account for the oss.sonatype.org repo? I remember some automatic synchronization between this and the Eclipse repo for release builds...</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Signing_Process&diff=390788Californium/Signing Process2015-09-01T11:53:01Z<p>Eclipse.kovatsch.net: </p>
<hr />
<div>This is a straw-man proposal to document the signing process to push milestones and releases to Maven Central. Please correct any false or unclear information given here.<br />
<br />
----<br />
<br />
It is important for the project to distribute milestones and releases to Maven Central because most people will want to pull in their dependencies from there. This requires the builds to be signed using GPG, which is usually done using the private key of the committer who performs the release locally on his own machine.<br />
<br />
The above process is problematic when within a company network. Furthermore, it is desirable to have a reproducible publishing process in place that can be triggered by any committer, always yielding the same result, i.e. independent from which person actually triggered the process. The Eclipse Foundation provides the facility to sign JAR files and also Windows and OS X applications with the Foundation's certificate. However, it does not provide any facility so far to GPG sign artifacts. Thus, we use the following signing process for the Californium project to distribute milestone and release builds through the HIPP:<br />
<br />
== Summary ==<br />
<br />
# Eclipse webmaster creates the GPG key pair for signing on the HIPP using cf-dev@eclipse.org<br />
# GPG key is kept in the home directory of the genie account of the HIPP<br />
# All committers sign the GPG key with their (personal) keys<br />
# Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml)<br />
# HIPP polls Git repo to trigger Milestone and/or Release builds<br />
# To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required<br />
<br />
== Using the Hudson Instance ==<br />
<br />
The HIPP already supports GPG. It can poll the Git repository at a chosen rate and trigger Milestone and/or Release builds, which automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).<br />
<br />
For this, we need to specify the Maven Central staging repo credentials and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).<br />
<br />
== Key Creation ==<br />
<br />
The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the keyring.<br />
<br />
The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.<br />
<br />
Californium committers sign this key with their (personal) keys in order to improve trustworthiness.<br />
<br />
== Key Invalidation ==<br />
<br />
The key should expire after '''recommended time'''.<br />
If something goes wrong, a majority vote by the committers should be required to invalidate and/or replace the key through the webmaster.<br />
<br />
== Open Questions ==<br />
<br />
- Thanh Ha recommended that the trusted builds are built from trusted commits/tags, which are signed by a committer key. How do committers sign these?<br />
- Do we also need a project account for the oss.sonatype.org repo? I remember some automatic synchronization between this and the Eclipse repo for release builds...</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Signing_Process&diff=390787Californium/Signing Process2015-09-01T11:44:36Z<p>Eclipse.kovatsch.net: Created page with "This is a straw-man proposal to document the signing process to push milestones and releases to Maven Central. Please correct any false or unclear information given here, in p..."</p>
<hr />
<div>This is a straw-man proposal to document the signing process to push milestones and releases to Maven Central. Please correct any false or unclear information given here, in particular parts that are marked in bold.<br />
<br />
----<br />
<br />
It is important for the project to distribute milestones and releases to Maven Central because most people will want to pull in their dependencies from there. This requires the builds to be signed using GPG, which is usually done using the private key of the committer who performs the release locally on his own machine.<br />
<br />
The above process is problematic when within a company network. Furthermore, it is desirable to have a reproducible publishing process in place that can be triggered by any committer, always yielding the same result, i.e. independent from which person actually triggered the process. The Eclipse Foundation provides the facility to sign JAR files and also Windows and OS X applications with the Foundation's certificate. However, it does not provide any facility so far to GPG sign artifacts. Thus, we use the following signing process for the Californium project to distribute milestone and release builds through the HIPP:<br />
<br />
== Summary ==<br />
<br />
# Eclipse webmaster creates the GPG key pair for signing on the HIPP using cf-dev@eclipse.org<br />
# GPG key is kept in the home directory of the genie account of the HIPP<br />
# All committers sign the GPG key with their (personal) keys<br />
# Staging repo credentials and passphrase are stored in encrypted form in the Maven settings.xml file (requires settings-security.xml)<br />
# HIPP polls Git repo to trigger Milestone and/or Release builds<br />
# To invalidate and/or replace the key through the webmaster, a majority vote by the committers is required<br />
<br />
== Using the Hudson Instance ==<br />
<br />
The HIPP already supports GPG. It can poll the Git repository at a chosen rate and trigger Milestone and/or Release builds, which automatically deploy the created artifacts to oss.sonatype.org (and thus to Maven Central).<br />
<br />
For this, we need to specify the Maven Central staging repo credentials and the GPG key passphrase in the Maven settings.xml file. Both can be provided in "encrypted" through a master password defined in the settings-security.xml file (see https://maven.apache.org/guides/mini/guide-encryption.html).<br />
<br />
== Key Creation ==<br />
<br />
The GPG key pair is created by the Eclipse webmaster using the mailing list address of the project (cf-dev@eclipse.org). It is then installed in the keyring.<br />
<br />
The primary GPG key is stored in the home directory of the genie account (genie.californium). It is a normal login-less user account that runs builds on behalf of the project.<br />
<br />
Californium committers sign this key with their (personal) keys in order to improve trustworthiness.<br />
<br />
== Key Invalidation ==<br />
<br />
The key should expire after '''recommended time'''.<br />
If something goes wrong, a majority vote by the committers should be required to invalidate and/or replace the key through the webmaster.<br />
<br />
== Open Questions ==<br />
<br />
Thanh Ha recommended that the trusted builds are built from trusted commits/tags, which are signed by a committer key. How do committers sign these?</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=EclipseCon_2015_Dinner_Meetup&diff=379573EclipseCon 2015 Dinner Meetup2015-03-09T05:35:38Z<p>Eclipse.kovatsch.net: </p>
<hr />
<div>This page is to help groups organize for the Dinner Meetup at [http://www.eclipsecon.org/na2015 EclipseCon 2015] and [https://2015.foss4g-na.org/ FOSS4G NA]. (To see what groups did last year, check out the [https://wiki.eclipse.org/EclipseCon_2014_Dinner_Meetup 2014 Dinner Meetup wiki page]).<br />
<br />
On Monday evening after the Happy Hour, two chartered buses will provide transportation into Burlingame. The buses will loop between the hotel door by the elevators and the Burlingame Caltrain Station. First departure from the Hyatt is 6pm; last pickup in Burlingame is 9:45pm. Buses leave every 15 minutes.<br />
<br />
We encourage you to choose some companions, pick a restaurant, and enjoy dinner with your fellow attendees. Then head back to the Hyatt for Late Night in Knuckles bar.<br />
<br />
If you're the plan-ahead type, use this page to organize a group ahead of time and reserve a table for dinner - '''[https://www.eclipsecon.org/na2015/meetup#restaurants this list] should help.''' If you prefer spontaneity, hop on the bus, start a conversation, and have dinner with some new friends.)<br />
<br />
Here's a suggestion for organizing a Dinner Meetup group. '''It's a good idea to limit groups to no more than eight people, since many of the restaurants are small.''' Some of the restaurants can handle larger groups if you reserve ahead of time, such as [http://www.ilfornaio.com/?page=138&type=catering&restaurant_id=3144 Il Fornaio], [http://steelheadbrewery.com/burlingame/ Steelhead Brewery], or [http://www.straitsrestaurants.com/straits---burlingame-pages-5.php Straits].<br />
* Add your name and contact info as the group organizer, using one of the templates below<br />
* Consider choosing a theme for your group, such as "Modeling Mavens" or "Microbrew Appreciators"<br />
* Suggest a specific restaurant and consider making a reservation - this [https://www.eclipsecon.org/na2015/meetup#restaurants list] should help<br />
* Pick a meeting place and time, such as "at the restaurant at 7:30" or "let's gather at the 7:15pm bus"<br />
<hr><br />
<br />
=== Group 1 - IoT ===<br />
* Organizer: Benjamin Cabé<br />
* Theme: IoT<br />
* Dinner location: Steelhead Brewery<br />
* Meetup time and place: 7.30pm at the restaurant<br />
* Add your name below! We have a reservation for 20 people.<br />
# Benjamin Cabé<br />
# Ian Skerrett<br />
# Simon Lemay<br />
# Valentine Maire<br />
# John Schloman<br />
# Preeti Lovekar<br />
# Andrea Ceiner<br />
# Kai Kreuzer<br />
# Steffen Evers<br />
# Olaf Weinmann<br />
# Alexander Edelmann<br />
# Julien Vermillard<br />
# David Woodard<br />
# Luca Dazi<br />
# Ian Craggs<br />
# Gunnar Wagenknecht<br />
# Jendra Rambharos<br />
# Vatsal Shah<br />
# Alex Blewitt<br />
# Matthias Kovatsch<br />
<hr><br />
<br />
=== Group 2 - Modeling ===<br />
* Organizer: Eike Stepper<br />
* Theme: Modeling<br />
* Dinner location: [https://plus.google.com/108038536515491915291/about?gl=us&hl=en Kabul Afghan Cuisine], 1191 Burlingame Avenue, 650-343-2075<br />
* Meetup time and place: TBD<br />
* Add your name below!<br />
# Eike Stepper<br />
# Ed Merks<br />
# Al Chrosny<br />
# Pavel Sibirtsev<br />
# Erick Hagstrom<br />
# Akos Horvath, Istvan Rath<br />
# <br />
# <br />
<hr><br />
<br />
=== Group 3 - Geospatial Innovation ===<br />
* Organizer: Joe Allnutt<br />
* Theme: Geospatial Innovation<br />
* Dinner location: La Corneta Taqueria<br />
* Meetup time and place: 7.30pm at the restaurant<br />
* Add your name below!<br />
# Joe Allnutt<br />
# Andrew Ross<br />
# Robert Cheetham<br />
# Diego Gómez-Deck<br />
# Manuel de la Calle <br />
# Jody Garnett<br />
# Jim Hughes<br />
# Jamie Conklin<br />
# Wabuya Gaothusi <br />
# Evan Chan<br />
# Valerie Raybold Yakich<br />
# <br />
<hr><br />
<br />
=== Group 4 - Women in Geospatial ===<br />
* Organizer: Sarah Cordivano<br />
* Theme: Women in Geospatial (though anyone is welcome!)<br />
* Dinner location: TBD<br />
* Meetup time and place: <br />
* Add your name below!<br />
# Sarah Cordivano<br />
# Kathryn Killebrew<br />
# Lyzi Diamond<br />
# Lizzi Slivinski<br />
# Julie Goldberg<br />
# Lauren Ancona<br />
# <br />
# <br />
#<br />
#<br />
#<br />
#<br />
#<br />
#<br />
<hr><br />
<br />
===Group 5===<br />
* Organizer:<br />
* Theme: <br />
* Dinner location: <br />
* Meetup time and place: <br />
* Add your name below!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
<hr><br />
<br />
===Group 6===<br />
* Organizer:<br />
* Theme: <br />
* Dinner location: <br />
* Meetup time and place: <br />
* Add your name below!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
<hr><br />
<br />
===Group 7===<br />
* Organizer:<br />
* Theme: <br />
* Dinner location: <br />
* Meetup time and place: <br />
* Add your name below!<br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
# <br />
<hr></div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=IoT/Face-2-Face-Meeting-March10-2015&diff=378953IoT/Face-2-Face-Meeting-March10-20152015-02-27T08:17:11Z<p>Eclipse.kovatsch.net: /* Project Updates */</p>
<hr />
<div>The Eclipse IoT Working Group will host a face to face meeting at EclipseCon NA 2015. <br />
<br />
All Eclipse IoT Working Group members are invited to attend. If you are not a member, please contact ian.skerrett@eclipse.org for an invitation.<br />
<br />
==Time and Location==<br />
<br />
March 10, 2015<br />
<br />
2:15-5:00pm<br />
<br />
Sandpebble CDE<br />
<br />
==Agenda==<br />
<br />
=== Project Updates ===<br />
<br />
* Each project will spend 10 minutes updating on their current status. The update should include:<br />
** Project Overview: Short (1 slide) reminder about your project functionality. This is for people who might be new.<br />
** Project stats: tell us how well your project is doing. Number of download, number of contributors, number of bugs opened, number of mailing list subscribers, etc.<br />
** Project plan: when is the next release and what are the key features.<br />
** Key Challenges: What challenges/issues are you having?<br />
** Collaboration Opportunities: Where do you see potential for collaboration with other Eclipse IoT projects or other communities.<br />
<br />
* Projects<br />
** Leshan - Julien Vermillard<br />
** Wakkaama - Juliem Vermillard<br />
** Paho and Mosquitto - Ian Craggs<br />
** Kura - David Woodard<br />
** Eclipse SmartHome - Kai Kreuzer<br />
** Californium - Matthias Kovatsch<br />
<br />
=== LWM2M over MQTT ===<br />
<br />
* Update the group on the work being done to implement LWM2M over MQTT.<br />
<br />
=== Review action items from last F2F ===<br />
* Orbit style commons for IoT<br />
* Common MQTT message formats<br />
<br />
=== GPG Signing Party===<br />
<br />
* Detailed to be provided.<br />
<br />
===Other Discussions ===</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Release_Process&diff=376527Californium/Release Process2015-01-16T06:48:17Z<p>Eclipse.kovatsch.net: </p>
<hr />
<div><br />
=== How-to release californium ===<br />
<br />
1st get a copy of '''all''' the californium repository:<br />
<br />
<code><br />
git clone git@github.com:eclipse/californium.element-connector.git<br />
<br />
git clone git@github.com:eclipse/californium.scandium.git<br />
<br />
git clone git@github.com:eclipse/californium.git<br />
<br />
git clone git@github.com:eclipse/californium.tools.git<br />
<br />
git clone git@github.com:eclipse/californium.actinium.git<br />
</code><br />
<br />
You need to process the repository in the correct order:<br />
<br />
<code><br />
element-connector<br />
<br />
scandium<br />
<br />
californium<br />
<br />
tools<br />
<br />
actinium<br />
</code><br />
<br />
In each repository:<br />
* set the final version (probably the same as the current one but without "SNAPSHOT")<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z<br />
</code><br />
<br />
* build & sign the artifacts (you need a gpg key; see below)<br />
<br />
<code><br />
mvn clean install -Prelease<br />
</code><br />
<br />
* looks in ./target/ does the artifacts looks nice?<br />
* check if there is no *-SNAPSHOT in the dependency: <br />
<br />
<code><br />
mvn dependency:tree<br />
</code><br />
<br />
* then commit the pom.xml, and tag the release:<br />
<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git tag "X.Y.Z"<br />
</code><br />
<br />
* publish the artifacts on maven central<br />
<br />
<code><br />
mvn deploy -Prelease<br />
</code><br />
<br />
* prepare for the next cycle:<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT<br />
<br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
</code><br />
<br />
* push the commits<br />
<br />
<code><br />
git push && git push --tags<br />
</code><br />
<br />
Now connect on the [https://oss.sonatype.org/#stagingRepositories Sonatype OSS Nexus] and close the staging repository. If it's fine you will be able to "release" the repository and the artifact will show up in maven central in a few hours.<br />
Next step is to edit the [https://projects.eclipse.org/projects/technology.californium/governance Eclipse project metadata] and announce it on the mailing list.<br />
<br />
----<br />
<br />
=== GPG Help ===<br />
<br />
Under CygWin the following error might occur:<br />
<code><br />
gpg: cannot open tty `no tty': No such file or directory<br />
</code><br />
<br />
This can be fixed by configuring gpg through an active profile in <code>.m2\settings.xml</code> where also the Sonatype password is stored:<br />
<br />
<pre><br />
<settings><br />
<servers><br />
<server><br />
<id>ossrh</id><br />
<username>[username]</username><br />
<password>[password]</password><br />
</server><br />
</servers><br />
<profiles><br />
<profile><br />
<id>gpg</id><br />
<properties><br />
<gpg.executable>gpg</gpg.executable><br />
<gpg.passphrase>[password]</gpg.passphrase><br />
</properties><br />
</profile><br />
</profiles><br />
<activeProfiles><br />
<activeProfile>gpg</activeProfile><br />
</activeProfiles><br />
</settings><br />
</pre></div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Californium/Release_Process&diff=376526Californium/Release Process2015-01-16T06:37:34Z<p>Eclipse.kovatsch.net: </p>
<hr />
<div><br />
=== How-to release californium ===<br />
<br />
1st get a copy of *all* the californium repository:<br />
<br />
<code><br />
git clone git@github.com:eclipse/californium.element-connector.git<br />
<br />
git clone git@github.com:eclipse/californium.scandium.git<br />
<br />
git clone git@github.com:eclipse/californium.git<br />
<br />
git clone git@github.com:eclipse/californium.tools.git<br />
<br />
git clone git@github.com:eclipse/californium.actinium.git<br />
</code><br />
<br />
You need to process the repository in the correct order:<br />
<br />
<code><br />
element-connector<br />
<br />
scandium<br />
<br />
californium<br />
<br />
tools<br />
<br />
actinium<br />
</code><br />
<br />
In each repository:<br />
* set the final version (probably the same as the current one but without "SNAPSHOT")<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z<br />
</code><br />
<br />
* build & sign the artifacts (you need a gpg key)<br />
<br />
<code><br />
mvn clean install -Prelease<br />
</code><br />
<br />
* looks in ./target/ does the artifacts looks nice?<br />
* check if there is no *-SNAPSHOT in the dependency: <br />
<br />
<code><br />
mvn dependency:tree<br />
</code><br />
<br />
* then commit the pom.xml, and tag the release:<br />
<br />
<code><br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
<br />
git tag "X.Y.Z"<br />
</code><br />
<br />
* publish the artifacts on maven central<br />
<br />
<code><br />
mvn deploy -Prelease<br />
</code><br />
<br />
* prepare for the next cycle:<br />
<br />
<code><br />
mvn versions:set -DnewVersion=X.Y.Z-SNAPSHOT<br />
<br />
git add pom.xml \*/pom.xml<br />
<br />
git commit -m "Release X.Y.Z"<br />
</code><br />
<br />
* push the commits<br />
<br />
<code><br />
git push && git push --tags<br />
</code><br />
<br />
Now connect on the [https://oss.sonatype.org/#stagingRepositories Sonatype OSS Nexus] and close the staging repository. If it's fine you will be able to "release" the repository and the artifact will show up in maven central in a few hours.<br />
Next step is to edit the [https://projects.eclipse.org/projects/technology.californium/governance Eclipse project metadata] and announce it on the mailing list.</div>Eclipse.kovatsch.nethttps://wiki.eclipse.org/index.php?title=Launch_Plan_for_IoT_Java&diff=366858Launch Plan for IoT Java2014-07-10T02:17:21Z<p>Eclipse.kovatsch.net: /* IoT Java Projects */</p>
<hr />
<div>== Overview ==<br />
A number of the Eclipse IoT projects are targeting Java developers. By September 2014 most of these projects will have completed their first release from eclipse.org. Therefore, it is time we start talking about the overall solution for Java developers that is available from Eclipse IoT.<br />
<br />
=== Time-frame ===<br />
<br />
We will launch an IoT Java Stack at JavaOne, September 28-Oct. 2<br />
<br />
=== IoT Java Projects ===<br />
<br />
* Concierge [OSGi runtime]<br />
* Paho Java Client [MQTT]<br />
* Californium [CoAP framework]<br />
* OM2M [OneM2M]<br />
* Kura <br />
* Eclipse SmartHome<br />
* Eclipse SCADA<br />
<br />
<br />
==== Supporting Project ====<br />
* BIRT<br />
* ECF<br />
<br />
=== Key Messages ===<br />
<br />
* Connect and Manage IoT Solutions<br />
<br />
=== Download Package ===<br />
<br />
* We need to determine if we can create a download that can be used by Java developers. <br />
* What is the content of a download?<br />
* Potential deployment targets: Raspberry Pi, BeagleBone, others?<br />
<br />
=== Demos ===<br />
List of potential demos<br />
* SmartHome demo using Concierge, Kura<br />
* SCADA demo – [[EclipseSCADA/GettingStarted/DemoSystem]]<br />
* OM2M demo<br />
* ECF [[Tutorial:_OSGi_Remote_Services_for_the_Raspberry_Pi | Raspberry Pi Remote Services Tutorial]]<br />
* << TBD >><br />
<br />
=== Content ===<br />
* White Paper describing IoT Java Stack<br />
* Tutorial for Kura and Concierge<br />
* Java IoT Cookbook<br />
<br />
=== Web Site ===<br />
<br />
* Need to create a landing page for IoT Java on iot.eclipse.org<br />
<br />
=== Promotional Activities ===<br />
* Booth at JavaOne<br />
** Fact Sheet<br />
** IoT Java sessions at JavaOne<br />
** Cross promotion and demos with other Eclipse IoT partners at JavaOne<br />
* Webinar series<br />
* Press release at JavaOne<br />
<br />
=== Partner Organizations ===<br />
List of member companies from Eclipse IoT WG that would like to participate in the launch:<br />
* TBD</div>Eclipse.kovatsch.net