Vainolo's Blog

Archive for the ‘programming’ tag

Adding JAR Dependencies to an Eclipse Plugin Maven Tycho Build

leave a comment

Something that is constantly bothering me when developing the OPP project is the use of hard-coded Java library dependencies. I manually downloaded the jars for the libraries I use, copied them to a directory in the plugin that required them, and the added them to the MANIFEST.MF file.

You are probably asking why am I doing this. Well, Eclipse plugins (or more correctly OSGi projects) are built in Maven using a plugin called “Tycho”. This build process is different from the standard java Maven build process, specifically in how it handles dependencies.

OSGi dependencies are defined in a MANIFEST.MF file and not defined in POM of the project. When Maven is executed, it looks at the MANIFEST.MF file, extracts the dependencies, and then tries to download them from one of the repositories defined in the POM, which, as expected, are defined differently than Maven repositories.

We love standards. That is why we need at least two of them :-(.

So back to my problem: I have a number of simple Java dependencies that I am using in my projects. So searching the net I found the Apache Felix Maven Bundle Plugin (BND). After trying and trying again to get its configuration right, I gave up. Maybe you need a PhD to configure this, so I’ll come back again in a couple of months (hopefully :-)).

But hey, I’m a developer, and I should scratch my own itch, so why not develop a Maven plugin that does what I want? Yep, good idea! But after two weeks of work (by work I mean the only half hour available to me each day to work on this, excluding weekends) I found myself with a simple Maven plugin that is able to copy a file from here to there, but the learning curve is a steep.

And then I reinvented the wheel, because the solution was already posted in StackOverflow and I had read it a while ago, but disregarded it. Last week after learning some more Maven (because I was writing a plugin), I understood that I could create a new project (standard Java maven project) where the dependencies are downloaded and then copy the dependencies to my Eclipse plugin project. After a couple of minutes, Voila! It Works! You can find the results in the OPP repository. The Java only project is com.vainolo.phd.opp.java-dependencies which is required by the Maven module com.vainolo.phd.opp.utilities. Check how the POM files are written to see how this works. I also added the dependencies project as a child project of com.vainolo.phd.opp.releng so it gets built as part of the project.

There is also a simpler way to do this without another project, as described in this StackOverflow answer. Here the maven-dependency-plugin plugin is invoked directly in one of the initial phases of the build (i.e. validate), using plugin specific configuration to select the dependencies. Tried this but while it works for the direct dependency, it didn’t download transitive dependencies. This is probably a configuration things but at this stage I am not going to invest more time in this.

Maybe next year.

Happy coding!

Written by vainolo

January 23rd, 2016 at 11:30 pm

JSONPlaceholder: a “mock” RESTful API for Learning/Testing

leave a comment

When I’m learning new things, I always like to have real, simple examples that work. This makes for easier progress and also gives a good feeling that I’m on the right track. As I was learning how to work with APIs in Java, I needed some simple API to call to check that I was doing things right.

And I found the perfect match for this: JSONPlaceholder. This simple API supports all verbs (GET, POST, PUT, PATCH, DELETE and OPTIONS). It contains mock data that can be fetched, updated, and deleted. And best of all, requires no registration or special configuration. Just call the endpoints and things work.

Can’t be more grateful to these guys. Thanks!

Written by vainolo

October 25th, 2015 at 10:32 am

Posted in Thoughts

Tagged with , , , , , ,

A Lone Developer Can’t Hunt a Mammoth

leave a comment

I’ve noticed lately that I spend a lot of my time just sitting and talking with other people in my team about the things we are doing and the things we want to do. But it’s not only me (I am a PM, so talking is part of my job description).

After we moved to an open space seating, it is a very common thing to see groups of two/three developers, seating together in front of one of their workstations and talking about how to design a feature, or how to better implement a special piece of code. This is done quietly most of the time, but sometimes the discussion becomes loud, and then we send them to some focus room to keep it going.

This made me think about how much we need interaction with other people to do great things. Akin to hunting huge animals. Like a mammoth.

source: https://telltalewhat.wordpress.com/2015/01/05/guardian-of-the-fire/

source: https://telltalewhat.wordpress.com/2015/01/05/guardian-of-the-fire/

When the prehistoric man wanted meat, he hunted. A single hunter could probably bring down a rabbit, some birds, or other small creatures. But as we gathered together in tribes, this was not efficient. We needed something bigger, that fed the whole tribe and lasted for a while. So we started hunting larger pray. Like mammoths.

Hunting a large animal is completely different than hunting a small one. The hunter isn’t afraid of some small animal. But a mammoth can kill you. It can step on you, run at you, hit you with a tusk… And it is very resilient, so putting a spear inside it doesn’t really make a difference. You need more.

We needed to work together. To coordinate an ordinate attack, to create diversions when one of the team members was about to be trampled, to keep up the hunt even after injuries and weariness crept in.

And that is how teamwork was born.

Fast-forward to the 21st century, we are not hunting mammoths anymore (thank goodness!). We have replaced this by going to our office each day and getting a paycheck at the end of the month. Instead of mammoths, we hunt problems. Problems that people are willing to pay for us to solve them.

And just like before, a lone developer can surely solve some problems. Even complex ones. But the real, mammoth problems can only be solved by teams working together. You could say to with the weapons we have today, a lone hunter could kill a mammoth, and that is true. But unlike our prehistorical mammoth, our (problem) mammoth keeps on growing and growing.

First we just had to program a console applications, running on one machine, one source of input and output. Very fast things started getting more and more complex: Graphical User Interfaces, multiple input methods, users, distributed processing, global access, redundancy, high availability, high performance… And who knows what the future will bring.

So next time you find yourself at work talking with other developers, don’t feel that you are not working. This IS part of your work. Stop thinking that only by writing code you are doing work.

Working as a team is the only way to hunt down the mammoth (and good luck always helps)

P.S: I’m against animal hunting for fun and pleasure. I used the analogy because it was the first thing that came to mind and stuck.

Written by vainolo

August 9th, 2015 at 7:41 am

%d bloggers like this: