Split off the "normal case" example from the "legacy case" one.

[jean-philippe-martin]

This PR does two things:

• Move the current NIO example to a separate jar (this one still uses the "case 2" technique for adding GCS support to legacy jars).
• Create a very-similar NIO example in the examples jar, but this time using the "case 1" normal technique of adding gcloud-java-nio as a dependency.

This way we satisfy issue #778's goal of having all the examples being consistent per project. We also satisfy issue #791's goal of adding a new example and splitting into two example jars.

We'll probably want to subsequently add more NIO examples to the gcloud-java-examples project.

I put the new jar in gcloud-java-contrib, but we could put it somewhere else if appropriate, let me know.

I'm pulling this to start the discussion, but we can't merge it yet because (at least for me) it isn't working - the gcs filesystem provider doesn't load in the case 1 example. I don't yet know why.

edit: now I know and it works (see down the comment thread)

[jean-philippe-martin]

OK, this should address all the issues.

We still have the problem that mvn exec:java -Dexec.mainClass="com.google.gcloud.examples.nio.Stat" -Dexec.args="--check" does not work. I checked, and the jar file seems to have the correct SPI magic, so I'm not sure why we still get java.nio.file.ProviderNotFoundException: Provider "gs" not found.

As an experiment I have tried running the Stat example via an appassembler script, and this works just fine. This confirms that the jar is sound, and when adding it the way the end user would, the program works.

At this point it looks like mvn exec:java is the cause of our problems. We could either switch everything to appassembler, or figure out how to fix mvn exec.

[jean-philippe-martin]

Here's a proposal to switch the examples to using appassembler instead of mvn.exec. We'll have to talk about it first of course.

The benefits are:

• Stat example now works (both use cases)
• Easier to see what is available (list the bin folder)
• Easier to see what running an example entails (read the script)
• Simpler command line (no more -Dexec.args)

The first one is of course the biggest deal from my point of view.

PTAL!

[jean-philippe-martin]

I see Travis failed. Something about RemoteGcsHelperTest. This is surprising to me since I didn't change that class at all or (as far as I can tell) anything related to it.

[aozarov]

Looks good few more comments.

[jean-philippe-martin]

Thanks @aozarov! This should address the comments.

I went ahead and changed one of the Stat examples to ListFilesystems instead. Let me know if you want it to be some other example instead!

[mziccard]

We still have the problem that mvn exec:java -Dexec.mainClass="com.google.gcloud.examples.nio.Stat" -Dexec.args="--check" does not work. I checked, and the jar file seems to have the correct SPI magic, so I'm not sure why we still get java.nio.file.ProviderNotFoundException: Provider "gs" not found.

This may come a little late but this issue can be overcome. The problem here is that gcloud-java-nio is not available as an artifact dependency and that exec:java does not pass it in the classpath. To fix this add

    <dependency>
      <groupId>com.google.gcloud</groupId>
      <artifactId>gcloud-java-nio</artifactId>
      <version>0.1.6-SNAPSHOT</version>
    </dependency>

to the example's pom.xml and execute the class with:

mvn exec:exec -Dexec.args="-classpath %classpath com.google.gcloud.nio.example.Stat --check"

This will pass all jars in the classpath and the file system provider will be available.

[jean-philippe-martin]

@mziccard in reply to the exec.java comment above (GitHub doesn't seem to have a better way to reply?)

Thank you for your suggestion, that works indeed! I just had to change the command to

mvn exec:exec -Dexec.args="-classpath %classpath com.google.gcloud.examples.nio.Stat --check"

I didn't need to change the pom because gcloud-java-nio was already listed as a dependency.

It is weird though to have this example use exec:exec and all the other ones use exec:java. I tried to make it work with the latter; my attempt is mvn exec:java -Dexec.mainClass="com.google.gcloud.examples.nio.Stat" -Dexec.args="-classpath %classpath --check" but this failed because of a "malformed escape". It also doesn't work if I don't specify the classpath, even though one might reasonably expect maven to set the classpath correctly since it already knows about all the dependencies.

So now we have to decide whether we want to go with appassembler, or go back to mvn exec:*. Personally I lean towards appassembler because it's more consistent and for the reasons highlighted before (in short, the magic is better contained: for example I tried to use exec:exec before but failed because I didn't know it needed an explicit classpath argument with a magical string).

[mziccard]

@jean-philippe-martin I am fine with appassembler as long as we are consistent. This branch was detached from master before the dns branch was merged. We must remember to also switch dns examples to appassembler before merging.

[jean-philippe-martin]

Agreed then, let's use appassembler and remember to switch the dns example to it before merging the gcs-nio branch.

[aozarov]

Other than the last comment is there anything else we need to do before merge? @jean-philippe-martin @mziccard

[jean-philippe-martin]

Nothing left to do before the merge as far as I know.

[mziccard]

No more comments from me but the very important matter about newlines :) Sorry for not being clear!