search

vert-x3 / vertx-maven-service-factory

Verticle factory for resolving verticles from Maven at run-time
Apache License 2.0
12 stars 12 forks source link

detached service descriptors? #4

Closed ghost closed 9 years ago

ghost commented 9 years ago

Arising from discussions in threads on vertx, vertx-dev

At time of writing, vertx-maven-service-factory uses the service identifier as maven coords to find an artifact jar to deploy, then assumes a service descriptor json with a particular name constructed from the service identifier / maven coords can be found once it has put that jar (and its dependencies) on a classloader's classpath, in a slightly "chicken/egg"-y fashion implementation-wise. It would be possible to support service descriptors themselves as maven artifacts external to the implementation jar instead or in addition to that approach, typical maven remote repository services do support json files as artifacts, see e.g. discussion here (though I suppose each service descriptor can also already fairly easily be wrapped in a tiny jar artfifact)

This could be a solution for the situation where you have one jar artifact containing implementations of bunch of related but distinct services, as has already arisen in e.g. vertx-mysql-postgresql-service. Perhaps you could have a little pom for the service descriptor json or jar with associated maven dependency info - i.e. each little per-service maven artifact could have a declared dependency on the shared service implementation jar maven artifact.

ghost commented 9 years ago

Uhh, seconds after filing this, spotted vertx-mysql-postgresql-service #11, which see.

purplefox commented 9 years ago

My worry with having a separate artifact for the descriptor is it seems quite Maven specific. Going ahead it would be nice to support other repositories (e.g. bintray) in a similar dynamic way, and I think it would preferable to handle the service descriptor in the same way for each repository.

ghost commented 9 years ago

Just to xref to the other idea in the vertx group thread as it seems pretty useful - actually allow an optional additional non-maveny qualifier on the end too, as you said:

  1. Allow the ability to override the service name when deploying. E.g. normally one would do:

vertx.deployVerticle("service:com.mycompany:myartifact:1.0");

and this would install the artifact then look for a file com.mycompany.myartifact.json on the CP.

However if one did:

vertx.deployVerticle("service:com.mycompany:myartifact:1.0::serviceA");

this would install the artifact then look for a file com.mycompany.serviceA.json on the CP.

purplefox commented 9 years ago

I've implemented the extra qualifier as described above. Hopefully that is good enough :)