-
Notifications
You must be signed in to change notification settings - Fork 193
Developer Set up Instructions Eclipse OpenIoT v0.1.1
- Eclipse Integrated Development Environment (IDE) – Latest Version
- Java SDK 1.7+ - Latest Version
- JBOSS AS 7.1.1 (Please use only this version)
- Maven 3.1 (Or Latest)
- The following variables needs to be set for successful running of maven, JBOSS and java
- JAVA_HOME
- MAVEN_HOME
- The following path needs to be set
- Java bin directory
- Maven bin directory
http://www.mkyong.com/maven/how-to-install-maven-in-windows/
This document aims to provide a step-by-step instruction to deploy the OpenIoT components. This document will not focus on LSM installation. The current document is developed to use the LSM on deri’s server. The following iterations will include instructions on installing and configuring LSM.
- Under UI Folder
- ui.requestCommons
- ui.requestDefinition
- ui.requestPresentation
- ide/ide.core
- Under modules
- Scheduler
- scheduler.core
- scheduler.client
- SDUM
- sdum.core
- sdum.client
- LSM Lite (If this gives error, don’t worry. For now ignore LSM as we will use DERI’s LSM server. I will update the document when I successfuly install and configure LSM locally).
- x-gsn
- Scheduler
- Under utils
- Utils.commons
- Install maven
- Download maven from http://maven.apache.org/
- Set the path to the maven bin directory
- Ensure you can run the mvn –version command from terminal or command prompt
- Install Eclipse Juno (or latest version). The following eclipse plugins needs to be installed to get a working environment without any errors. If you use a different version of eclipse, please update the following tools with corresponding version.
- Maven 2 Eclipse plugin – This is required to run maven commands from Eclipse and also import POM files into Eclipse as a eclipse-maven project -http://download.eclipse.org/technology/m2e/releases
- Install JBOSS Maven Support and JBOSS Web and Java EE Development tools – http://download.jboss.org/jbosstools/updates/stable/juno
- JIBX Eclipse plugin 1.1.6a from http://jibx.sourceforge.net/eclipse/
- Web Tools Platform 3.4.2 - http://download.eclipse.org/webtools/repository/juno/
-
Note 1:
- For JBOSS Web and Java EE Development Tools, only install
- Context and Dependency Injection Tools
- Forge Tools
- JBOSS JAX-RS Rools
- JBOSS Tools Java Standard Tools
- JBoss Tools JSF
- JBoss Tools RichFaces
- JBoss Tools Visual Page Editor
- JBoss WebService Tools
- JBossAS Tools
- For JBOSS Web and Java EE Development Tools, only install
-
Note 2:
- If you use a more recent version of eclipse, please replace the URl with corresponding version specific plugins.
-
Note 3:
- When using Eclipse Kepler, as much as possible, install the above plugins from the Eclipse Marketplace by searching for plugins by name.
-
Note 4:
- All these plugins can be installed from eclipse “install new software” option from under Help menu.
- Download JBoss 7.1.
- Unzip JBOSS to a directory in your hard drive.
- In Eclipse, under Windows->Show View->Other, search for servers.
- In the server window, right click and select new.
- If you have all the above plugin and tools installed, you will see an option for JBOSS 7.1 under the server options
- Select the location of JBOSS (the location on your drive previously unzipped).
- Start the JBOSS server from eclipse (a small play icon in the server window) to test and ensure JBOSS is starting and running successfully.
- Download the OpenIoT sources from github using your favorite git client or if using bash using the command - git clone https://github.com/OpenIotOrg/openiot.git
- Install the LSMLib into the maven store
- The lsm lib is under the utils directory of the OpenIoT source.
- There is a bat file with the command to install a jar file into your local maven repository.
- Run this and ensure the maven output results in Success.
- Start eclipse and create a new workspace.
- Import the following projects into eclipse using the file->import->maven project option.
- scheduler.core
- scheduler.client
- sdum.core
- ui.requestCommons
- ui.requestDefinition
- ui.requestPresentation
- utils.commons
- x-gsn
- Note: If maven complains about a JIXB plugin go ahead and import the project. This error is temporary and we will fix it later.
- Each project should import successfully, download all the POM dependencies.
- Note: At this stage, there will be some errors shown by eclipse IDE. Complete step 9 to ensure all errors are fixed except for xGSN errors which is a eclipse bug and not an error.
- The above projects are dependent on the utils.commons and ui.requestCommons (Note: First run utils.commons and then requestCommons to avoid any errors in maven build).
- Other project might pop up a missing dependency error. Don’t worry yet.
- Right click on the utils.commons project and choose run as-> maven build … (choose the one with three dots)
- In the new window, for goals enter the word “install”
- This will compile the project, generate the jar and install it in the maven repository.
- Repeat the same steps for the ui.requestCommons project.
- Right Click on the other projects and run maven->update project
- Now all errors should be resolved and only x-gsn will indicate couple of error. Ignore this as the error is due to incompatibility to eclipse maven plugin with some x-gsn configurations.
- Copy the openiot.properties file from the utils.common/src/main/resources/properties to the jboss folder standalone/configuration
- For the below projects, right click on project name, select maven build … and enter the following for the goal “jboss-as:deploy”
- ui.requestDefinition
- ui.requestPresentation
- sdum.core
- scheduler.core
- Check the JBOSS console for any errors. If no errors are generated, you have successfully deployed the OpenIoT platform on your local JBOSS server.
Note: To solve a JAXB exception, in the pom files of the ui.requestDefinition and ui.requestPresentation insert the following lines somewhere in the <dependencies> section
<dependency>
<groupId>org.eclipse.persistence</groupid>
<artifactId>org.eclipse.persistence.moxy</artifactid>
<version>2.5.1</version>
</dependency>
To run the platform, we first need to configure xGSN so that we have some live data being pushed into LSM. The current documentation is limited to pushing data to LSM server running on DERI. Once we have a successful xGSN setup, we can run the Request Definition and Request Presentation user interfaces to compose a new service.
The first component setup was xGSN. This was to ensure that there was sensor data available to be used later on by the request application
Wiki reference
The following are the LSM configuration properties used
Figure 1. LSM Configuration properties
During tested it was observed that the only “SensorType” and “SourceType” property that worked was “GSN”. This also leads to the issue discussed later on all sensor sources are visible on the request definition map as sensor type GSN. This makes it difficult to differentiate between sources.
Figure 2. Metatdata Description of Virtual Sensor in XML
For testing purposes, a CSV file was used as the source for test data to upload to LSM. This can be seen in the wrapper below. The CSV file is in the GSN folder under data directory
Figure 3. Virtual Sensor Description
Setting up new sensor in wrappers.properties
Figure 4. wapper.properties file
The wiki provides documentation on how to register a sensor using the existing batch file in the xGSN folder. However due to issues with class path length, the code within the batch file has to be re-written to the following.
Figure 5. Sensor registration
The following command is executed against the file. Execute this command from the xGSN parent folder.
- “lsm-register.bat virtual-sensors\netatomo_csiro_ws01_az.xml.metadata”
Figure 6. Sensor registration Successful
Once this is complete the new sensor ID is provided by the LSM registration process and the user must update the metadata file with the ID.
Figure 7. Change Sensor ID
To run xGSN from command prompt (windows), please update the entire .bat file with the following
java –classpath “./target/*;./target/dependencies/*” -splash:lib/logo.png -Dorg.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogger -Dorg.mortbay.log.LogFactory.noDiscovery=false org.openiot.gsn.Main 22232
The following command is executed to start xGSN. Execute this command from the xGSN parent folder.
gsn-start.bat
To run the Main method within the project, the port number on which the server will be set up on needs to be passed as arguments.
Figure 8. Run/Debug Setup
When executed the following debug shows a successful pushing of data to the LSM cloud
Figure 9. successful logging of data
The scheduler core is the core service that will be deployed on JBOSS. The scheduler service can be tested by opening the following URL
http://localhost:8080/scheduler.core/rest/services
The scheduler client is a java application with Swing UI to test the services of the scheduler.core service.
Here is a quick summary of the function. Some of the functions are still unclear.
Welcome - Will ping the server to test it is running
Discover – The discover service will discover the list of sensors within the given latitude and longitude
Register user – will register a new user with LSM (the new user will be stored into the graph as indicated by the configuration property file previously copied to the JBOSS store).
Login – the second register user section will test if a user is valid by authenticating the user against LSM.
Oamo and Osmo – These functions are used to get rdf information of users and services from the LSM store.
Figure 10. Scheduler client
The SDUM core is the core service that will be deployed on JBOSS. The SDUM service can be tested by opening the following URL
http://localhost:8080/sdum.core/rest/services
The sdum client is a java application with Swing UI to test the services of the sdum.core service.
Similar to the scheduler client application, the wiki / cookbook does not seem to provide any documentation on this client application. This makes it difficult for user to start using.
From experimentation, the following is the function of the client UI
Welcome – will test if the sdum.core service has been successfully deployed
Poll – the poll for service will take a service id and get the rdf data related to the service id
note: currently, there is no way to find the service id when using the user interfaces. The scheduler API if used directly without the request definition ui can provide the user with service id’s
Figure 11. Sdum client
The request definition interface can be access from http://localhost:8080/ui.requestDefinition
- Create a new user
- Login with the new user
- Compose a new service
- Validate the design
- Save the design
The request definition interface can be access from http://localhost:8080/ui.requestPresentation
- Login with same user id
- Load your application
- Click on current application-force dashboard refresh
- Data should become available in the selected output format