* Ensure `plugin-api` module gets published at the correct maven path
* Move `plugins` to `plugin-api`
Signed-off-by: Edward Evans <edward.evans@consensys.net>
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Return plugin-api to the main repo
* Spotless
* Migrate all external plugin-api references to the project in this repo
* Add licence header
* Update repo reference for publish, even if commented
* Use real configuration for publishing plugin-api
This was tested with the
`:plugins:publishMavenJavaPublicationToMavenLocal` task and checking the
local Maven repo to make sure it was using the correct paths
Signed-off-by: Edward Evans <edward.evans@consensys.net>
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Use the external jars to provide the plugin libraries.
* Add mavenLocal to local repositories to aid development
* Remove the :plugins project
* Move the PantheonPluginContextImpl into :pantheon
* rename a few files
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* Do plugin lifecycle in ThreadPantheonNodeRunner
* Sniff out rendezvous directory for test during register call, it changes.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>
* It returns for any block we would broadcast to other peers, when
we would broadcast them.
* It returns a JSON String containing hash, number, and timestamp
* This event data is not set in stone, it may change in type or content.
* Acceptance tests and unit tests got a re-work away from the assumption
that there is only one plugin type.
Signed-off-by: Adrian Sutton <adrian.sutton@consensys.net>