Publish GRIP to maven central

[nightpool]

This was brought up by kevin (@madhephaestus) to me today. It would be really cool if GRIP (or at least grip core) was published to maven central, so it's super easy to depend on, and develop applications that embed it.

thoughts?

[SamCarlberg]

Maybe? GRIP doesn't really have an API that'd be useful for dependent programs

[madhephaestus]

Well i would realy like to be able to embed the UI as a JavaFX tab in BowlerStudio (a full-stack robotics IDE). I would like to have it generate groovy (Java) that can be loaded and executed and linked against existing robotics libraries for command/control, kinematics CAD and physics simulations.

I would like a functions to:

• Get the UI as a widget (by being passed a camera source)
• Get the menus
• Attach a listener to the "run" event that receives code (and have that code used and modified rather then run stand alone)

The goal is to integrate your code with robot control code at a level above GRIP, while keeping the grip UI as an integrated part of development, not a seperate step.

[JLLeitschuh]

The concern that I would have about doing this is that suddenly GRIP core becomes an API and as such any internal changes to the API become breaking changes.

@madhephaestus I don't know if this helps but GRIP works as a functioning ROS node.

[madhephaestus]

ROS doesnt help as i am attempting to build a full stack IDE for real-time control systems. To my knowlage there is no possibility of running ROS node communication with stable fixed real-time. Also serializing and deserializing all data into and out of ROS packets is a performance bottle neck that need not exist when running code in a common memory space which can pass objects by reference, rather than by value.

As for API changes being stabilized, i dont understant why that shouldnt happen anyway?

[JLLeitschuh]

1. Regarding the API stabilizing we haven't really needed to do anything like that. The only API consumer is the xstream xml files we use for saving and loading and the values that get published to network tables. We only really have breaking changes when our save/load structure changes. To do what you suggest suddenly our internal code becomes an API that we have to support.
2. GRIP was never designed to be used as a library. We rely on guices dependency injection to wire the app together which does not make it optimal to be used as a library (I'm certain with some shoehorning you could). We also heavily rely on the guava event bus to send messages across the app, for example, to trigger changes to the UI. You could probably tie into that if you need to listen to events but I don't really want to be unable to change the meaning of events internally and have that be an API breaking change. It sounds like there may need to be some more thought that goes into this.

Maybe it would make more sense to create a puplic facing API wrapper over grip core that could be considered our API. Then the structure of core doesn't become something that users need to be aware of. What do other people think?