Importing Maven Projects from Git into Eclipse That Were Created By NetBeans

Eclipse projects managed by Maven and stored in a git repository can be opened in NetBeans without taking any special measures. The same cannot be said for trying to open a NetBeans project managed by Maven in Eclipse. This article will show you how to accomplish this task.

Step 1:

Verify that the project you are importing from a git repository is a Maven managed project. This is important because Maven defines the directory structure of the project and only if this structure is respected can the project be succesfully imported.

Maven projects created by Eclipse store all the files in a folder at the root level of the Git repository.

Figure 1 What an Eclipse project will look like on

To determine if this is a Maven managed project you will need to open the folder.

Figure 2 Maven managed Eclipse project

The existence of the ‘.project’ and ‘.classpath’ files plus the ‘.settings’ folder identify this project as created by Eclipse. NetBeans will load Eclipse based Maven projects without any issues. The same cannot be said when going in the other direction. Up until now I have been creating my sample code with Eclipse so that it can be used with either Eclipse or NetBeans. Not anymore as I prefer NetBeans to Eclipse.

A basic Maven managed project will have a file named pom.xml and a folder named ‘src’. There may be sub-folders to ‘src’ as well as other folders and files but it is safe to assume that if there is a pom.xml then the directory structure below ‘src’ is correct.

Image title

Figure 3 Maven managed project created with NetBeans

Eclipse cannot recognize this project created with NetBeans as a valid project without some effort.

Step 2:

In Eclipse select the File menu and then select Import… You will see:

Figure 4 Eclipse Import dialog

Step 3:

Select Projects from Git, click on Next, and you will now see:

Figure 5 Is the project in a local or remote repository

Step 4:

Select Clone URI and you will see:

Figure 6 Defining the location of the repository and project

All you need to enter on this form is the https address of your project from the repository. Once you do, most of the remaining fields are filled in. You only need a user name and password if you plan to commit back to the repository, assuming you have the necessary privileges.

Figure 7 After entering the URI

Step 5:

The next dialog allows you to select either the master or a branch of the project.

Figure 8 Choose the master or, if present, one of the branches of the project

Step 6:

The next dialog deals with an unusual feature of Eclipse and Git. Eclipse stores projects in folders called Workspaces. In the workspace folder are all the configuration information for every project in the workspace. Non git projects are created as sub folders of the workspace.

In a non-Eclipse environment the folder that a project is stored in will have a sub-folder named ‘.git’. This is where git stores your code whenever you perform a commit. However, the best practice for Eclipse is for git projects to be stored outside the workspace folder. The workspace is then configured to use your project as if it were a sub-folder of the workspace.

Figure 9 Selecting the folder for a Git project

By default, Eclipse will want to store your projects in a folder named git in your home folder. Feel free to change the location of the folder.

Step 7:

The next action is to chose a wizard for importing the repository.

Figure 10 Choosing the import wizard

If the project was originally created by Eclipse then you would select Import existing Eclipse projects. A NetBeans project is not recognized. Therefore, we must set it up as a General Project.

Step 8:

Now we need to give the project a name. Eclipse chooses the git name and that is usually sufficient.

Figure 11 Entering a name for the project

Click on Finish and you should see your project in Eclipse.

Figure 12 Imported project in Eclipse

Step 9:

As it stands the project is not ready to work with. You must convert the project from a General to a Maven project. Eclipse makes this easy. Right mouse click on the project and select Configure -> Convert to Maven project.

Figure 13 Converting a general Project to a Maven Project

The project will now look like a proper Maven project.

Figure 14 Maven project prsentation in Eclipse

You can delete the ‘bin’ folder. It is not a Maven folder and Eclipse is storing a copy of the project with its compiled code in it. It can be safely removed.

Step 10:

As a final step you should build your project. In Eclipse you build a Maven project by right mouse clicking on the project and selecting Run As -> 4 Maven Build.

Figure 15 Running your project as a Maven Build

Step 11:

The Edit Configuration dialog now appears. All you need to do here is click on Run.

Figure 16 Edit configuration dialog

Your project should compile and execute. There is one problem that could crop up here.

Error when building

You may or may not know that Eclipse, unlike NetBeans and other IDEs, does not use the Java JDK installed on your computer when compiling code. Instead it has a built-in compiler. Maven cannot work with the Eclipse compiler and so must have access to the Java JDK. Unfortunately, Eclipse only sees the JRE installation of Java which is all it needs to run the code it has compiled. If your Eclipse setup does not use the JDK then you will see this error when you run the Maven project:

[ERROR] No compiler is provided in this environment. Perhaps you are running on a JRE rather than a JDK?

To resolve this, go to the menu Window and select Preferences. In the Preferences dialog select Java -> Installed JREs. If you see the JRE in the list, remove it and replace it with the JDK.

