Friday, September 21, 2018

Parsing command line arguments in Spring etc

lots of frameworks are reported here:

but eventually I just want to do it using Spring classes

The advantage in Spring is that you can directly bind the command line arguments to attributes, there is an example here

A very simple example:

package org.pierre.clidemo;

import org.springframework.boot.SpringApplication;

import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.core.env.PropertySource;
import org.springframework.core.env.SimpleCommandLinePropertySource;
import org.springframework.boot.CommandLineRunner;

public class DemoApplication implements CommandLineRunner {

 public static void main(String[] args) {, args);

 public void run(String... args) throws Exception {
  PropertySource ps = new SimpleCommandLinePropertySource(args);
  // --file=pippo.txt --language=EN_TO_DE --firstOriginal=true
  System.out.println("file=" + ps.getProperty("file"));
  System.out.println("language=" + ps.getProperty("language"));
  System.out.println("firstOriginal=" + ps.getProperty("firstOriginal"));

and of course the JOptCommandLinePropertySource version is more robust...

Interesting also the project, but only to write CLI applications

Wednesday, September 19, 2018

Eclipse Linux Tools (Docker Plugin) source code

git clone git://

jars are installed NOT under the Eclipse installation folder, BUT here


Here they explain how to submit a bug

Unfortunately there is a bug in org.eclipse.linuxtools.internal.docker.ui.wizards.ContainerCopyTo

    public boolean performFinish() {
        boolean finished = mainPage.finish();
        if (finished) {
            target = mainPage.getDestination().toOSString();
            sources = mainPage.getFilesToCopy();
        return finished;

If you run Eclipse on Windows, and the docker daemon runs on Linux, the toOSString() formats any path into the Windows format, which is not recognized by Linux. So you can't specify "/var" because it will be turned into "\\var" which obviously fails on Linux. bug submitted

Monday, September 17, 2018

Nexus Maven repository migration

I need to migrate a Nexus 2.14 Maven repository to Nexus 3.10.

Unfortunately the Nexus product doesn't care much about migrations... probably they believe that, once installed, their product is immovable, like a sick elephant.

With a Nexus 2.14 to Nexus 2.14 migration, the repository structure is so simple that you can do it with a rsync.
But Nexus 3.10 is a totally different beast.

Luckily there are people who wrote tools:

I have to migrate from http://localhost:8081/nexus/content/repositories/releases/ (Nexus 2.14) to http://localhost:8181/repository/releases/ (Nexus 3.10)

git clone
cd maven-repository-tools
mvn package
java -jar maven-repository-provisioner/target/maven-repository-provisioner-1.3.2-SNAPSHOT-jar-with-dependencies.jar

java -jar maven-repository-provisioner/target/maven-repository-provisioner-1.3.2-SNAPSHOT-jar-with-dependencies.jar -s http://localhost:8081/nexus/content/repositories/releases/ -t http://localhost:8181/repository/releases/ -u admin -p admin123 -a org.pierre:pvjoinfacestest:war:1.0

tragically, the tool doesn't allow wildcards.... so you must know in advance the gav of ALL the artifacts you have to migrate.... my impression is also that the .war is not really uploaded!

I am trying this one

copy to my /home/centos/nexus214/sonatype-work/nexus/storage/releases folder, then run

./ -r http://localhost:8181/repository/releases/ -u admin -p admin123

and it works!