Update swagger-parser to 2.0.1

[jmini]

Because 2.0.1 version of swagger-parser will be published soon (see swagger-api/swagger-parser#717) this PR give us a chance to test it in OpenAPI Generator before it is released.

[jmini]

@jimschubert:

I’d recommend against pushing a -SNAPSHOT dep to master. This will prevent us from being able to run git bisect to detemine when a regression was introduced.

This is a valid point. We can leave this PR open until the 2.0.1 release is published. This means that for testing we should do it on this branch.

[wing328]

Definitely a valid point but I would suggest using the SNAPSHOT version of 2.0.1 so as to uncover potential issues before the official release. There were issues (regressions) upgrading to the latest swagger parser before and that's why we are using the latest SNAPSHOT version in the master to avoid running into similar issue.

[jmini]

We can not have both requirements:

• Not having SNAPSHOT versions on master at all.
• Being able to test now the next swagger-parser version before its release on master (this version is for the time being 2.0.1-SNAPSHOT).

I tend to agree with @jimschubert.

---

We will always have the case that we would like to test what will be impacted with the update of one of our dependencies. So we need to come up with a solution.

Maybe a solution would be to rename on this branch our version to 3.0.0.preview-SNAPSHOT or something like that, and to publish it on maven central snapshot.

From time to time (daily for example) we merge master branch into this branch.

We ask interested users to test the version 3.0.0.preview-SNAPSHOT of OpenAPI Generator.

This way we have a way to test 2.0.1-SNAPSHOT of swagger-parser but we keep very strong dependency policy on our master branch (that can help with regression investigation in the future).

[jimschubert]

Would it be out of the question to commit a local lib of the SNAPSHOT every 1-2 days? This way we would have repeatable builds, and still be able to evaluate the changes across branches.

[jmini]

@jimschubert: I am sorry, but I do not understand what you mean...

[jimschubert]

@jmini we can put the jar (and any transient SNAPSHOT jars) in a lib folder as unmanaged artifacts. They'd be in the class path and compiled into the shadow jar. I would need to see how to do this with maven and the plug-in.

[jmini]

@jimschubert: I do not think that this is the maven way of handling dependencies.

And yes, this will cause trouble with people testing the maven plugin (and overriding some dependencies in their pom).

And having jars (binaries) committed in a git repo does not seems right. It is ok for the gradle-wrapper (that is project independent and almost always the same) but not for dependencies.

---

1. We allow SNAPSHOT on master
2. We don’t test upstream dependencies
3. We create this “preview” branch with published artifacts (p or preview suffix in the version name) that works parallel to master, where we can test some SNAPSHOT version of our dependencies.

Because not having "1." is important for later investigations, I propose to go with "3.".