Figure 17 Change from JRE to JDK

If you needed to update from JRE to JDK then you should be able to successfully execute a Maven Build.

You should now be able to manage the Maven project that was created from NetBeans in Eclipse.

IoT without the Breadboard, Part 1

      No Comments on IoT without the Breadboard, Part 1

A little over three years ago I purchased a promise on Kickstarter called Kano. This was a kit consisting of a Raspberry Pi B+, case, keyboard, power supply, speaker and cables. Having good luck with Kickstarter, the promise became a reality and I received a Kano. While the kit was designed for younger users I saw it as a way to get involved with the Internet of Things.

For Xmas that year I put on my wish list a specific set of components that could allow me to interact with devices. What I received for Xmas was a big bag of parts, some components such as LEDs, temperature sensor and a small LCD display. I set as my first goal to turn on and off an LED. Here was my kit:


Figure 1 My Kano and components

You will notice on the right side of the photo a breadboard. For those unfamiliar with this, it is a plastic board with rows of holes wired together and that can be connected to the GPIO pins of a Raspberry Pi. This way you can work with resistors, LEDs and other components without having to run individual wires to each pin on the GPIO or use a finger burning soldering iron. You can see the GPIO pins on the Raspberry Pi.

My breadboard currently holds a resistor, an LED and a cable. When I decided to do this I expected to be able to code the tuning on and off of the LED in Java. What I discovered, likely due to incompetent searching, was that most articles and blogs on playing with Pi computers were about using Python or C. I decided to put aside my preference and went with Python. After about five hours over two days I finally turned on and off the LED. It was not as much fun as I hoped for so I put it aside. I used the Raspberry Pi as a prop at the college open house but otherwise it carried out its most common function on my desk as “The Paperweight”.

In December 2015 I came across another Kickstarter project called Wio Link that caught my interest. A company called Seeed had a project for a wireless Grove controller. Grove is the name given to a family of IoT components mounted on a circuit board along with any necessary supporting components such as resistors. Each of this small boards have a 4 pin male connector socket. These components can now plug in to a circuit board called the Grove controller that is Arduino based. The Wio Link Grove controller board is communicated with over Wi-Fi. As I understood it, you could read or write to connected components using HTTP requests.


Figure 2 Wio Link board by Seeed Studios

When it arrived in April 2016 I was able to get it to work fairly easily. I leave it to you to read up on the Wio Link at It worked as advertised, sort of. To use the device, it needed to be configured with the necessary drivers for whatever component you were connecting to it. Here is where it got a bit weird. Every time you used the smartphone app to upload the necessary driver, the server from which the driver came from had to first compile the C code for the driver. The server was in China and the documentation recommended using your own server.

The Wio Link server code was available on GitHub and as a Docker image. I needed a Linux system for this and luckily I had an unused system upon which I installed Ubuntu. Now it was time to load the server software from Seeed. I tried the Docker approach first but to no success. Next I tried the native install. It actually did work, sort of. It appeared that I could connect to my server from my smartphone and I could instruct the server to download the necessary driver to the Wio Link board. When I queried the board via HTTP all I could get was an error message stating that I was using the wrong token. That was disappointing. I will return to this problem this summer.

In my research on the Wio Link I came across the GrovePi+. This is a circuit board that mounts on top of a Raspberry Pi and from which you can access components plugged into the GrovePi+. Here in Montreal there is a store named ABRA Electronics,


Figure 3 ABRA Electronics in Montreal

At ABRA I purchased a Raspberry Pi 3 and a GrovePi+ circuit board. I assumed that the components from the Wio Link would work on the GrovePi+ board, also made by Seeed.


Figure 4 The GrovePi+ circuit board

Another company, Dexter Industries,, specializes in selling educational kits based on the GrovePi+. They had an offer for teachers of a free three-month loan of a kit after which you returned it or bought it. This kit came with some cool sensors that were not part of the Wio Link kit. I ordered it and it arrived quickly.

I made contact with John Cole from Dexter Industries. On their web site they mention that the languages Python and C# but no Java. John told me that he was unaware of a stable and maintained library for Java and GrovePi. There was the Pi4j library,, but he felt that it was not being maintained. It was also designed to interact with the GPIO of a Pi and not the GrovePi. I told John I would investigate what was out there and report back.

What I discovered in my research were two projects on GitHub that presented code to interact with the GrovePi. The first was JGove,, by Dan Jackson and the second was IoTDevices,, by Eduardo Moranchel. Both are proof of concept code. I hope that from these two projects I can put together a library that can be easily used by anyone to code the GrovePi in Java.


Figure 5 GrovePi+ mounted on a Raspberry Pi 3 with a temperature/humidity sensor and an LCD display

In part 2 I will look more closely at the Grove system. Parts 3 will look at a mashup between Payara Micro and GrovePi+..