Frankly I don't think this is a good idea, too "clever", but raising it as an issue for a final yes/no decision based on threads on vertx, vertx-dev
A lot of services's service.descriptor.json files at time of writing have had their names abbreviated in a somewhat regular fashion, similar to the rules used by e.g. the apache felix maven osgi bundle plugin here i.e. if the tail of the groupId matches the head of the artifactId, drop the redundant-looking bit.
Unfortunately that has the inevitable effect of making them impossible to deploy with vertx-maven-service-factory as it stands. Rather than fixing each service descriptor's file name, it would be possible to extend vertx-maven-service-factory to look for abbreviated service descriptors, though again, I don't think it's a good idea even if file names like com.example.blahblah.blahblah-foo-service.json look a bit redundant. It seems brittle and could introduce potential for ambiguity.
Frankly I don't think this is a good idea, too "clever", but raising it as an issue for a final yes/no decision based on threads on vertx, vertx-dev
A lot of services's service.descriptor.json files at time of writing have had their names abbreviated in a somewhat regular fashion, similar to the rules used by e.g. the apache felix maven osgi bundle plugin here i.e. if the tail of the groupId matches the head of the artifactId, drop the redundant-looking bit.
Unfortunately that has the inevitable effect of making them impossible to deploy with vertx-maven-service-factory as it stands. Rather than fixing each service descriptor's file name, it would be possible to extend vertx-maven-service-factory to look for abbreviated service descriptors, though again, I don't think it's a good idea even if file names like
com.example.blahblah.blahblah-foo-service.jsonlook a bit redundant. It seems brittle and could introduce potential for ambiguity.