Swagger additions break eclipse enviornment

jmkao commented 8 years ago

Swagger moved and repackaged everything at the beginning to the year and is now swagger.io. No more com.wordnik.

My suggestion is to pause on adding any more annotations until I'm done with the build integration for swagger.

@WesGilster I'll fix the existing annotations and send a PR back to you for them, easiest thing right now is probably to work on something else while I get swagger fixed up. :)

WesGilster commented 8 years ago

Sounds good. I'm pretty much done with my first round of swagger though. Everything should have a simple description. I'll wait till you have something you want to pull.

jmkao commented 8 years ago

The PR is ready, and it's a doozy from a build perspective because it carries over nearly all the work the @ergobot prototyped so I could manage swagger's library dependencies automatically and handle some strange library conflicts between swagger and jackson.

WesGilster commented 8 years ago

This is looking really awesome. It's great we are getting this all hooked into gradle and I got pretty excited when I saw your screenshot and merged this into my workspace before I looked it over.

Unfortunately, it kindof devastated my dependency management in my Eclipse workspace and configuration management is also broken.

Also, Gradle needs to work through a conflict for two versions of httpcore that were on the classpath. I fixed this recently, by deleting one of them, but that might not turn out to be quite as easy to deal with now that transitive dependencies are managed by Gradle. You will want: httpcore-4.3.2.jar(which comes from cling) and not httpcore-4.2.5.jar(which comes with jetty) This resolves the problem that direct URL downloads were failing.

It also looks like you might be missing mail.jar, which probably came from @ergobot branch. Let me know what's your plan and I'll stay out for a while...

jmkao commented 8 years ago

The best way to integrate with eclipse probably is with the official Gradle plugin. That will keep the two in sync. Let me work on a set of docs for that.

I could've sworn I deliberately did something with mail and httpcore, but might have left something out. I'll check on those. Both should be easy to handle.

Can you give me more detail on what is broken with confit management? Is it primarily the class path for the conf directory when running from eclipse? Or did I break something else?

On Apr 2, 2016, at 7:53 AM, Wes G. notifications@github.com wrote:

This is looking really awesome. It's great we are getting this all hooked into gradle and I got pretty excited when I saw your screenshot and merged this into my workspace before I looked it over.

Unfortunately, it kindof devastated my dependency management in my Eclipse workspace and configuration management is also broken.

Also, Gradle needs to work through a conflict for two versions of httpcore that were on the classpath. I fixed this recently, by deleting one of them, but that might not turn out to be quite as easy to deal with now that transitive dependencies are managed by Gradle. You will want: httpcore-4.3.2.jar(which comes from cling) and not httpcore-4.2.5.jar(which comes with jetty) This resolves the problem that direct URL downloads were failing.

It also looks like you might be missing mail.jar, which probably came from @ergobot branch. Let me know what's your plan and I'll stay out for a while...

― You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

!DSPAM:56ffdce223321616385309!

WesGilster commented 8 years ago

First off, it was a big commit, so I could easily have missed something. This is more of a division of duties type of email. I can deal with config.properties and eclipselog4j.properties in the launchers if you want, but I don't want to duplicate any work that you are working on. I'd rather stay away from conflicts while things are in flux.

Thanks, Wes G. On 4/2/2016 10:04 AM, James Kao wrote:

The best way to integrate with eclipse probably is with the official Gradle plugin. That will keep the two in sync. Let me work on a set of docs for that.

I could've sworn I deliberately did something with mail and httpcore, but might have left something out. I'll check on those. Both should be easy to handle.

Can you give me more detail on what is broken with confit management? Is it primarily the class path for the conf directory when running from eclipse? Or did I break something else?

On Apr 2, 2016, at 7:53 AM, Wes G. notifications@github.com wrote:

This is looking really awesome. It's great we are getting this all hooked into gradle and I got pretty excited when I saw your screenshot and merged this into my workspace before I looked it over.

Unfortunately, it kindof devastated my dependency management in my Eclipse workspace and configuration management is also broken.

Also, Gradle needs to work through a conflict for two versions of httpcore that were on the classpath. I fixed this recently, by deleting one of them, but that might not turn out to be quite as easy to deal with now that transitive dependencies are managed by Gradle. You will want: httpcore-4.3.2.jar(which comes from cling) and not httpcore-4.2.5.jar(which comes with jetty) This resolves the problem that direct URL downloads were failing.

It also looks like you might be missing mail.jar, which probably came from @ergobot branch. Let me know what's your plan and I'll stay out for a while...

― You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

!DSPAM:56ffdce223321616385309!

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/area515/Creation-Workshop-Host/issues/199#issuecomment-204731088

jmkao commented 8 years ago

Integrating with the gradle plugin will probably reduce or eliminate the need for the launchers and ensure that run behavior is consistent between gradle and eclipse. Let me put something together there and you can see if you like it.

WesGilster commented 8 years ago

Sounds awesome thanks. Since my Eclipse Workspace is in disarray anyway, I thought I'd take advantage of it and upgrade: https://eclipse.org/che/

My guess is that this will probably extract IDE/project/execution information completely out of our project(where it belongs). Don't let this stop your work though, I've got another project I'll try this out on...

jmkao commented 8 years ago

Ok, several fixes in the PR.

There is also a Gradle plugin called BuildShip that is shipped by a collaboration between Eclipse and Gradle out of the base project and works in conjunction with an eclipse task in the gradle build. This takes all of the eclipse project files out of the repo and puts the base structure under the control of gradle, with local additions (gradle updates will be merged with your local additions, which also solves the problem of local changes getting repo-wide visibility if we check them in just to help bootstrap new developers).

You can install BuildShip the usual way via:

There are two key features that BuildShip provides:

Project import/synchronization
Nice wrapper for running gradle tasks, especially test

To fully utilize BuildShip, you'll need to do the following:

Delete the project out of your workspace
Run: gradlew eclipse to generate the eclipse library dependencies
Import the project as a Gradle project:
Delete the Build Path Source entry for the host/tests that outputs to testbin:
Add the Gradle Task and Gradle Execution views that are buried under Window --> Show View --> Other...:
Use the run, testtasks by double-clicking on the task rather than creating custom launchers. This will take advantage of the OS logic already in the script and eliminate the need for eclipse-specific launchers for different operating systems.
fullRelease can be added as a Gradle type run launcher, which also eliminates any OS specific paths or shell logic

When dependencies are updated, they can be regenerated by running ./gradlew eclipse at the command line. For some reason this behaves funny when run from inside of eclipse. The BuildShip doc also mentions a Refresh Gradle Project option in the Project right click menu. For some reason, this isn't sufficient.

You will also see among the available tasks a cleanEclipse. Do not run this, it will totally regenerate the project and create a strange interaction that will make BuildShip wipe out our bin directory. I will fix this later when we re-organize sources into the standard src/main/java style organization that will fully standardize the build.

The HttpCore dependency issue seems to have been handled by the way I'm bringing in jetty components, and we only have 4.3.5. There was another conflict between JavaMail and and older version embedded in the RestEasy multipart provider. That's also been fixed, and I tested that both mailing and URL downloads work on Windows and Raspbian.

kloknibor commented 8 years ago

How to run gradlew eclipse? I'm missing al the java links in properties so I can't follow your steps :(

area515 / Photonic3D

Swagger additions break eclipse enviornment #199